[CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support

[zefir]

The queue was required for the very first sample chips with limited availability. Following waves will be available in volumes and should not need to register.

As for the clock: the eval board in China uses 12MHz clock, Bitmine's 16MHz - both work. PLL settings allow arbitrary setting of divider, configuration tables for the PLL settings for 12 and 16MHz input clock and different system clock rates will be added to the documentation ASAP. If you design a multi-chip board, to feed all chips with one oscillator you need - guess what - clock buffers (no kidding here).


Cheers,
zefir

Crap, that means another 6 months until we get chips.

I think he means you need clock buffers on the board, not on the chips.  No need to worry yet.

Edit: Removed excess text.

Correct. I should have avoided attempts being humorous in such a serious and sensitive field, sorry.

To clarify: if you are building a multi-chip board, you either need to provide an oscillator to every A1, or use one common clock and connect it to all A1s over clock distribution ICs (TI uses the term 'clock buffers' for their related product family).

[1715067255]

1715067255

[1715067255]

1715067255

[1715067255]

1715067255

[1715067255]

1715067255

[goodney]

Is there another thread where people are discussing their DIY A1 designs? I don't want to hijack Zefir's thread with renderings if there is a better place...

-a[g

[zefir]

Is there another thread where people are discussing their DIY A1 designs? I don't want to hijack Zefir's thread with renderings if there is a better place...

I don't mind, since this ought to be also the DIY support thread. If someone is starting new A1 design related threads, please let me know so I can add a reference. Otherwise feel free to stay here.

[goodney]

Thanks! Here is my board: 145mm x 95mm, adjustable VCORE, power module on/off control, support for selecting between 2 oscillators, FTDI232H for SPI (no microcontroller), 75mm pitch holes to support standard LGA115X heatsinks, and a +12V fan header.

Only drawback is the expensive power module. Once I get this board working, I'll spend some time designing my own 30A VCORE supply.

Top:


Bottom:

[Bicknellski]

Like the Purple board... The Grover?



Single chip board... neat.

Cooling top and bottom so two heat sinks sandwiching the board?

[danchoo]

Now I am waiting for the chips, PCB design is in.

Mr zefir, Did you test it in turbo mode?

0.85V / 47A (40W) of power is required for VDD_CORE?

I would like to know the test result of max speed.(40GH/S ?)

[goodney]

Like the Purple board... The Grover?

That is the color OSHPark (www.oshpark.com) uses for solder mask, so their board renderings use it too. Their service is great, I highly recommend it if you can stand to wait about two weeks for your boards to come back.

Cooling top and bottom so two heat sinks sandwiching the board?

Yes, hopefully a big LGA heatsink with or without fan on top and a smaller heatsink thermal-taped to the chip on bottom.

[zefir]

Correctioin: Level Shifters mandatory

Well, as pure SW guy I can provide only limited HW related feedback, so please double check.

I have both a level shifter and the option to use an inline resistor to drop the 3.3V signal down to 1.8V on my test board similarly to how some Bitfury designs have implemented it. Have you investigated doing that, or just feeding 3.3V straight in?

I understood that the eval board used in China (the one you saw in the pictures) for testing has a level shifter for input and output signals, while Bitmine's boards use resistors to lower the input signals and a level shifter for the output signal (MISO) - seem to work both.

This seems to be true only for lower clock frequencies. As we approach the nominal clock range, the different delays within resistor network and integrated level shifter add up to a skew large enough to corrupt SPI communication. This is still being tested, but if you want to be on the safe side, use integrated level shifters for all signals to your uC (if its IO is not 1.8V).

[zefir]

Notification: Sample Chips delivered

According to tracking, most of the sample chips have already been delivered or are scheduled for delivery by end of today.

Some PM'd me about tracking number, which I think answering is obsolete meanwhile. If you do not get the chips by tomorrow, please contact me again and I'll provide you the tracking number.


Good Luck!

[marto74]

Notification: Sample Chips delivered

According to tracking, most of the sample chips have already been delivered or are scheduled for delivery by end of today.

Some PM'd me about tracking number, which I think answering is obsolete meanwhile. If you do not get the chips by tomorrow, please contact me again and I'll provide you the tracking number.


Good Luck!

Hi,
Zefir any update on the first batch distribution , pricing , delivery etc.
We'll for sure get from you if available some chips, like it was in the beginning with bitfury chips.
I hope We can do something similar here too

Best Martin

[zefir]

Notification: Sample Chips delivered

According to tracking, most of the sample chips have already been delivered or are scheduled for delivery by end of today.

Some PM'd me about tracking number, which I think answering is obsolete meanwhile. If you do not get the chips by tomorrow, please contact me again and I'll provide you the tracking number.


Good Luck!

Hi,
Zefir any update on the first batch distribution , pricing , delivery etc.
We'll for sure get from you if available some chips, like it was in the beginning with bitfury chips.
I hope We can do something similar here too

Best Martin

This is something I myself wait to get answered from Bitmine - who themselves only can forward what Innosilicon and GF is giving. Until otherwise stated I still expect them second half of January, which in bitcoin land I'd assume to be more towards end than mid of January.

As for long term availability, that's a different issue. I will keep my commitment and provide up to 5k chips from my initial order to the DIY scene, but I don't know what happens thereafter. For chips scheduled late February I need to place a binding order during the next 10 days, but I am not going to speculatively order without real knowledge of demand.

Therefore my approach would be as follows

• I keep track on availability, order deadlines and prices and will update here as soon as I have confirmed and binding numbers
• you continue testing the chips, and if you decide it has potential and see room to monetize your design, provide me your demands (volume @ delivery time @ price range)
• I'll match your demands as best as possible with what is available and place follow-up orders accordingly

I understand this is an uncomfortable process - but that's what we have to live with in a business that lasts for 3 months and has a lead time of half a year.

As for the price, as announced in the OP I'll forward Bitmine's prices transparently with a small premium to cover S&H to you. There is no adapted price yet announced from Bitmine, but the CPP terms give at least a rough figure. If price was $5/GHps for chips delivered mid December, CPP would add 40% more hashing power to chips delivered end of January - which gives some number around $3.5/GHps. This is pure speculation and maybe optimistic for the buyers' side - since with the current lack of competition the supply/demand factor is void for price finding.


Good luck testing,
zefir

[intron]

Notification: Sample Chips delivered

According to tracking, most of the sample chips have already been delivered or are scheduled for delivery by end of today.

Some PM'd me about tracking number, which I think answering is obsolete meanwhile. If you do not get the chips by tomorrow, please contact me again and I'll provide you the tracking number.


Good Luck!

Samples received, thank you so much.

Now let's see if we can get these
beauties hashing:)

[Bicknellski]

Pretty chip... can't wait till we get ours. Monday for us.

[giorgiomassa]

Happy to hear that some of you already got the samples! Remember that these are from a pilot run of the IC packaging, our guys in China have done several further optimizations in the meantime like the glue and the wires used inside the IC, also we did tweak some parameters with the foundry for future wafers, so the chips are going to be definitely much better in production run (coming probably next week already) than these samples.

Sorry that I fail to be active here on the forum but we are heavily debugging this baby in our labs these last days (and nights). Here are some hints we've found out that you should be aware of:

1) Reset should be toggled for a relatively long time, at least one second!

2) We tested both with 12 MHz and 16 MHz reflock, zefir's excellent driver can easily be used to program relatively any refclock within the specs given in the datasheet.

3) Not a news but the chip is veeeeery sensitive to VDD ripples, try to keep them between 50-70 mV maximum.

4) Heat sink is needed both on top and on bottom side. As for the top, a small BGA heat sink should be enough, you can experiment and as long as you keep the surface temperature to < 50°C it shouldn't have problems.

5) Suggested level shifters to be used for interfacing to anything that hasn't 1.8V I/O is TI TXS0104

Anything else I'll try to address it here

Good luck!

[intron]

1) Reset should be toggled for a relatively long time, at least one second!
--
Any idea why this is needed? To flush out all
start-up state (i.e. to clock out all random bits
stored in registers)?

2) We tested both with 12 MHz and 16 MHz reflock, zefir's excellent driver can easily be used to program relatively any refclock within the specs given in the datasheet.
--
Please can you tell were this driver can be found?

Thanks in advance,
intron

[zefir]

2) We tested both with 12 MHz and 16 MHz reflock, zefir's excellent driver can easily be used to program relatively any refclock within the specs given in the datasheet.
--
Please can you tell were this driver can be found?

Getting and building the A1 driver branch
I was approached by users having problems accessing the driver sources, since I wrongly assumed everybody is used to work with git. Here are the steps required to get and build the A1 SPI driver on a Linux host:

Code:

# 1) checkout our repository
git clone https://github.com/bitmine-ch/cgminer.git

# 2) in cgminer/ switch to our branch
cd cgminer
git checkout -t origin/bitmine-A1-scratchpad

# 3) run autogen and make
./autogen.sh --enable-bitmine_A1
make

The PLL setting feature is not yet pushed - I am currently cleaning up the code and should be done today. I'll also post some bring-up info relevant for your testing, if you need to start playing with the PLL settings before, this is how the parameters are related:

Code:

sys_clk = (ref_clk * pll_fbdiv) / (pll_prediv * pll_postdiv)

The SPI clock is derived from sys_clk and has a default divider of 64. You can verify your PLL settings are correct by sending dummy SPI commands to the chip and scoping its SCK_L - with 200MHz sys_clk, you should measure 3.125MHz.

[zefir]

Update: Chip Bring-up mini-Howto

Driver Update
I cleaned up the cgminer driver sources and pushed today to github. It is running now quite stable (so far tested with chains of up to 16 chips for 48h continuously) and gives you a ready to use tool to test your design long term after the bring-up. Among minor fixes it adds support for command line parameters to configure the PLL and SPI clocks - please take a look at ASIC-README for a short info.

Visual mini-Howto
I was supplied with visual representation of the points addressed here by the chip designer (Innosilicon) that I find quite handy and want to share:




Step-by-Step Bring-up Process
1) Physical
Most is depicted in the above figure, this is the prose version:

• chip is 1.8V only => use level shifter for all signals from/to host SPI interface
• VDD needs to be ~820-850mV with a max. ripple of 70mV (pilot run chips do not support undervolting)
• AVDD needs to be 1.8V with a max. ripple of 200mV
• power-up PLL settings are based on 12MHz reference clock; if you use a higher value do not start hashing without reducing system clock via PLL or you risk bricking the chip by overclocking it
• if you have a multi-chip board, use a clock distribution device to drive them with a single oscillator
• heat-sinks on both sides of the chip needed, monitor and ensure surface temperature does not exceed 50°C
• HW reset is mandatory; RSTN needs to be pulled low for at least one second; ensure it was released for at least one second before the first command is issued

2) SPI Interface
If you use the provided cgminer driver, it will run from an SPI host as is - like we are using a RasPi. If your system is uC based, the required SPI parameters are

• SPI_MODE_1
• low-active CS
• 16bit access only
• clock must be lower than A1 SPI master clock, which is sys_clk / 64 (e.g. if you set sys_clk to 100MHz, keep your host SPI clock below 1.5MHz)
• the last chip in the chain needs to close the SPI loop by connecting SDI_L with SDO_L

3) Command Sequence
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

b) set PLL

• while you scope SCK_L from the first chip, issue READ_REG: send 0x0a01, poll for 0x1a01 xxxx yyyy zzzz
• you should read the power-on values of 0x46c8, 0x2184, 0x00nn
• the SCK_L you scoped should have a frequency of ref_clk * 66.6 / 64 (with 12MHz ref clock SCK_L should be 12.5MHz)
• configure the PLL for a system clock at ~200MHz: calculate pll_prediv, pll_postdiv and pll_fbdiv, or take one of the following multipliers:
  
  • 7.5: 0x883c
  • 10.0: 0x8850
  • 12.5: 0x8864
  • 15.0: 0x8878
  • 20.0: 0x88a0
  • 40.0: 0x8940
  • 50.0: 0x8990
  • 60.0: 0x89e0
• with the selected divider value for xxxx, issue WRITE_REG: send 0x0900 xxxx 0x2184 0x0000, poll for 0x0900
• busy issue READ_REG and wait for pll_lock bit (register[24]) to be set
• issue another READ_REG and ensure that clock at SCL_L equals sys_clk / 64

c) hash
Now that chip is set to a secure low sys_clock, we can feed it a work item. For that, you could use the following reference job:

Code:

job[]={
/* midstate */
0x8D, 0x1F, 0xA3, 0x18, 0xD8, 0x0A, 0x25, 0x2C, 0xE4, 0xB7, 0xCD, 0x6D, 0x12, 0x2F, 0x80, 0x8F,
0x17, 0xDC, 0xD8, 0x10, 0x04, 0x17, 0xEA, 0x3F, 0xE8, 0xF3, 0x71, 0x41, 0x70, 0xF3, 0x4B, 0x49,
/* wdata */
0xD6, 0x98, 0x8E, 0x01, 0x27, 0x1F, 0x66, 0x52, 0xB6, 0x0A, 0x10, 0x19,
/* start-nonce, difficulty 1, end-nonce */
0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x1D, 0xFF, 0xFF, 0xFF, 0xFF
}

This work item has 5 winning nonces: 99b18d18, 0cb2a63a, de648f3f, 09c79cb9, b3587bbe

Now it is time to see it hashing:

• queue the work as job_id 1 for first chip by issuing WRITE_JOB: send 0x1701 <job>, poll for 0x1701
• get results busy looping while chip is hashing
  
  • issue READ_REG, exit loop if register[16]==0
  • issue READ_RESULT: send 0x0800, poll for 0xY8NN
  • if NN!=0, the next 2 words are a winning nonce

You should have received those 5 results and that's basically it. Rest is trivial (like my math prof used to say and left you working for weeks to get the trivia ), as can be seen in the cgminer driver on how to streamline input and output queues for continuous hashing.


Good Luck,
zefir

[Dexter770221]

Current consumption on AVDD? Is it relevant to SPI clock? How much?

[danchoo]

Chip received today. Thank you.

PCB was not ready yet.

 I'll try the test as soon as possible and writes here the result.

[Bicknellski]

The 2 - A1 samples got delivered today.

We will update you all on our progress.

Was hoping to have Zefir drop in our meeting next Saturday to discuss the firmware etc.