On hold until chip delivery - everything else makes no sense.

Aaargh, too tired to notice the difference. You're right, which means something went really wrong with keeping the docs up-to-date   Will push to fix.

Folks,

sorry for the troubles and not getting back in time, but I have a tough fight with the A1 which takes every minute of my time.

Edit: see posts below
First for the documentation: the picture intron posted above is exactly the one included in the latest spec document (https://github.com/bitmine-ch/bitmine/tree/master/Specs), or do I miss something? Please ignore other versions of that document, Bitmine did some modifications on packaging following community feedback after their initial post of the specs and updated the git repository.

As for the status of my fight: the chip hashes as expected - with proper cooling I got it running at 800MHz / 25GHps. What is more challenging is the chip-chaining, which in the current eval boards used for bring-up is unstable. The chips use their own SPI clock that is derived from system clock with a clock divider of 64 or 128. At that frequencies and with so much heavy power around, getting this part stable is not exactly trivial. I successfully run a 16-chip chain at lower clocks (somewhere around 250MHz), which proves that the chaining mechanism works in general, so all work left is to tweak the layout and get it operational at full speed.


Not sure how far your design is and whether you started testing, but I guess everyone else following this thread is eager to hear about results from independent parties.


No further news about delivery dates of chips in volumes - still expecting them this month.


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

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.

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

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

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.

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

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


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.



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

FYI: The initial testing of the chips passed, first wave of sample chips distributed to DIY projects shipped. More details here.

Currently everyone at Bitmine is busy testing the chip and I suspect they just lack time to plan and announce it. I'll post when I know more.



Update: Initial Tests with real Chips

Sample Chips
The first wave of sample chips has been shipped by Bitmine to the following people / projects (2 chips each): WASP, marto74, MrTeal, danchoo, Felipeo, Lucko, intron, burnin. They should arrive this week. Next wave will be available (in higher volumes) in week 3-4/2014.


Chip Testing
I visited Bitmine over the weekend for the initial chip bring-up. Test was performed on the first revision of the 8-chip boards that will be used in the rigs delivered to customers. We fought some very basic issues half night through - and finally we made the chips working. The cooling design is still worked on (and will be adapted to the findings during the tests), therefore we had to work without top heatsink. As a result, we could perform tests with reduced clocks so far, which is sufficient to validate the communication, chaining, and hashing. During the next days the cooling should be available and I will be able to explore the edges and post performance figures.

Intermediate Results Relevant for DIY
The following is a short list of things tested and relevant for DIY projects:

• PLL configuration working: arbitrary system clock selectable and usable
• AVDD must be 1.8V, input is not 3.3 V tolerant
• host SPI interface: level shifter from/to 1.8V required
• SPI chain termination: the last chip in the chain needs to have SDI_L and SDO_L connected to close the loop
• chips need to be HW reset (by pulling RESETn to ground) for proper operation
• hashing engines work, chip produces exactly the expected hashrate (number of engines * system clock)
• the initial cgminer driver published works as is
• chip is designed to dissipate ~70% through the PCB and 30% over top side, therefore heat-sink is mandatory

That's all for now. I will post a follow-up when cooling is properly applied to push the clocks to nominal ranges. By next weekend we could also get initial feedback from some of the DIY projects listed above.


Cheers,
zefir

Ok, coordination between timezones was bad: Giorgio posted the good news minutes ago: chip is working


The bad news are: there are only ~20 sample chips available for DIY projects in W1/2014.

Then again, the good news are: up to 10 projects will be provided with 2 free chips each.
More good news are, sample chips in volumes will be available in W3-4/2014.

The sample chips will be sent out by Bitmine; I will provide them the list of DIY projects that already registered, which will be supplied with higher priority over those registering hereafter.

Please note: only the very first sample chips are scarce as gold. If your design is ready and waiting for chips (like I know from WASP and marto74), please confirm to me you would like 2 chips from the pilot run. If you are still designing and would be fine with sample chips second half of January 2014, please be fair and leave the samples to those who need them more urgently.


Cheers,
zefir

Update: Preliminary Findings relevant for DIY Designs



Well, it was more an inspect-and-guess than a reverse-engineering - outcome is already included in the driver and described below.

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:


Known limitations
This is what I got from the FPGA emulator and therefore preliminary, but assuming the chip behaves the same, it is essential for HW designs out there: the BIST_START command that runs the auto-addressing process and enumerates the chips in a chain seems to work only once after chip reset. In subsequent calls it returns zero number of chips. The RESET command does not help here, therefore to start from a defined state you should provide means to HW-reset the chip in your design.

Undocumented features
Some bits in the register[23:8] range (tagged as reserved in section 3 of current spec doc) seem to have the following functionality:
register[17]:    2nd job active - if 0, host can feed another job to input queue
register[16]:    1st job active - if 0, chip is job-less and not hashing any more
register[15:12]: job_id of 2nd input item
register[11:8]:  job_id of 1st input item

Again, these are preliminary assumptions that need to be confirmed by chip designing company. But since this bits are used in the current driver to greatly improve the feeding of input queues, assume them to be final.


These updates will be added to the chip specification document as soon as we double-check with real chips and get confirmation from chip manufacturer - which I expect to happen by end of this week.


Partitioning chip chain
As you can read from the driver sources, the working units visible to cgminer are chip-chains. Instead of having long chains exposed to the risk of a single chip bricking the chain, Bitmine follows a modular concept with one STM32F1x controlling sub-chains on its SPI interfaces and transparently behaving like a chip-chain to the host as SPI-slave. I started working on this FW, which will be made open source as soon as it passes testing. If you are following the same concept with your design and are interested in working together on the SW side, please PM me.


That's for this year. I have some feeling that next year will be a good one for the DIY scene.

Cheers,
zefir

Miners and Bitmine customers,

before this thread fully turns into a source of misinformation and FUD, I want to herein try to limit the noise by clarifying those facts I am aware of.

Aside from being their largest customer, I work for Bitmine as a contractual consultant at the SW side. As such, I am in direct contact with the management and also regularly visit their offices. While doing PR on the forums is not part of my contract, I dislike the current sentiment where speculation and misinformation dominate. Still, I am under NDA and therefore can only sum up what is already publicly known or not covered by the NDA.

Chips
Believe it or not: there is no chip packaging facility in Europe. Therefore, the wafers produced by GF in Dresden were sent to China for packaging and will be returned back to Switzerland for testing / assembly.

Software
As announced here, I was supplied with an FPGA chip emulator to develop a cgminer SPI driver for the A1. The initial version was released some days ago, and with that, there is a tool available to mine with the A1 as soon as the chips are assembled. On top of that base functionality, the features currently being worked on are

• support for clusters of autonomous chip chains for modularity
• un-brickable FW upgrade to mature SW in the field
• user-defined / auto balance of hashrate vs. power consumption
• GUI

This list is sorted after priorities, and a GUI is obviously not on its top. I personally am fine to have the GUI provided by cgminer's miner.php, but there will also be a 'polished' Web-UI available.
 
Assembly
As already done with the Avalon clones, PCBs are assembled in north Italy and the PCBAs are delivered to Switzerland for product assembly and QA. During my last visit I saw around a dozen workplaces - production capacity should be therefore closer to 50 than to 10 units/day.

Misc FUD
To state the obvious: a) there are no A1 chips available - nowhere in the world, and consequently b) Bitmine is not mining with customer's rig.


Hope this helps to limit the current speculation. Please understand that I can't be more specific than this, but I am quite confident that we will hear significant news from Bitmine officials soon.


Happy New Year,
zefir

Update: initial A1 cgminer driver released


DIY folks and miners,

as announced before, some days ago I received one of this FPGA boards to develop the initial cgminer driver. This board is configured to emulate two daisy-chained A1 chips with 4 cores each, running at ~10% of the expected nominal clock. This is as close at it gets without having the real chip in hand, i.e. I was able to implement and test all documented features (plus some I reverse engineered).

While the emulated HW is limited in terms of clock and number of cores, all basic features (hashing, queue management, chaining) are working. At this stage I am quite confident that if the ASIC behaves exactly like emulated, it can start hashing immediately after it is put on its PCB.

I am running the FPGA board connected to a RasPi. Running over night cgminer settles the average hashrate to 650MHps, which corresponds to ~26GHps for the A1 (4x the cores @ 10x the clock).

Those interested can find the cgminer branch on github here.


Wish you all peaceful and pleasant holidays and a truly successful start in 2014 - with chips to play in hand soon.

zefir

I am also impatiently waiting for news while the expected delivery date for the A1 is approaching fast. All I know is that Bitmine is visiting China these days, so we should have updates early next week.

The document is all what Bitmine has available for their own design - if you miss something, please name it. You can not compare this to Avalon or BFL - they had already a working design that only needed to be published. Here everybody starts with a chip still in pipeline and there is no single design proven to work around to be named as reference - if you want to compare it, you need to do so with BitFury chips.

Again, I do not know how much is required to enable HW designer to work on a PCB for this chip, but since the WASP team is almost done, I have to assume it is sufficient. Please let me know otherwise which exact information you miss.

That's included in the git HEAD (p.16), thanks.


Thanks for sharing.