Quote from: phillipsjk on July 21, 2011, 11:46:00 PM

It's worse than that: we want to be able to bring down the FPGAs deliberately if they are drawing too much power. How much data would need to be moved across the bus every time we do this? So far the assumption is that bandwidth is negligable. Edit: 1.6MB can take minutes at standard serial speeds.

And that's a spartan 3E i'm talking about - I imagine the 6 series has a lot more cells that need to be programmed.

Quote

Another reason for using the MCU is that it saves space on the FPGA for hashing. The MCU can translate between USB and SPI for example.

Edit2: MCUs can also be reprogrammed without software costing $3000 to produce the bitstream. This makes things like minor protocol changes or calibrating the built-in temperature sensor easy.

It's fairly easy to get an evaluation license for Xilinx - and I think it's even pretty easy to just re-generate more if you have more e-mail addresses.... Nobody in the industry really pays for Xilinx licenses - they just give them away when you buy chips typically - but the bad news is that it's unlikely they will even give you a license if you aren't purchasing semi-bulk. I would guess it'd be kind of hard for hobbyists to nab a non-eval license.

So what exactly is the purpose of powering down FPGAs? If this was my mining rig, I'd be running it at 100% at all times. I see you mentioned temperature sensor - so maybe in places without adequate cooling or if a cooling system breaks you might want to turn things off... again I think I need to see a bit more of what you guys have designed so far.

The amount of FPGA space you will use for simple things like comm protocols is nearly negligible - especially when these modules are running at much reduced clock rates compared to the important stuff ( the hashing engine ). Another thing to think about - see what other FPGAs in the family have the same foot-print. A prototype board doesn't need to have the most expensive FPGA if a cheaper smaller FPGA can handle 1 hash engine, and this may help a little in the first round of prototyping.

I guess if the MCU is very cheap it's not that much of a hit to have one... but you are adding one more layer of complexity to the design. PC <==> USB chip <==> MCU <==> FPGA. And the MCU itself will need to have code written for it... I guess it matters what you really want the MCU to be able to accomplish. Or what you think the MCU may be able to accomplish in the long run.

I think I need a bit more info on what the high level design architecture is going to be. How does the backplane/motherboard fit into this if each DIMM module has it's own MCU and USB controller? I would imagine ideally you would put these type of comm things onto the backplane/mobo itself - but I understand in terms of prototyping and development it'd be easier to have it on the module itself so you wouldn't need a backplane to debug/develop with it.

Also, I'd like to mention that I'd be willing to throw up a bit of cash ( couple hundred dollars ) when prototyping time comes. And I am interested in helping with the project. I have access to Xilinx ISE tools, and all kinds of hardware equipment ( logic analyzers, power supplies, o-scopes, sig gens, etc... ). I am also a hobby programmer with experience in C/C++, Java, python, perl, PHP, etc... Trained as an EE in school, but focused more on computer engineering, hence why I'm now a firmware engineer. But yeah I'd love to help develop this with you guys and I have some money I could pool together with you guys to get the first round running. I don't do much of the hardware layout - but I can always ask my coworkers to take a look at things.