Topic: [CLOSED] Bitmine CoinCraft A1 28nm chip distribution / DIY support - page 20. (Read 81287 times)

Lucky you, once the power numbers were confirmed I paid a king's ransom to get test boards made quickly so they'd be here before the chips. I'll look at trying to mod them, but I'm guessing I'll just have to pony up the money to get them remade.

Oh! my god....

I looked at my sample chips to measure. You are right.

The gap is 3.0mm (6 * 0.5) between the seven pins.

I'll have to stop making PCB. Modifications are needed....

Thank you for your information.

https://lh6.googleusercontent.com/-mbfAKAt_sMQ/UtX79QbOJII/AAAAAAAAABA/QshoU5GgvVo/w672-h553-no/A1.jpg

Well, this is more than a little disappointing. The datasheet is incorrect; the pad spacing is not 0.4mm it is 0.5mm.
Any chance we can get an updated and correct datasheet uploaded onto the Bitmine website?

Good news!

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.

Chip received today. Thank you.

PCB was not ready yet.

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

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

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:
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 , 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

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:


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.

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

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!

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

Samples received, thank you so much.

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

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

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

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!

Correctioin: Level Shifters mandatory

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).

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.


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

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 ?)

Like the Purple board... The Grover?



Single chip board... neat.

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