Modular FPGA Miner Hardware Design Development

[Olaf.Mandel]

@O_Shovah: I asked three days ago about clarifying the terms under which what is created here becomes available. These are the suggestions that were made:

li_gangyi : distribution under the GNU GPL license
MountainMan : distribution under the MIT license, don't use GPL (Troll?: one post, no reply)
Olaf.Mandel : distribution under the GNU GPLv3+ license or possibly a different OSI approved license
O_Shovah : founding a company and distributing stake holdership or distribution under the GPL license
TheSeven : distribution under a FOSS license (MIT, BSD, GPL, LGPL, ...) or (reluctantly?) release into the public domain

Since then, the discussion has ceased. I guess people where agreeing by staying silent... Seems like distribution under one of the GPL variants or possibly a different OSI approved license (=FOSS license) are the most preferred solution. There were open questions with licensing under the GNU GPLv3+ (or a different variant):

• Can it be applied to hardware designs without problem? -> There seem to be some open hardware licenses (Wikipedia: TAPR, CERN-OHL and more. In contrast, OpenCores page suggests use of the GNU LGPL. The home-fabrication crowd (3D printers) are discussing this also: I haven't found an authoritative answer.
• What about contributions in this forum, in the form of ideas and management resources that do not lead to authorship of copyrighted documents? -> In my opinion, the person implementing the ideas into a file (design, whatever) has to decide if this is sufficient input to award the supplier of ideas shared authorship or not. This works well for normal publications, so why not here?

I myself don't see why a software license should not be usable for our purposes: the design files (Eagle, tables with BOM, ...) are the source-code files and the actual hardware built from these designs are compiled binaries. In that sense, we would be fine:

• there is no restriction whatsoever on what you can do with the hardware
• everyone who gets the hardware is entitled to the designs it is based on
• if someone uses our design, and modifies it (and gives out the hardware) they have keep giving our names as (co-)authors
• the stuff can still be sold (at a low margin of profit)

Please either discuss this question more energetically to get a conclusion or make a decision if you think there is a consensus. We cannot keep going on without these things clarified.

[1714246057]

1714246057

[1714246057]

1714246057

[phillipsjk]

I like the GPL. The problem with using a software license for hardware is the concept of "source code" becomes ambiguous. If it is made out of molded plastic, am I required to supply a copy of the mold upon request?

For images, are the original vector files used for rendering needed? Do all of the rendering parameters need to be spelled out?

I think for the FPGA, releasing the verilog files is enough, even if the "compiler" is very proprietary.

For the board, releasing the eagle files is probably enough as well, despite being another proprietary program.

"Public Domain"  may cause legal problems in some countries. That is what the WTFPL was written for.


Edit: The GPL licenses have some anti-patent provisions. This may be a problem if some patented functionality is included in the cost of one of the components.

[pusle]

Since there are two regulators for VCCINT it's better if they are separate even if they are happily connected together. ( most dc-dc don't like this).
With separate planes you can have individual  feedback from each FPGA.

You  don't need the VCCINT planes to cover the whole board, just under the FPGA extending out the the caps surrounding it and a super fat trace to the DCDC switcher.

The GND layer can/should cover the entire PCB. If you have to split it up, make sure the unbroken areas covers the FPGA's, the decoupling  caps,  the powersupply and the bus lines to the connector. There should be no "obstacles" or detours in the path of the return current.

The decoupling caps under det FPGA should be moved so one pad is as close to the VCCINT via as possible, then add a new GND via
that fits close to the other pad of the cap. ( if there isn't a GND via with suitable distance there already )

The termination resistors at the receiving end are not needed and just causes driving issues and draws lots of current.
Use series resistor at the output pin/buffer instead. 100R should be fine for anything up to 25MHz.
The FPGA has selectable impedance/drive strength on all pins so no need for  series drive resistors for signals  driven by the FPGA.

Is it me or does the via pads look very small?   But if the pcb manufacturer doesn't complain, neither shall I

[Olaf.Mandel]

Since there are two regulators for VCCINT it's better if they are separate even if they are happily connected together. ( most dc-dc don't like this).
With separate planes you can have individual  feedback from each FPGA.

You  don't need the VCCINT planes to cover the whole board, just under the FPGA extending out the the caps surrounding it and a super fat trace to the DCDC switcher.

Ok, so you are saying polygons instead of a supply plane.

[...]
The decoupling caps under det FPGA should be moved so one pad is as close to the VCCINT via as possible, then add a new GND via
that fits close to the other pad of the cap. ( if there isn't a GND via with suitable distance there already )

I was afraid someone would comment on the slightly longer trace length...

The termination resistors at the receiving end are not needed and just causes driving issues and draws lots of current.
Use series resistor at the output pin/buffer instead. 100R should be fine for anything up to 25MHz.
The FPGA has selectable impedance/drive strength on all pins so no need for  series drive resistors for signals  driven by the FPGA.

There is two types of resistors there: Thevenin termination for the SCLK (CCLK), MOSI, CLK, TCK and TMS signals. This is actually strongly suggested by Xilinx UG380 for the SCLK signal (they don't mention it for the others, though). This is a bit weird: the argument is that in master mode, the FPGA uses only a small drive strength on the CCLK output. But even for the slave mode (figure 2-3), they use the termination resistors. Unless you are very sure there, I would leave them in at least in the prototype: they can be desoldered for a test then and we can see. There is no such suggestion for the other terminations, I just thought they couldn't hurt. Same as above: remove them from the prototype to be sure.

The other three resistors are not termination at all: they are pullups for DONE, !IRQ and MISO. !IRQ must have a pullup during configuration (unless the MSP430 can do a weak drive?). Done can be left completely unconnected, in which case this pullup as well as R1 and R2 can go. But we may want to know if uploading the bitstream worked or not. And MISO is there to prevent an undefined logic level on that net before and during configuration.

Is it me or does the via pads look very small?   But if the pcb manufacturer doesn't complain, neither shall I

It's a bit of a problem: the drill of 0.2mm and the annulus of 0.25mm that I was shooting for don't fit inside the BGA. I erroneously configured 0.2mm annulus, so everything seemed to be fine. When I found my mistake, I chose to reduce the annulus to the (very slightly) more expensive 0.1mm annulus. The price difference is marginal (<2EUR per board for one example). Different suggestions?

[O_Shovah]

@O_Shovah: I asked three days ago about clarifying the terms under which what is created here becomes available. These are the suggestions that were made:

li_gangyi : distribution under the GNU GPL license
MountainMan : distribution under the MIT license, don't use GPL (Troll?: one post, no reply)
Olaf.Mandel : distribution under the GNU GPLv3+ license or possibly a different OSI approved license
O_Shovah : founding a company and distributing stake holdership or distribution under the GPL license
TheSeven : distribution under a FOSS license (MIT, BSD, GPL, LGPL, ...) or (reluctantly?) release into the public domain

Since then, the discussion has ceased. I guess people where agreeing by staying silent... Seems like distribution under one of the GPL variants or possibly a different OSI approved license (=FOSS license) are the most preferred solution. There were open questions with licensing under the GNU GPLv3+ (or a different variant):

• Can it be applied to hardware designs without problem? -> There seem to be some open hardware licenses (Wikipedia: TAPR, CERN-OHL and more. In contrast, OpenCores page suggests use of the GNU LGPL. The home-fabrication crowd (3D printers) are discussing this also: I haven't found an authoritative answer.
• What about contributions in this forum, in the form of ideas and management resources that do not lead to authorship of copyrighted documents? -> In my opinion, the person implementing the ideas into a file (design, whatever) has to decide if this is sufficient input to award the supplier of ideas shared authorship or not. This works well for normal publications, so why not here?

I myself don't see why a software license should not be usable for our purposes: the design files (Eagle, tables with BOM, ...) are the source-code files and the actual hardware built from these designs are compiled binaries. In that sense, we would be fine:

• there is no restriction whatsoever on what you can do with the hardware
• everyone who gets the hardware is entitled to the designs it is based on
• if someone uses our design, and modifies it (and gives out the hardware) they have keep giving our names as (co-)authors
• the stuff can still be sold (at a low margin of profit)

Please either discuss this question more energetically to get a conclusion or make a decision if you think there is a consensus. We cannot keep going on without these things clarified.

I agree that we have decided on a GPL licence or derivate of it.
The software part of it surly can be copyrighted by GPL. I m going to check wich basic problems might occure if there is also harware included.I also have some colleagues at university wich are into such topics. I ll interview them too.
As phillipsjk stated we should try to use as few proprietairy software and files as possible in the end. Maybe we could submit the harware as gerber files, not as eagle (i asume they are public file types, but have to check that) 

Maybe the next of you who uploades a file to dropbox may create a .txt file where he states what he has done and who else has contributed so far.

So in the end i have to do some further researche within the next week to give some hard facts.
Im sorry that i didn't do that up to now but im still right within my exams.

[pusle]

Of course the pullups are needed and the conf done should be routed to the MCP.
I was talking about the thevening 100R+100R termination.
This is only needed for really high speed and even then it's kind of a tossup.
At work I'm using series termination at the driver end for a DDR bus running at 160MHZ ( 320Mbit pr wire) single end.

Just avoid T-junctions and split the signals at the source perhaps with a series resistor for each wire.
If you really want rx end termination I would suggest using a cap+resistor in series. Then there is no DC current drawn + driver issues but
it's still terminated for the higher frequencies.


For the fpga ball & escape routing,  I  use 0.50mm pads for the fpga, and 0.25mm vias with 0.60mm pads. ( 1.0mm pitch BGA)


You don't have to work your ass off for every decoupling cap, but to me it looks like it should not take much time to get a large improvement here.

I guess the connector will be on one side of the fpga. Then you have 2-4 rows you can route "straight" out and make routing
of the special purpose pins + vcc quite easy.

[li_gangyi]

Since there are two regulators for VCCINT it's better if they are separate even if they are happily connected together. ( most dc-dc don't like this).
With separate planes you can have individual  feedback from each FPGA.

You  don't need the VCCINT planes to cover the whole board, just under the FPGA extending out the the caps surrounding it and a super fat trace to the DCDC switcher.

We can swap up to the current sharing capable LMZ modules, and make the Vccint 1 single supply, that'll need an external clock to make sure both modules run at the same frequency though. Can be a simple 555 or driven off the MSP430. With the MSP430, u can even generated a 180deh phase shifted clock, to reduce ripples in the output.

Good note on the Vccint plane, it should decrease routing complexity some.

[Olaf.Mandel]

I uploaded a new version of the FPGA schematic, board and PDF+PNG to github and dropbox. Commit log:

Converted the supply layer for VCCINT back to polygons, which allow the use of different nets. Also, moved some decoupling caps closer to their respective via.

This takes care of pusles first comment. I didn't change the vias, yet.

Also uploaded an AUTHORS and COPYING file, specifying GPLv3+. Please add or edit your info into these when you upload. The GPLv3+ license is tentative at the current time, while O_Shovah looks into the legal aspects of hardware vs. GPL a bit further. Anyone has a strong feeling about GPLv2 vs. v3? Tell us and edit the COPYING file if there is a consensus.

[Olaf.Mandel]

Of course the pullups are needed and the conf done should be routed to the MCP.
I was talking about the thevening 100R+100R termination.
This is only needed for really high speed and even then it's kind of a tossup.
At work I'm using series termination at the driver end for a DDR bus running at 160MHZ ( 320Mbit pr wire) single end.

Just avoid T-junctions and split the signals at the source perhaps with a series resistor for each wire.
If you really want rx end termination I would suggest using a cap+resistor in series. Then there is no DC current drawn + driver issues but
it's still terminated for the higher frequencies.

Ok, will remove them in the next iteration of the board. That will leave just 5 resistors for the FPGA board. As for the splitting at the source: does this apply for JTAG as well (should be slow enough, right)? And do you think one can run 25MHz through a T for SPI? The reason I ask is that this would make the bus even wider.

For the fpga ball & escape routing,  I  use 0.50mm pads for the fpga, and 0.25mm vias with 0.60mm pads. ( 1.0mm pitch BGA)

"x via with an y pad" means an annulus of (y-x)/2=175um, right? That leaves a clearance of ~157um on either side.

The default trace size and clearance for pcbcart are 200um (though 150um and 100um are also available) and min drill size is can be selected between 400um and 100um. The annulus sizes are either 250um or 100um. Their "standard PCB" product range is limited to 200um for the trace and drill size and the 100um annulus size is also not available there. The price difference seems to be small, though...

[...]
I guess the connector will be on one side of the fpga. Then you have 2-4 rows you can route "straight" out and make routing
of the special purpose pins + vcc quite easy.

Don't get it: how is the (power, I assume) connector related to this? And I haven't tried your settings, yet, but with the design rules I used I cannot access any of the inner pins without routing this to a different layer.

[O_Shovah]

I just added my mail to the authors and copying file.

I found a recent development in hardware licencing.The "CERN OHL" so the Center European de Research Nuclear  Open Hardware License http://www.ohwr.org/projects/ohr-meta/wiki/CERNOHL.
Its meant explictly and exlusiv for hardware and is similar like the GPL for software.
This would need for a spliting of the software part of the project to the GPL (all firmware,FPGA binaries,additional software) and the Hardware Part (all technical drawings, Documentation, Layouts, Prototypes).
But it would supply us with a reliable Licencing for both software and hardware, as the GPL has proven to be solid and reliable even in court and the CERN OHL can be seen simmilar as it was created by a International Authority and meant for Universitys and other societys wanting to publicate their hardware projects open to everyone without losing the initial rights to it.

In addition i just added my mail to the authors and copying file.


So thats my current status and proposal.I will dig further into this matter from monday onwards (last test ).

I see the Layout party being quite busy.Thank you everybody for making my little startthread such a great project

[phillipsjk]

I found a recent development in hardware licencing.The "CERN OHL" so the Center European de Research Nuclear  Open Hardware License http://www.ohwr.org/projects/ohr-meta/wiki/CERNOHL.

Section 3 reminds me of the infamous BSD advertising clause that was eventually removed when it became too unwieldy.

That license looks like it has potential, but I am not totally comfortable with it. Not that it matters since I have not really contributed to the hardware design yet. I like how it explicitly says the firmware is under a different license.

[Olaf.Mandel]

Before I reroute the FPGA again to incorporate the newest suggestions, I would like to get a final consensus on design rules like trace width, clearance, dril size, etc. This would also help li_gangyi and O_Shovah, I am sure.

So first, as we basically decided to go with pcbcart as our board supplier, here are their specs as seen in the ordering form. Stated are the selectable minimum sizes: larger is cheaper, but the price steps are surprisingly small (maybe not so small for the drills: didn't check).

Specification	Possible minimum values
Copper thickess, outer layers	35um, 70um, 105um, 140um
Copper thickess, inner layers	18um, 35um, 70um, 105um
Trace width / Clearance	0.10mm, 0.15mm, 0.20mm
Annular ring	0.10mm, 0.25mm
Hole diameter	0.10mm, 0.20mm, 0.30mm, 0.40mm

Starting from the FPGA BGA (in the FGG housing), as it is the smallest as far as I see so should drive the specs, we have first to look at the pad diameter: the datasheet specifies 0.4mm as the minimum diameter, but both the default library element and pusles recommendation are for 0.5mm.

The following table states different combinations that allow placing a via in the middle of four pads for the smaller pad size. The "Via" column is checked if this also works for the larger pad size. The "Routing" column is checked, if it is also possible to route a trace between two pads in the top layer for the larger pad size (this is always possible for the smaller pad size). The table is sorted in descending order by drill size, annular ring and trace width / clearance.

Drill size	Annulus	Trace width	Via	Routing
0.40	0.10	0.20	-	-
0.40	0.10	0.15	x	x
0.40	0.10	0.10	-	-
0.30	0.25	0.10	-	x
0.30	0.10	0.20	x	-
0.30	0.10	0.15	x	x
0.30	0.10	0.10	x	x
0.20	0.25	0.15	-	x
0.20	0.25	0.10	x	x
0.20	0.10	0.20	x	-
0.20	0.10	0.15	x	x
0.20	0.10	0.10	x	x
0.10	0.25	0.20	-	-
0.10	0.25	0.15	x	x
0.10	0.25	0.10	x	x
0.10	0.10	0.20	x	-
0.10	0.10	0.15	x	x
0.10	0.10	0.10	x	x

Any of the combinations given above works if we decide on 0.4mm pads. If we want to be safe and use 0.5mm pads, we need to have at least the Via column checked, better to have even the Routing column checked. Please give me your opinion on pad size and which design rules to use.

As for layer setup and other things, I think we now are in agreement to use the following setup:

• Layer 1: Component and routing layer. Polygons for large components with large currents
• Layer 2: Supply layer GND: no routing possible (prevented by Eagle)
• Layer 15: Routing layer, dominated by power polygons. VCCINT[01] for the FPGA and PSU, ?? for the MCU
• Layer 16: (Small) Component and routing layer. Polygons for areas with many connections (VCCIO for FPGAS, ?? for PSU and MCU)

The placement grid for components should be 50mil or 25mil. I am violating this with the caps on the backside of the FPGAs, at the moment.

Once we have agreement on this, it should be much easier to later merge the individual parts together.

[pusle]

Routing:
I would think a T junction when the line has reached the small board splitting to the two fpga's is no problem.
Just put a series resistor at the driver end (MCP).
For several sockets on a motherboard either use individual traces or resistors at the junction points feeding them to prevent ringing/standing waves.
If you want simplicity and the speed is just a few MHz you can just slow the edge rise time with a larger single resistor value at the driver side.

Routing straight out from one side of the fpga was in reference to the I/O's needed (spi etc). I assumed routed to a pcb edge connector? dimm?
All the I/O's you need are there. Rows 1 and 2 you can route without via's, just traces on the top layer.
Rows 3 and 4 with using vias to the bottom layer. Then you only have to route power, clock and jtag under/across the fpga area.



PCB spec, my suggestions:

trace width/clearance:                      0.15mm                I don't think there are any factories not capable of 0.15mm today and even home made pcb's with decent equipment can manage it.

Copper thickness, inner/outer layers:    35um                  This seems like industry standard and it's enough for this board. Sure the thicker the better but if you want more you usually have to pay some extra.

Hole diameter:                               0.20mm or 0.30mm    Please check with the pcb company about the number of layers you can have and board thickness for each diameter. 

Annular ring:                                as big as possible.     Without violating the clearance between the fpga balls.
                                                                               Even if you have to pay the 0.1mm price, you should make it larger so it's easier to manufacture and more factories can manage it.


0.15mm width/clearance is easy for all PCB manufactures I know of.
0.1mm annular ring and small drill sizes like 0.1 and 0.2mm through thick boards is much harder. or rather this is where there is a larger difference from factory to factory.


Using 0.4mm pads for the fpga should not be a problem. But as I stated previously with our pcb manufacturing clearning house we settled on 0.5mm.   0.45mm is also an option
And if you read about soldermask defined pads for fpga just ignore it. Always use cobber defined and pull the mask away as to not get any on the pad itself.
But not so much as to expose the via/traces between the pads and increase the risk of solder shorts. Check the solder mask precision they specify.




 

[O_Shovah]

Regarding the PCB specs i would propose the following:

Pads: 0.5mm just for the safe side regarding the BGA

Drill: 0.3mm Should provide the nessecary current safetyand needed for the 1:5 aspect ratio to get through the 1.2 mm board.

Annulus: 0.1mm  to accomplish the 0.5 mm Diameter and clearance

Trace with: 0.15mm

Cooper thickness: 35um should be suffiecient and is also for testing purpose

I also agree with the layer stackup.


I did a brief calculation at pcbcart for these specs. For a 150mmx75mmx1.2mm
I got a 65$ qoute for each board if we order 5 boards wich should be more than enough for the testing.

We should also define how may boards we  will order inthe first run and who is best fit to debug them. 

[li_gangyi]

How soon are we proposing to get these boards out? I need to clear some storage space for the parts and boards.

$65 is with or without the cost of populating these 5 boards?

[magik]

OK, so took me a day and a half, but I finally went through and read all 23 pages of this thread.  Kind of glossed over it, so I'm not 100% on what all the decisions are made, but I have a much better feel of where you guys are at in terms of the design and progress.

Some things i'd like to add to the discussion for now:

In terms of Xilinx licenses - as someone said above - Xilinx doesn't care too much where you get the software or license - as in the end you will require a Xilinx FPGA to program and that's really where they make their money.  If anyone cares I can show you where to obtain a less than reputable ( read: pirate ) ISE license for ISE 13 with everything unlocked ( including the LX150/T design targets )

The unconnected I/O are unimportant for this design.  You can tie them all to ground, you can tie them all to Vcc, you can leave them floating.  It doesn't matter - personally I'd say just leave them floating.  This design is not going to be requiring non-noisy I/O lines as we aren't going to be doing anything like a high speed bus on the I/O.  At my workplace we build industrial monitoring equipment and on a lot of our boards we just leave unconnected I/O hanging and set the ISE to either use a weak pull down or leave the I/O floating.  It's really not much of an issue unless you are requiring very high speed accurate I/O ( think 100-200MHz clock ranges ).  These settings can be found under right clicking on Generate Programming File -> Process Properties -> Configuration Options -> Unused IOB pins ( Pull Down, Pull Up, Floating )

Also, again I'm a bit unclear on how the JTAG is going to be set up.  But I would expect a JTAG header on every DIMM, or at least one JTAG somewhere with all FPGAs chained.  I would also probably expect a couple of LEDs.  You probably are going to want to put one between VCC and GND to show you that the baord has power.  You will probably also want an LED or two as debug outputs.  In my mind, I would also love to have a couple other test points as just unused I/O pins routed out to a TP - these are also very useful for debugging.  On the other hand, this design shouldn't require too much debugging as it's pretty dead simple - but in terms of future application/expansion, it may be helpful for debugging new features.  Also, typically there will be an LED or two somehow tied to the tx/rx lines of the USB bus so you can tell when communications is occurring.  I would love to be able to route all the unused I/O to pin headers or test points, but I agree with what has been said above, and the cost/complexity to do it is just not worth it.  Sure you'd be able to use the board as a spartan6 dev board, but I don't think that's the goal of this project.  So to keep PCB complexity down I agree with you guys - just route exactly what's needed, and then possibly add a handful more I/Os for debugging/indicators and then a few more that are brought out for future expansion  - either to DIMM pins or test points ( think extra comm protocols etc... ).  If not all DIMM pins are going to be routed ( not taken for power or I/O ) - I would also prefer to have a TP for each of these unused DIMM pins - that way we could deadbug new features or bug fixes this way.  If we leave just enough room for error that we can hack something on for this prototype it will save us a lot of time/effort later because it'll likely help us skip re-spinning.  I agree with what was said above that this is a prototype - it should have a slight excess of what's necessary to help us debug/fix any potential problems/errors we may make before the first spin.


I'm unsure about what internal clock rates any said miner design will be able to obtain inside the FPGA.  But I would guess it's going to be around 25-50 MHz.  I would probably advise against using the same 25 MHz crystal for the MCP and the FPGAs just because to get 25MHz to 100 MHz using a PLL in the FPGA will require using the CLK_FX output to multiply the input clock and this is generally a noisier clock solution.  It's definitely doable, but maybe not the best implementation.  I don't have any experience with Spartan6 devices either ( we use a lot of Spartan3s ), so I'm unsure if it's possible to get useful computation done in this chip at higher clock rates.  One thing I definitely do know is you will want to route your clock input into one of the global clock pins - basically there are certain pins in each bank that route closer/more directly to the BUFGMUXs that control the quadrant clock lines.  These clock lines are the best lines to use for distribution clocks throughout the FPGA as they are built for this function and provide the least amount of clock skew along these lines.  You can definitely still take a clock in on any I/O pad and route it to one of these BUFGMUXs - it's just sometimes that trace path ( between non-clock I/O and BUFGMUX ) is not the most optimal path.  There are a bunch of different pins you can use, but I would stray away from the quadrant/side locked clock inputs and just use one of the global clock inputs ( there should be at least 4 ).  The quadrant/side clocks are useful if you partition your FPGA device into regions based on clock domains - then you can free up global clock resources and only use clocks in one quadrant or one side if needed - but this isn't necessary for our design - I envision one main clock for the hashing engine, and potentially one other clock for communications.  The hashing engine clock is the only one I'm worried about - the comm clock could be derived internally off a counter as it's not fast speed or touches a lot of resources.  If you'd like to read more up on it -ug382.pdf describes clocking mechanisms for the Spartan6 family.  

TL;DR So when you are looking to route the clock to the FPGA - make sure you connect to a GCLK I/O pin.

[O_Shovah]

@li_gangyi:

I m not sure of the timeframe. It's mostly dependent on how fast we get a final testboard layout so i would like to return this question also to you and Olaf.Mandel
I hope we may finalise the FPGA section and the implementation of all parts next week but i m not the one to guarantee that.

The 65$ are for the boards alone without any fingers and without any population.(little numbers make them costly)

I hope we may still take advantage of you offer to populate the boards at you place.
In that case we should also define how to get all the parts to you and pay them.

In my calculation we would roughly get  70$ ( board and shipping) + 160$ ( Spartan 6 Lx150 FGG484) + 100$(power supply) + 50$(MSP430,Connectors,small parts) = 380$ or 270 €
These numbers may cetainly varie depending on parts sources , so please correct them according to your estimations.

I will fund at least one of these boards and maybe a second one when months salary gets in. But i hope also somebody else will participate here.

[magik]

I think another thing to note is locations of everyone in this project.  If you plan on shipping these things around to different people for different things the shipping costs alone may become very large.  I'm in the USA, California.  But it sounds like a lot of you guys are in Europe or Asia... I hate to say it because it may mean it will be more difficult for me to get a board here in the US, but it almost sounds like you guys in Euro/Asia are closer together - and it might make more sense to get everything done semi-close to you guys, e.g. board fab/assembly/debugging.  I'd love to get my hands on one of these myself, so it kind of sucks if us US guys are the minority, but it goes both ways too....  But basically to reduce costs we are forced to centralize things - we can't not buy all the boards at once without it costing much more $$$, same goes for the part orders.  Assembly may not be as bad as li_gangyi seems to have that covered for now.  But again, if he's doing the assembly, and correct me if I'm wrong, he's in Singapore, that may be part of the decision right there.  I could do any soldering/assembly myself, except for the reflow/bga stuff.

I don't mind putting up some money for prototyping, but without getting any hardware myself I'd be much less likely to put money up ( I imagine I'd only want to part with USD$100-$200 if it meant I wouldn't see anything for a while - plus I'd love it if that meant I got some sort of discount later or guaranteed first production run etc... ).  If I knew I was going to get hardware for this, I may be more willing to spend around USD$300-$500 for prototyping.

Here's a thought - how hard are LX150's to re-sell.  Maybe we should try to acquire enough funds to get the first price break on a batch of 10 of those?  It sounds like we're going to need at least 1-2 prototypes, but it's sounding almost more like we might make 5-6 and ship them around to that various devs.  Dunno how much of a price savings it is, but if everyone is very convinced that's the FPGA we're going to use, then maybe this might be a good cost savings investment now?

edit: seems like @ digikey there is no bulk discounting at all for these chips

On another note to the FPGA devs out here - what FPGA code are we currently going with?  I havn't kept up with the Open Source FPGA Miner project in a bit, have any major improvements be made?  I was thinking about setting up some simulation test benches in Xilinx and trying to further optimize what they've done.  IIRC the design they have made IMO doesn't perfectly match up with the Xilinx architecture - and that's likely why people have been unable to fully maximize/optimize a hashing core for this chip.  I think Xilinx does much better with faster clocks and smaller logic - but I'm by far no guru or expert, this is just my gut feeling - we'd really have to tear deep down into timing analysis and RTL diagrams to really optimize well.

[magik]

FPGA Power considerations

Spartan 6 FPGA Power Management
http://www.xilinx.com/support/documentation/user_guides/ug394.pdf

The FPGA can only enter suspend mode if enabled in the configuration bitstream (see
Enable the Suspend Feature and Glitch Filtering, page 14). The SUSPEND pin must be Low
during power up and configuration. Once enabled through the bitstream, and the
SUSPEND_SYNC primitive is not present in the design, when the SUSPEND pin is
asserted, the FPGA unconditionally and quickly enters suspend mode.
...
There are four possible ways to exit suspend mode in a powered system:
• Drive the SUSPEND input Low, exiting suspend mode.
• If multi-pin wake-up mode is enabled, drive the SUSPEND input Low and then assert
any one of the user enabled SCP pins.
• Pulse the PROGRAM_B input Low to reset the FPGA and cause the FPGA to
reprogram.
• Power cycle the FPGA, causing the FPGA to reprogram.

sounds pretty simple to put this guy into suspend, and it will retain it's programming in that state too, and all that's needed is to enable it in the bitstream and to assert the SUSPEND pin when you want it to go to sleep.  Sounds like you guys want to tie that to the MCP so then it can control if the FPGA is on or not. 

there is also a hibernate mode, but it basically just sounds like a way to safer way to power up/down in hot-swapping situations

What is the configuration consensus again?  Bit banging the MCP's I/O and a JTAG chain of the 2 FPGAs?

it also says:

Saving Power
...
The lowest power state is the quiescent state with no inputs toggling, all outputs disabled,
and no pull-up or pull-down resistors in use.

[li_gangyi]

I can fund all 5 initial boards and then some1 come up with a simple test procedure, say a Jtag boundary scan, I run the tests and if they pass I sell the board at cost + shipping to whoever needs them. How's that?

Regarding the clk source, I know the AVnet boards that the guys over on the Open Source FPGA thread are using, have an external 100Mhz oscillator.

http://www.files.em.avnet.com/files/178/xlx_s6_lx150t_dev-sch-revd090810.pdf

Sheet 20 shows the clocks. (Thanks to Fpgaminer for pointing me in the right direction.)

We should go with this known working solution.

Once Olaf is done, including the MSP430, I can route in the PSU, I think we should leave out the external LDO for the MSP for now and just use suspend, to keep it simple.

Then we'd be able to let every1 vet through the design, spot any major errors and move on to production.