Modular FPGA Miner Hardware Design Development

[fizzisist]

fpgaminer, you're right, we are set up to use the Slave Serial Mode as on page 26. I believe Olaf.Mandel did this work, but he seems to MIA lately.

The thing about the F55xx series, is that they have hardware serial interfaces. You can bit-bang the outputs of the Launchpad, but that might be more work than it's really worth... Since we don't have a F55xx board, we're kinda out of luck until we get this real board made. Also, not having access to the pins you need on your dev board, it gets even worse.

In that respect, I think switching to a JTAG interface is a great idea. Why not? Hopefully Olaf will come back and answer some of these questions better than me before you get too far on the wrong track (in case I'm missing some reason not to do it this way).

Another option is to add a flash IC to the board, and use the MCU to reprogram that when necessary. Would this be easier/better? As ngzhang has pointed out, these chips are cheap.

[inh]

Regarding heat dissipation, I was going to recommend these until I realized they are still quite a bit smaller than the FPGA itself. Still, newegg has some others that might work well...



http://www.newegg.com/Product/Product.aspx?Item=N82E16835108071

[fpgaminer]

fizzisist: Yeah, I doubt anything I write now will ultimately be used as-is, but it will likely make good ground-work, and heck it shouldn't take me that long. The Python side of things will probably be the most useful

If the code doesn't end up getting used, add it to my pile of incomplete hobby projects

[pusle]

WoW boards!   


http://www.bitcoinminer.com/post/9268040136

http://fillwithcoolblogname.blogspot.com/2011/08/heres-where-its-at-now.html

[rph]

Hope this is still alive. It got very quiet in here.

[twinpeaks]

Hi,
Just wanted to let you know that http://tideals.com/ offers today the MSP-EXP430F5529 USB Experimenter’s Board for half the price with free international shipping while supplies last. Could maybe be useful.

twinpeaks

[inh]

Hi,
Just wanted to let you know that http://tideals.com/ offers today the MSP-EXP430F5529 USB Experimenter’s Board for half the price with free international shipping while supplies last. Could maybe be useful.

twinpeaks

Thanks! Snatched one up

[njloof]

Hope this is still alive. It got very quiet in here.

This thread maybe took some of the air out of the room:
https://bitcointalk.org/index.php?topic=40047.0

[O_Shovah]

Hello everybody.

So just to give word. this thread isn't obsolete afther all. But we are desperatly seeking  software and hardware developers willing to contribute again.

The main goal before getting to a prototype stage is to posses a code for the MSP 430 chip in order to access our fpga's.

So anybody interested and still supporting us  please post so or give me a pm.

regards

Jens 

[phillipsjk]

My situation has not changed since my PM. What timeline were you thinking of?

Back in June I decided I was not interested in buying mining hardware this year: getting a stable Internet connection with IPv6 support is more important for me. I don't have any bitcoins to my name, and am not mining, so the current low prices are not really bothering me. However, I want this project to succeed, and I know enough to to know you can't ship the prototypes without the software for the microcontroller.

I also know the software will take time to write. It is tedious and safety-critical: just the type of programming I feel I need to learn how to do (Insert rant about inherently insecure computers here). The code is safety critical, because even if it does not burn your house down when a temperature sensor fails, apparently flashing the wrong image can damage the expensive FPGA.

TL;DR: I think I can commit about 3 hours a week almost immediately. I suppose a good first step would be to manually review all of the pin-outs on the proposed PCB.

[rph]

http://inisyn.org/src/xup/ might be useful as a SW reference, if you haven't seen it yet:

-rph

[inh]

I got my MSP430F5529 dev board in yesterday and am getting setup to start cutting code for it. My goal is to get SPI for the FPGAs and a serial connection over USB working. I'm busy with school and work like everyone else but I can spend a few hours on weeknights and weekends working on this. I've done microcontroller programming and SPI interfaces before, so this shouldn't be too hard

[phillipsjk]

http://inisyn.org/src/xup/ might be useful as a SW reference, if you haven't seen it yet:

-rph

No I hadn't seen that. It looks like it is not directly applicable because it assumes a programming cable using a different MCU.

I spent my first 3 hour block of time taking notes on the current state of the project.

The project appears to be using the Xilinx Spartan 6 XC6SLX150-3FGG484C Source, and the Texas Instruments MSP430F5529 , QFP80 package Source. I have not dug out all of the relevant documentation yet, but when I do, I will post a list.

Does the new part resolve questions  Olaf.Mandel raised about the need to multiplex SPI?

ngzhang's post about bitstream sizes concerns me as well. The chosen part has a bitstream weighing in at just over 4MiB. Where do we want to store it? I think the feeling is "on the host". However, this is supposed to be a modular miner with possibly different modules loaded on the same board. I feel we need to do one of:

• Store the bitstream(s) on a flash chip as ngzhang suggested; bitstream updates would be written to the fash by the MCU.
• Work out some way to uniquely indentify each module (model/revison), such that the host knows which image to load. Edit: I suppose the USB ID could be used for that.

[inh]

http://inisyn.org/src/xup/ might be useful as a SW reference, if you haven't seen it yet:

-rph

No I hadn't seen that. It looks like it is not directly applicable because it assumes a programming cable using a different MCU.

I spent my first 3 hour block of time taking notes on the current state of the project.

The project appears to be using the Xilinx Spartan 6 XC6SLX150-3FGG484C Source, and the Texas Instruments MSP430F5529 , QFP80 package Source. I have not dug out all of the relevant documentation yet, but when I do, I will post a list.

Does the new part resolve questions  Olaf.Mandel raised about the need to multiplex SPI?

ngzhang's post about bitstream sizes concerns me as well. The chosen part has a bitstream weighing in at just over 4MiB. Where do we want to store it? I think the feeling is "on the host". However, this is supposed to be a modular miner with possibly different modules loaded on the same board. I feel we need to do one of:

• Store the bitstream(s) on a flash chip as ngzhang suggested; bitstream updates would be written to the fash by the MCU.
• Work out some way to uniquely indentify each module (model/revison), such that the host knows which image to load. Edit: I suppose the USB ID could be used for that.

My vote is to use an onboard SPI serial flash (~$4 USD) which can configure all FPGAs on the DIMM card simultaneously. See this appnote: http://www.xilinx.com/support/documentation/application_notes/xapp951.pdf

The μC can configure the flash via it's USB connection, and it probably wont be too hard to have the μC configure the FPGAs directly in lieu of a flash memory IC.

I think as long as we focus on keeping the DIMM interface the same, any combination of FPGAs makes and models can be setup to work together. Perhaps on the main backplane bus (SPI/USB/whatever) (my vote is SPI) we can have a standard protocol and one feature of this can be a getInfo request where each DIMM module spits out number and types of FPGAs, etc etc..

I'm setup to compile code for the MSP430 now, working on uploading and debugging at the moment. Considering buying a ztex FPGA module to do MSP <-> Spartan6 communication tests. Is anyone aware of an XC6SLX150-3 dev board that comes out to less than $600 after shipping to the US besides the ztex?

[O_Shovah]

http://inisyn.org/src/xup/ might be useful as a SW reference, if you haven't seen it yet:

-rph

No I hadn't seen that. It looks like it is not directly applicable because it assumes a programming cable using a different MCU.

I spent my first 3 hour block of time taking notes on the current state of the project.

The project appears to be using the Xilinx Spartan 6 XC6SLX150-3FGG484C Source, and the Texas Instruments MSP430F5529 , QFP80 package Source. I have not dug out all of the relevant documentation yet, but when I do, I will post a list.

Does the new part resolve questions  Olaf.Mandel raised about the need to multiplex SPI?

ngzhang's post about bitstream sizes concerns me as well. The chosen part has a bitstream weighing in at just over 4MiB. Where do we want to store it? I think the feeling is "on the host". However, this is supposed to be a modular miner with possibly different modules loaded on the same board. I feel we need to do one of:

• Store the bitstream(s) on a flash chip as ngzhang suggested; bitstream updates would be written to the fash by the MCU.
• Work out some way to uniquely indentify each module (model/revison), such that the host knows which image to load. Edit: I suppose the USB ID could be used for that.

My vote is to use an onboard SPI serial flash (~$4 USD) which can configure all FPGAs on the DIMM card simultaneously. See this appnote: http://www.xilinx.com/support/documentation/application_notes/xapp951.pdf

I fully second that aproach. Has been already disscussed but seems to have been forgotten.

The μC can configure the flash via it's USB connection, and it probably wont be too hard to have the μC configure the FPGAs directly in lieu of a flash memory IC.

I think as long as we focus on keeping the DIMM interface the same, any combination of FPGAs makes and models can be setup to work together. Perhaps on the main backplane bus (SPI/USB/whatever) (my vote is SPI) we can have a standard protocol and one feature of this can be a getInfo request where each DIMM module spits out number and types of FPGAs, etc etc..

Yes SPI is the intended interface for the backplane communication. So with the flash located on each DIMM and a standartised protocol we should be abled to create a backplane wich is independent of the types of DIMM's located on it.

I'm setup to compile code for the MSP430 now, working on uploading and debugging at the moment. Considering buying a ztex FPGA module to do MSP <-> Spartan6 communication tests. Is anyone aware of an XC6SLX150-3 dev board that comes out to less than $600 after shipping to the US besides the ztex?

Hey  makes me glad something  is happening again.
I will order one of these MSP 430 boards too. But due to my student budget i will not invest in an FPGS eval board in addition ( i like to spare some money for the real prototype).

But also we should produce one working DIMM before getting to the motherboard or we might end up splitting our efforts to widely at one time.

@ both of you :  How about your electronic hardware knowledge ?
I could need some additional eyes reviewing our current layout and routing in eagle.
@phillipsjk  Maybe you could give me your email adress so i may add you to the dropboxfolder

[phillipsjk]

Thinking about it, I think we can get away without the flash: It would make it slightly easier to use the DIMM for things other than bitcoin. On the other hand, waking up from sleep/suspend/off mode would be a lot simpler if things got loaded from flash automatically.

In either case, you need the boards to be able to identify their make/model for bitstream updates.

You can email me at: bitcoin@example.com, where example.com is the domain of my personal website. My OpenPGP fingerprint is CBDE CFB6 BB6A 2BB5 FDE1 01C5 3CF6 0C5E 1CFD A27B (SHA-1, June 28 2012 expiry). My public key is also on my website; I posted the fingerprint here in case my ISP, webhost or your ISP tries to pull a fast one (You access this site using HTTPS, right?).

I took a two year electronics course, which included a final project using the Motorolla (now Freescale) MC68HC11E1 Microprocessor. I ended up going through my code line-by-line to check for software errors: I had hardware errors as well . I don't really have any specific electronic work experience though. I have been trying to keep up my soldering skills though.

[O_Shovah]

My MSP430 dev board is ordered.

Im currently reviewing the piouts and layouts in the eagle files to get me back into the hardware matter.
Has anybody noticed any faults or irregularyties by now ?

[daphreak]

Hi All,

I'm interested in helping out with hardware or software dev wherever there is need. I'm a EE so I have some experience with designing/manufacturing pcb's and have worked with FPGA's and various uC's.

It seems there is a lot of work going towards the master hardware and I would like to help out. Is there an interest in having the master be a stand-alone ethernet connected device? It seems like this could add a lot of flexibility to ones mining setup.

I have a lpcxpresso board (lpc1769) here and a spartan3 dev kit that I could easily begin prototyping an ethernet master on and practice talking to the SPI interface on the fpga. However in this thread there is some momentum in the msp430 direction and I dont want to branch the effort. I may just try to get some JSON action running on the uIP stack and that should be somewhat portable to other parts.

Some comments on the latest stuff in the thread:

Has the global JTAG chain been abandoned? If not you can use the JTAG ID's to decide which bitstream to load for each device. Your master will need some bulk storage for all the bitstreams but it will be cheaper than each FPGA having its own config memory. May be a little slow without a small cpld/fpga to accelerate things but if you are only rebooting every once in a while it wouldn't matter.

Anyway, let me know if/where I can help.

[makomk]

I have a lpcxpresso board (lpc1769) here and a spartan3 dev kit that I could easily begin prototyping an ethernet master on and practice talking to the SPI interface on the fpga. However in this thread there is some momentum in the msp430 direction and I dont want to branch the effort. I may just try to get some JSON action running on the uIP stack and that should be somewhat portable to other parts.

Heh, I was vaguely contemplating trying this too. Don't think there is an SPI-enabled FPGA design yet that I know of though...

[daphreak]

uC's have UART's as well so I could use the serial interface as a holdover.