"Condo" for your Avalon chips: Price Drastically Reduced!

[flyonwall]

Update:

I have now ordered the most important parts -

1. Avalon ASIC chips
2. Xilinx Spartan-6 (there may be a shortage of this, so I ordered several)
3. Xilinx Spartan-6 prototyping board
4. TP-LINK WR703N (lots of these in Amazon)

I have also gone ahead and hired a PCB layout technician at ODesk. Once the specs and reference design from Avalon become available (anyday now), we will be ready. Tomorrow I am visiting a PCB prototyping and manufacturing shop not too far from where I live.

[BitHub]

Mabuhay, kamusta? The condo idea is pretty interesting. I'm very tempted to fly there from Australia in a month's time and help you set this up. Can we talk? ingats.

[wrenchmonkey]

Update:

I have now ordered the most important parts -

1. Avalon ASIC chips
2. Xilinx Spartan-6 (there may be a shortage of this, so I ordered several)
3. Xilinx Spartan-6 prototyping board
4. TP-LINK WR703N (lots of these in Amazon)

I have also gone ahead and hired a PCB layout technician at ODesk. Once the specs and reference design from Avalon become available (anyday now), we will be ready. Tomorrow I am visiting a PCB prototyping and manufacturing shop not too far from where I live.

I'm really hoping that the Spartan board is not actually a necessary component. Hopefully Avalon just wanted to save time, and had a bunch of FPGAs to get rid of, and that is the only reason they went that route. It would really suck to have to install a Spartan FPGA on every unit...

[flyonwall]

At this point, only the Avalon folks know the answer to that. It is possible they chose a Spartan-6 to do the job of the Control Unit because they have tons of that part on hand. However, it is unlikely because the Lancelot needs a different kind of Spartan-6, one that has more cells than it has I/O pins. I therefore doubt that they chose the XC6SLX16 just because they have stock on hand.

More likely I think is that the hash units are given commands independent of one another, and rather than put a USB chip on each hash unit, they chose to have each chip have its own serial ports. 8 USB ports on each module (one for each hash unit) can be more expensive than serial ports on each of the chips plus a single Spartan-6 to control all the 4 modules in a system. So the Spartan-6 has at least 8 x 4 = 32 serial ports on it. The Control Unit configuration bitstream on the Spartan-6 then hands out work to each hash unit independently of one another. It would be very inefficient to hand out work to all hash units, and then wait for all of them to get done, all synchronously. I believe it is the Spartan-6's job to hand out work to each hash unit, keeping each one busy all the time. So I think the Spartan-6 is crucial in keeping the hash rate up.

[flyonwall]

Mabuhay, kamusta? The condo idea is pretty interesting. I'm very tempted to fly there from Australia in a month's time and help you set this up. Can we talk? ingats.

PM me please.

[flyonwall]

While We are All Waiting For the Avalon Chip Specs ...

In the Avalon system, there are 10 chips in every hashing unit, 8 hashing units in a module, and up to 4 modules in a system.

I have more than 80% confidence that the chips are indeed connected to each other in a daisy chain manner. There are two serial ports on each chip. Why two? One serial port to connect to the chip before it, and the other serial port to connect to the one after it.

If the chips are connected in an Ethernet-like manner on the same wire, each chip will have to have its own address. I am sure the cost of fabbing ASIC chips with unique addresses would have been prohibitively expensive. So, no chip address. How then can the Control Unit access each chip, or, if the Control Unit sends work to all chips (in the same hash unit) in one shot, how can the work be subdivided among those 10 chips? In other words, how can each chip "know" which part of the work is assigned to it?

Daisy chaining allows each chip to be addressed uniquely, even though all chips are identical.

Now the daisy chain is only within one hashing unit. Outside of the hashing units, there is no daisy chain. Each hashing unit is connected to at least one serial port on the Control Unit. In a system with 4 modules (and 8 hashing units in a module), at least 32 serial ports are needed. Daisy chaining the whole system would be very inefficient. Now the 32 serial ports on the Control Unit are operating asynchronously. That's why the Spartan-6 XC6SLX16 is crucial in the system design.

I believe that any Avalon chip system design that does not use the Spartan-6 or any other similarly capable multi-serial port subsystem would not be able to keep all hashing units busy 100% of the time.

[Foofighter]

Hi,

here are the avalon specs:
https://github.com/BitSyncom/avalon-ref

regards

[flyonwall]

Wow, great! Thanks Foofighter.

[John (John K.)]

http://pastebin.com/raw.php?i=rJB6ap9v

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The escrow address for flyonwall's Condo project is:

14LLaL23H7mkXBdkwvGghj51VmpdgNKwSd

Please state and agree to the conditions (if item is received damaged, item lost with tracking, customs fee etc) beforehand.

If possible, GPG sign your agreement to prevent any discrepancies later on and please ship with tracking to prevent problems during delivery. GPG signing is not a requirement, and any verbal exchange in the form of private messages or posts on bitcointalk.org, or email is effective as a statement of condition.

The fine print:
This Contract is solely generated for the purpose of facilitating the transaction between the seller and the buyer, which refers to the pseudonyms used on bitcointalk.org.
The escrow holder, John, assumes and gives no liability or guarantees on the satisfaction of all parties involved, although he agrees to mediate and facilitate the deal to the fullest extent he is capable of.  On the event that any problems arises, he will release the escrow to whichever party that presents him with the most convincing proof and/or after an open discussion with others or theymos. 
The verbal acceptance by both parties (or the failure to reject) and the sending of Bitcoins to the escrow address above constitutes the acceptance of the terms and conditions stated, and the activation of this Contract.

Please understand that I am assuming the risk of holding the escrowed Bitcoins, and I am using my own time to facilitate this transaction.   
I am imposing a fixed fee of 1.5% for this transaction, pre-paid or otherwise to 1NB1KFnFqnP3WSDZQrWV3pfmph5fWRyadz .

Thank you.

John (the escrow holder)
9 May 2013
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQIcBAEBAgAGBQJRi2EQAAoJEINT5jezqu6ww6QP/31vD1jDFLFwuvSufPqnnOnh
yHog5F83TS5s29ngRS54M02MXPej0bgr5JT6utWwJ7LrFYhj5TAmJNcpz5UdMGRh
USPnGUlD0SKmN7U4j1WFbQlzCAfHxcwMHbHgxvHTpyJn1gRr1zhn8VP3yLGYt+gQ
2zErqlDKe9UAgTcT0D1y8Dr4U394/oCNkLI3gfPFMMZIQv8sXdNKvrk/kk8Cr+H8
UFeFHMdfvJwBzASuGrAlb2n/FT0QYysZhw9Bbd1BnAOU24sE7l5R4q0fSqEwfx73
OP1vU7xQjzo4gbWBmEOOLuTKZHKllu36hDThLjy2lWu5DENaZ1wO7x3LJRgSV+gb
n/WwVd2YDRgR3tI9hUVTJKW0Ap4S1oJV+7UXxzWMvlYuirMSpdsxRebIgqvBDrP1
zQKfAGFG02TlY1Nk4B0Q+43pFlbm1eid+juRNc2YGZSoUiM2t2Ks96sWaxg4mZS6
qmwy1KbVrB5DICiLh4vdTWblJ68Ae5ylnfYgtGrtASa9FJGhzst03DrxCdcbCulb
/1ElWvruvvGGEewhdwlf8zSKK9sWHEJIKeyxBJKnLNrkc2yeK9gZl8AIxB5IRSCU
p4vlcxloq3k/A8yy946c6a5zr8TYe/VtfaQ394TXlSypNHVrczDKNiWvWcqjRSAu
bMFfgMYu9o+5g84bkBzl
=FY0L
-----END PGP SIGNATURE-----

[BitHub]

HI, would you mind pming me your phone number, going to arrange for a rep to talk to you and arrange a meeting. Thank you.

[flyonwall]

So now with the release of the schematics from Avalon, it's official: I have been right all along about the daisy chaining, and also the use of the Spartan-6. Any design that does not use a subsystem with multiple serial ports working asynchronously will not be efficient. We will be using the original Avalon design, but are not clear yet on the hashing unit power supply because of parts availability.

[FullFathom5]

Well I am interested and while escrow through John K. is reassuring, I am sending my order directly in order to help get this off the ground.

FullFathom5, 16, 21.44, 18GQGk21L4RdMpZLdTvXZ7XrocE9ZwKqNw

[flyonwall]

Thank you very much.

I am not worried that more people are not coming forward at this time. There is still time to consider their options. I think that those in the community who bought chips, including those who are thinking of building their own systems, will see that this option makes compelling sense.

1. There is no definite physical location as yet. We are scouting for a location that has the lowest cost supply of reliable electricity and 24/7 security service. Right now it's looking like ASIC Hosting Service has the best option. This should lower electricity costs drastically. We are signing up with this ASIC Hosting Service.

2. Once a service agreement with the ASIC Hosting Service is ironed out, we will publish here the recurring costs. Some people I'm sure are waiting for this recurring cost to be nailed down.

3. The unit price of 1.34 is only good for the first five condo systems. Plus, if you buy later, your condo system will have to wait because the systems will be built and deployed in a first-come, first-served manner. You want to buy now to be ahead in Bitcoin mining: every hour that your rig is delayed and not mining is money wasted.

[Bicknellski]

So now with the release of the schematics from Avalon, it's official: I have been right all along about the daisy chaining, and also the use of the Spartan-6. Any design that does not use a subsystem with multiple serial ports working asynchronously will not be efficient. We will be using the original Avalon design, but are not clear yet on the hashing unit power supply because of parts availability.

Doesn't seem like Bkkcoins is too worried about using any Spartan 6 in his design. Can you give more evidence to support your claim that it will be inefficient without it?

https://109.201.133.65/index.php?topic=190731.msg2103669#msg2103669

Ok. Let me try to explain some details about how the hashing works, and why either an FPGA or CPU can work, so that we can move beyond this.

In order for the hash engine to work it needs 3 pieces of data:

( midstate, fixed_data, nonce )

Midstate and fixed_data are provided for each work unit by cgminer.

Nonce is a 32 bit range that will counted up through so that every value is hashed, ie max 4 billion odd hashes.

When cgminer sends a work unit to the Avalon it sends some control info (like fan speeds, module number, asic count) and then the (midstate and fixed_data), and then it appends on the starting nonce value for each ASIC in the target chain module. So for Avalon that is 10 copies of the nonce start value. This all comes down USB and into the FTDI chip which sends it into the FPGA.

The FPGA accepts this in a super long shift register and acts on it. It has to send a stream of data for each ASIC in the chain - so that means repeating the ( midstate, fixed_data, start_nonce_value )  serially into the data input of the ASICs. This is quite a bit of data actually:

( 256 bits midstate, 96 bits fixed_data, 32 bits nonce ) x 10 ASICs in chain = 3840 bits.

It holds the midstate+fixed_data and repeats it for each ASIC appending on the nonce_start.

Avalon uses an FPGA because it's doing this process for each of the 32 modules it contains because it is the one central controller in the box.

The way Klondike works is different but results in the same data going into the ASIC.

Klondike has a PIC controller with USB integrated. So it talks to cgminer just like Avalon, but will use a different driver. This driver will send the (midstate, fixed_data) to Klondike via USB and the PIC stores this in it's RAM (44 bytes total). It doesn't need to calculate and send the nonce, the PIC will take care of that. So total data sent for each work unit is 44 bytes.

The PIC will take this data in RAM and serially push it into the ASICs and then append on a nonce start value (by masking the high 4 bits, thus giving it a range equal to 1/16th of the total). It will repeat this for each ASIC in the chain. Since it's only managing it's own module it doesn't have to switch and control 31 other modules like the Avalon FPGA.

The Klondike has 16 ASICs but I have split them into 2 banks of 8 each. This allows pushing the data in twice as fast, and also means if one ASIC is damaged then only 8 cannot function, instead of 16. While the data is pushed into an ASIC the hashes it calculates are invalid, so the faster the new work start data is pushed in the less time the hashing is stalled.

Klondike also performs a few secondary tasks. It sets up a PWM register to control fan speed. It now and then takes a voltage reading off the thermistor or internal sensor. And it also accepts work data from the USB host that is not intended for it's own ASIC chains. A 44 byte work unit can arrive that is for some other module. In this case it simply receives it and sends it right out again on the I2C bus. Since the PIC has a hardware I2C controller this takes very little code or work.

So the same thing happens in both systems but in Avalon the FPGA has to handle 32 times more data than the PIC. With 16 ASICs at 282 MHz a nonce range of 32 bits will take about,

2^32 / 16 / 282,000,000 = 0.95189878 seconds.

The PIC has to receive 44 bytes of data in just under a second for itself, and then repeatedly shift it into the ASICs as initialization for hashing. This should take about 3% or less of it's time depending on how fast the ASIC shifting is done. The other 97% of it's time it's waiting for results, relaying data or fiddling with it's fan. Since most of these are handled by interrupts it's basically idling.

I may stick a 320x240 LCD touch screen on the front of my Klondike master so I can see status. The I2C bus would allow this and give the PIC something to do when idle.

[flyonwall]

Klondike has a PIC controller with USB integrated. So it talks to cgminer just like Avalon, but will use a different driver. This driver will send the (midstate, fixed_data) to Klondike via USB and the PIC stores this in it's RAM (44 bytes total). It doesn't need to calculate and send the nonce, the PIC will take care of that. So total data sent for each work unit is 44 bytes.

In other words, the burden of subdividing and assigning work among the PICs is done by the cgminer driver itself. On the Avalon system, this task is performed by dedicated hardware, the Spartan-6 FPGA. It amounts to the same thing, but the big difference is whether to do the Control Unit function in hardware or software (cgminer driver).

We will know when the communication specs become available on which implementation is better. I believe there is a reason why Avalon chose to implement the Control Unit function in hardware, aside from cost. In case the cost issue is not clear to you, consider this: if a PIC costs a dollar, and a Spartan-6 of the kind used in the Control Unit costs 24 dollars, with 32 hashing units in a system the price is 32 dollars versus 24.

[flyonwall]

In the recently available Avalon specs, it appears that the serial output pins REPORT_N and REPORT_P are used to "report" completion of each chip's task to the Control Unit. All REPORT_N pins are connected together, and all REPORT_P pins are also connected together to a pull-up resistor and are then directed to an output buffer on the way to the Control Unit. We can surmise that the protocol works as follows:

1. During the initialization phase, the chips establish their identities using the daisy-chained serial lines. Each chip has a "down-line" chip, the next chip in the chain. It also has an up-line. The Controller starts the initialization process by sending the first chip its identity, say 0. The first chip takes 0 as its identity, increments it, and sends 1 to its down-line. The second chip takes 1 as its identity, increments it, and sends 2 to its down-line, and so on. Now each chip has an identity. Other parameters are broadcast down the serial chain from the Controller, like how much of a work item each chip should assign to itself.

2. Now to start off the chips on a work item, all the Controller has to do is send one message, with a starting nonce embedded in the bytes of a block header. The message contains other parameters, like the total number of nonces to be worked on.

3. All chips get the same work item start message, but starts off at different nonces, according to its identity and the total length of nonces in the work item. The chips then start producing hashes, checking each hash to see whether it is less than the target.

4. The first chip that produces a target hash pulls the REPORT_N or REPORT_P line down, and sends the Controller the target hash. At this point, all other chips in the same hash unit can stop their work, because a target has been found. This point is important because it means that the work cycle time for each hash unit is NOT constant. It can vary wildly.

(The question you maybe asking is: why an independent serial input line for each hashing unit? Each hash unit's line establishes its identity to the Control Unit, for one. But I think a more important reason is to allow each hash unit to be working on completely different, even unrelated, work items. I have not looked yet into pool mining protocols closely to know the answer, but if in a pool mining environment the work items can be unrelated, then having each hashing unit be independent of one another is necessary.)

5. The Control Unit pulls the next work item from a queue, and starts over at Step 2 above, JUST FOR THIS HASHING UNIT.

In other words, the necessity for the Spartan-6 FPGA or something like it hinges on whether all hashing units are coordinated or non-coordinated. They should be coordinated if the work items coming from the mining pool are large enough to be subdivided efficiently among ALL hashing units, and should be non-coordinated if the work items are so small that the system does not gain efficiency by further subdividing the work items among the hashing units. Put it simply: coordinated means its simple and the FPGA is unnecessary, non-coordinated means its complex and the FPGA is crucial.

[Bicknellski]

So you don't know.

Thanks.

[flyonwall]

Don't know for sure at this point, but chances are I am correct.  

Just to summarize, here are the differences between the Klondike design and the Avalon design:

1. In the Klondike design, the task of subdividing and assigning work items are implemented in the cgminer driver (software). In the Avalon design, this task is performed by dedicated hardware.

2. In the Klondike design, cgminer communication with the hashing units go through USB via the PIC. In the Avalon design, dedicated serial wires are used to accomplish that communication.

The decision in any on-board communication design boils down to having dedicated wires, or using unique addresses and having a bus-like structure (as in I2C). For me the USB is not a good choice because it uses both dedicated wires and unique addresses. It's appropriate for out-of-box connections, but maybe overkill for in-box connections. However, designing systems is more of an art than pure logic. What may look elegant for you may look ugly to me. In the end, what matters really is when the rubber meets the road, which design turns out to be faster. Or the differences maybe negligible and all this discussion is for naught.

If you bought a number of chips, what you need to consider are the risks you are willing to take with your chips. The Avalon design is a proven design.

Also, we test your chips as soon as these arrive at the fabricator. We will let you know if any of your chips are non-functional. These chips have been tested by TSMC before these were delivered to the buyer, so the chances of any chip being non-functional is slim. However, we want to make sure, because after we accept a chip as OK, it is then in our hands and we guarantee its functionality to you. If any of your chips breaks from the time we accept it, we will replace it. We have ordered our own chips partly for this purpose.

[dan99]

Does it make more legit if he uses escrow from John? that part is only fabrication of the pcb boards etc for the chip, but how about the long term aspects? You will eventually surrender the chips to him .. when mining start. Actually they want to host in the Philippines, but decides otherwise because of credibility and reliability issues and now shift to the US.

[flyonwall]

The decision to locate in the U.S. instead of Cebu has been mainly because of much lower electricity costs in the U.S. It has nothing to do with "credibility".

One thing we have not determined is the cost of maintenance, and how much that would affect recurring costs. Best case is that the cost will not be more than how much mining pools charge, and Centerus will have to eat the losses until "critical mass" occurs. Critical mass is defined as that point at which the number of client-owned units allow Centerus to be profitable, charging only percentage rates similar to mining pools. The only way this business model can work is by making the clients profitable themselves.

Also, by the time you have your chips shipped to Centerus, we will have proven that we have a manufacturing system that works. We have not chosen the PCB fabricator, but when we do and everything is ready, we will schedule PCB fabricator inspections.