Glad to see the things are rolling
Topic: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support - page 17. (Read 81190 times)
January 28, 2014, 07:08:41 AM
Great , Great news.
Glad to see the things are rolling
Glad to see the things are rolling
January 28, 2014, 06:23:54 AM
Update: Chips shipped to Europe
Status
I was informed that the first wave of chips made it to HK before Chinese New Year and is on its way to Switzerland.
Delivery is expected by end of this week, DIY projects should have them in hand next week.
Remaining Sample Chips
I have the following names on my list for remaining sample chips:
If you requested samples but are missing on that list, please contact me again. Same goes of you are on the list but don't need the samples any more.
Chip Orders / Availability
All projects that placed orders will be contacted today with payment details. You are given time to finalize the payment until end of this week.
End of this week is also the guaranteed availability for the chips, since unsold ones are converted to mining rig ASAP.
Cheers,
zefir
Status
I was informed that the first wave of chips made it to HK before Chinese New Year and is on its way to Switzerland.
Delivery is expected by end of this week, DIY projects should have them in hand next week.
Remaining Sample Chips
I have the following names on my list for remaining sample chips:
Code:
Michael S.
vs3
savetree
goxed
goodney
zulunation
vs3
savetree
goxed
goodney
zulunation
If you requested samples but are missing on that list, please contact me again. Same goes of you are on the list but don't need the samples any more.
Chip Orders / Availability
All projects that placed orders will be contacted today with payment details. You are given time to finalize the payment until end of this week.
End of this week is also the guaranteed availability for the chips, since unsold ones are converted to mining rig ASAP.
Cheers,
zefir
January 26, 2014, 12:56:27 PM
Please double check:
From here I would guess SDI_L and SDO_L are not connected, leaving the SPI chain open. With that, all broadcast commands fail - among others the chip can not finalize its chip enumeration, thus responds only to 0xa00 - which btw. is an illegal command, since READ_REG is addressed to individual chips and not defined for broadcast.
Let me know if you need further help.
- keep RESETn low for a second, then at RESETn=1 wait for another second before you send the first command
- connect SDI_L to SDO_L to close the SPI chain
From here I would guess SDI_L and SDO_L are not connected, leaving the SPI chain open. With that, all broadcast commands fail - among others the chip can not finalize its chip enumeration, thus responds only to 0xa00 - which btw. is an illegal command, since READ_REG is addressed to individual chips and not defined for broadcast.
Let me know if you need further help.
SDI_L/SDO_L was my first thought as well, but I double checked, and they are connected. I tried a continuity tester, but I also with the scope I see identical waveforms on both pins.
I also used a 1 sec reset and 1 sec pause. The READ_REG for broadcast seems to work, though. The results make sense.
Quote
- 0x0100 (BIST_START) is a one-shot command: enumeration works only once after HW-reset, subsequent calls return 0 for chip count
I was wondering, has anybody else ever tried a single chip before ?
January 26, 2014, 07:19:22 AM
I was wondering, has anybody else ever tried a single chip before ?
Hm, no - both tested designs (Bitmine, marto74) use multi-chip-chains. Not sure what the WASP folks are going for, but no test results so far from their side.
Worst case you need to ensure that chip is not broken. If you have the second sample available you could double check.
Above that, please PM me for a more interactive support.
Likely both chips, ours won't be a single chip prototype, will be put on a 6 chip board layout that we are employing for our bring up. We are working through our BitFury design first before moving on to the A1.
January 26, 2014, 07:09:19 AM
Worst case you need to ensure that chip is not broken. If you have the second sample available you could double check.
Yes, I have a second sample, and I'm planning to assemble another board. That way I can test the boards separately, but also link them in a chain, and see if the behaviour changes.
January 26, 2014, 07:03:58 AM
I was wondering, has anybody else ever tried a single chip before ?
Hm, no - both tested designs (Bitmine, marto74) use multi-chip-chains. Not sure what the WASP folks are going for, but no test results so far from their side.
Worst case you need to ensure that chip is not broken. If you have the second sample available you could double check.
Above that, please PM me for a more interactive support.
January 26, 2014, 06:59:12 AM
hi guys
is there any opensource board available for this?
is there any opensource board available for this?
January 26, 2014, 06:18:40 AM
Please double check:
From here I would guess SDI_L and SDO_L are not connected, leaving the SPI chain open. With that, all broadcast commands fail - among others the chip can not finalize its chip enumeration, thus responds only to 0xa00 - which btw. is an illegal command, since READ_REG is addressed to individual chips and not defined for broadcast.
Let me know if you need further help.
- keep RESETn low for a second, then at RESETn=1 wait for another second before you send the first command
- connect SDI_L to SDO_L to close the SPI chain
From here I would guess SDI_L and SDO_L are not connected, leaving the SPI chain open. With that, all broadcast commands fail - among others the chip can not finalize its chip enumeration, thus responds only to 0xa00 - which btw. is an illegal command, since READ_REG is addressed to individual chips and not defined for broadcast.
Let me know if you need further help.
SDI_L/SDO_L was my first thought as well, but I double checked, and they are connected. I tried a continuity tester, but I also with the scope I see identical waveforms on both pins.
I also used a 1 sec reset and 1 sec pause. The READ_REG for broadcast seems to work, though. The results make sense.
Quote
- 0x0100 (BIST_START) is a one-shot command: enumeration works only once after HW-reset, subsequent calls return 0 for chip count
I was wondering, has anybody else ever tried a single chip before ?
January 26, 2014, 05:59:48 AM
3) Command Sequence
After a HW-reset as described above issue the following command sequence stages:
a) initialize chain
After a HW-reset as described above issue the following command sequence stages:
a) initialize chain
- RESET_BCAST: send 0x0400, poll for 0x0400 response
- BIST_START_BCAST: send 0x0100, poll for 0x01nn, where nn is the number of chips found in chain
- BIST_FIX_BCAST: send 0x0300, poll for 0x0300
I have a single A1 chip on a board. When I send 0x0400 I get the 0x0400 response, but when I send 0x0100, I get 0x0100 0x0000 back.
Any idea ?
If I continue with 0x0300 command, and 0x0A01, I read 0x0A01 back, followed by 0xFFFF. If I send 0x0A00, then I get 0x1A00, and the correct register value.
- keep RESETn low for a second, then at RESETn=1 wait for another second before you send the first command
- connect SDI_L to SDO_L to close the SPI chain
- 0x0100 (BIST_START) is a one-shot command: enumeration works only once after HW-reset, subsequent calls return 0 for chip count
From here I would guess SDI_L and SDO_L are not connected, leaving the SPI chain open. With that, all broadcast commands fail - among others the chip can not finalize its chip enumeration, thus responds only to 0xa00 - which btw. is an illegal command, since READ_REG is addressed to individual chips and not defined for broadcast.
Let me know if you need further help.
January 26, 2014, 05:37:16 AM
Update: Chip Distribution re-opened
Now that the first independent developer confirmed A1 chips are working as specified and word is that chips are sent out from China before the Chinese New Year, chances to get the first wave of chips in January look good.
cut
Now that the first independent developer confirmed A1 chips are working as specified and word is that chips are sent out from China before the Chinese New Year, chances to get the first wave of chips in January look good.
cut
1 Page before. No one knows when chips arrives.
But these are only chips. If you search complete miners, you should have a look at technobit...
January 26, 2014, 05:31:00 AM
I want to buy ,,,when will they start the shipment ?
January 26, 2014, 01:22:45 AM
Some eye candy, an A1 after reflow:
That is a purdy view. Almost see under that chip... heehehe. VERY VERY DELICATE placement indeed.
January 25, 2014, 04:19:46 PM
Hi
Anyone making ready-made pcb:s for this coincraft asic? I would be interested
I believe TechnoBit plans to sell complete products using the A1. It's my understanding that the Wasp Collective plans to license PCB designs to manufacturers. My team is still discussing how we plan to move with our design; given the cost of the A1, I didn't know if there would be sufficient interest in a pre-manufactured PCB sans the ASIC. Anyone making ready-made pcb:s for this coincraft asic? I would be interested
January 25, 2014, 04:12:43 PM
Hi
Anyone making ready-made pcb:s for this coincraft asic? I would be interested
Anyone making ready-made pcb:s for this coincraft asic? I would be interested
January 25, 2014, 03:53:06 PM
Nice shot. That certainly makes me happy. Can't wait to get my hands on these chips. :-) My design wasn't quite ready enough when the eng samples were going out.
January 25, 2014, 03:47:25 PM
Some eye candy, an A1 after reflow:
January 25, 2014, 12:20:42 PM
3) Command Sequence
After a HW-reset as described above issue the following command sequence stages:
a) initialize chain
After a HW-reset as described above issue the following command sequence stages:
a) initialize chain
- RESET_BCAST: send 0x0400, poll for 0x0400 response
- BIST_START_BCAST: send 0x0100, poll for 0x01nn, where nn is the number of chips found in chain
- BIST_FIX_BCAST: send 0x0300, poll for 0x0300
I have a single A1 chip on a board. When I send 0x0400 I get the 0x0400 response, but when I send 0x0100, I get 0x0100 0x0000 back.
Any idea ?
If I continue with 0x0300 command, and 0x0A01, I read 0x0A01 back, followed by 0xFFFF. If I send 0x0A00, then I get 0x1A00, and the correct register value.
January 23, 2014, 05:31:34 PM
I have one question regarding chip clocking.
As i understood the chip does not have internal oscillator?
if CLKMUX = 0 then the 32MHz clock is passed through the CLOCK pin and then multiplied by PLL settings.
if CLKMUX = 1 then clock is passed through the CLOCK pin without any PLL multiplication
Am i correct?
As i understood the chip does not have internal oscillator?
if CLKMUX = 0 then the 32MHz clock is passed through the CLOCK pin and then multiplied by PLL settings.
if CLKMUX = 1 then clock is passed through the CLOCK pin without any PLL multiplication
Am i correct?
January 21, 2014, 10:46:34 PM
Did not have time for this.
Any way We are going to measure it as soon Bitmine can send us a few more chips to test fully populated board
Any way We are going to measure it as soon Bitmine can send us a few more chips to test fully populated board
Yes that be nice for us as well a few more chips for our boards so we can populate it.
January 21, 2014, 03:34:31 PM
Did not have time for this.
Any way We are going to measure it as soon Bitmine can send us a few more chips to test fully populated board
Any way We are going to measure it as soon Bitmine can send us a few more chips to test fully populated board
Jump to: