Topic: Modular FPGA Miner Hardware Design Development - page 23. (Read 119276 times)

Well, then that's a different design philosophy. I would argue against that idea, because the cost of the motherboard would be prohibitive to someone who is curious about FPGA mining, but not sure they want to invest enough to buy many daughterboards, thus making the motherboard worth it.

The real question is how much is saved by moving all of this stuff off the daughterboard and onto the motherboard?

A bit offtopic..  you guys using a poll to decide which one to use in prototype ..  why not build and test both ? See what works best and what could be changed to make it better.

Also, here's a link to the preferred FPGA with no minimum order, although there is a 7 week lead time:

http://avnetexpress.avnet.com/store/em/EMController/_/A-12942478?action=part&catalogId=500201&langId=-1&storeId=500201

I also thought the point of this was to make plugin boards for the fpga's since we don't have sockets for them.

Then the DIMM board should be only the FPGA + decoupling with a standarized pinout.

Provide lots of power pins with feedback sense for both VCC and GND + a handfull of I/O's and the configuration bus (serial or jtag).
Then all the other design choices are left up to the mainboard/backbone and the firmware you load.

There will be lots of different mainboards, but then they are all compatible with most/all DIMM fpga modules.
Add a few "Keying" pins for voltage select+ID and you can support different fpga families too  (even future ones)

oh and perhaps throw in a I2C temp sensor & voltage monitor just for kicks

Ethernet for standalone mining is definitely a good idea. I was thinking of another possibility for this, though, which would undoubtedly be cheaper than making this board and implementing the ethernet yourself: use a Pogoplug or Dockstar! These are basically a USB to Ethernet link, running a Linux operating system. If you install the Archlinux build for it (I've done this on a Dockstar and it's very easy) you can run whatever software you like on it.

As for the mechanical benefits of a backplane, I think stacking these cards up with standoffs would make for a nice, sturdy unit. For example: http://www.zerksus.com/images/overlay_stack.jpg

Stick that into an enclosure with a USB hub inside it and you've got a nice little mining box that you can set next to your PC. Want it standalone? Put a Pogoplug inside that box!

That's my feeling about it, but I suppose nothing would stop one from using the backplane/motherboard if you really wanted it. The only important question will be cost. PCB production generally costs by the area, so such a large board could get expensive.

Well, when its just for density, I'd rather take a wooden board and cut some grooves ontop of it, gives me a place to put the FPGA boards for free.

Please, dont get me wrong here, I really like the whole idea of a modular assembly, but I just can't see the point in making a backpane that just serves as a mechanical mounting platform.

On other idea: if you plan to put an USB port onto every doughter card, wouldn't it be easyer, to forget about all that SPI and I2C busses and just route the individual USB conectors of the FPGA boards  to an USB hub onto the backpane, which will than connect to the host PC by only one USB port?

I think one of the major benefits of a backplane is density. You can pack the modules in closer together without them getting scattered all over the place every time you bump the table.

I have little industry experience as well

Edit: By electrical, you mean circuits over 50V/20A?

Well, thats exactly the point and it was mentioned before. The whole thing is meant to be cost effective, so who would invest in a backpane that serves no purpose? I mean people who would get such a card really dont care if they have to wire them up seperatly onto a usb hub for 5 bucks or on a backpane that will be 50 bucks or more, I'm pretty sure they'll go for the cheaper alternative, it the backpace doesn't add any kind of feauture... The only reason to design a backpane, would be if it had some additional functionality, nobody is going to buy it, if its just a nice way to stack up the doughterboards.
And as far as I see it, that fuctionality would be Ethernet!

I cant imagine implementing an ethernet controller is too hard for people that can programm FPGAs, for example for Arduino (which was mentioned before and although feautures SPI, I2C etc) there are readily available schematics and libraries just for that purpose: http://www.practicalarduino.com/freetronics/EtherTen-schematic-worksheet.pdf

btw, I have been following this thread from the beginning, but since I am only in my third semester of electical engineering, I really dont have to much to say about most of the specs you're discussing here, please dont get me wrong here, I really apreciate your effort but i really think you should consider to develope a backpane that gives people a reason to buy it in the first place.

Each board shall have a USB connector anyway (see first post)

The motherboard will then serve as housing and the hub for the USB,SPI and JTAG connections.If you want to run a single daughterboard you are free to do that.
But i asume you dont want to use a number of USB cables equivalent to the number of boards you use as their number increases.
And in a later stage it will feature a cpu and ethernet connection for independent mining.

Maybe I'm missing something, but if you're going to the trouble of putting an MCU on the DIMMs (maybe daughter board is a better term), why would you need the backplanes at all? Why not just give each board a USB port?

No, just use a software implementation of JTAG! If you use a fancy general purpose chip like the MSP430, you should only use extra chips for interfacing if you really have to. Let's assume 20 clock cycles for each state change of a bit-banged interface (may be low, may be high: does anyone have a more educated guess?): if you clock the MSP430 with its max clock of 25MHz, this gives you a JTAG clock of 625kHz. Even for the default MCU clock of 8MHz, you still get 200kHz (f_JTAG=f_MCU/(2*20)). That may be good enough, if you can pack the bit-banging into that tight a loop.


I looked into this a bit further: the BSL is write protected, but the protection can be removed by software. After removing it, any garbage can be written into the BSL. This can normally be recovered via JTAG, unless you wrote garbage into the BSL!!! Specifically, the JTAG interface gets permanently disabled if memory-locations 0x17FC-0x17FF of the BSL contain anything but all 0s or all 1s. I have never had an MSP430F5xx in hand, can someone else confirm this?


I still feel that if an MCU is put on the DIMM, you shouldn't route the low level communication to the FPGAs onto the bus. Only connections to the MCU should go there. Let's say: USB for the dumb backplanes and SPI for backplanes with their own CPU, or no USB at all. It's a decision between putting a USB hub chip on the simple backplanes or putting an MCU on the backplanes. In general I just want to reduce the ways how we communicate with the DIMM, as more protocols means more testing required.

Ok, i didn't see that  i only had a brief look into the documentation. This would mean we need another IC as the masterfor JTAG.

• Not ready made: you need to read through the example code and write your own firmware.    ->I haven't had a look on the volume of code needed but i asume this may be bearable
• Not sure about this, but: Possibility to brick your DIMM by accidentally overwriting the BSL (can rescue with JTAG pins?).  -> I asume this may be rewriten by the JATG
• Did I mention you have to write your own firmware? This is worth two entries in this list    -> same as above i'm not aware of the workamount needed yet
• No JTAG master serial engine (as mentioned above).  -> if used on every DIMM as slave device we could use a IC either just supporting JTAG master or both JTAG and SPI master on the motherboard

Using an MSP like yours also seems to be a good idea.I would also like to have somebody more experienced making a suggestion.

Can you rephrase that? Which duplex do you mean and what does "flashing an I/O (port?)" mean?


Either I missed something, or it only has a JTAG slave, not a JTAG master. You could emulate a master by bit-banging GPIOs, but that is slower (compared to a dedicated serial engine). As I see it:

Advantages over FT2232H:

• Can handle things like buffering the next workload until FPGA is ready (minimum dead time). This could be done in VHDL on the FPGA, but in C it is easier (for me at least).
• Tri-stating any IOs should be easy.
• Includes ADC for voltage monitor and temperature guard.
• Can act as a client towards the DIMM bus (e.g. via SPI) and pass the data through to internal busses (whatever format).
• No need for a dedicated EEPROM (I²C or otherwise): functionality can be integrated here.
• USB example code available from TI after registering.
• IO voltage of 2.5V possible.

Disadvantages compared to FT2232H:

• Not ready made: you need to read through the example code and write your own firmware.
• Not sure about this, but: Possibility to brick your DIMM by accidentally overwriting the BSL (can rescue with JTAG pins?).
• Did I mention you have to write your own firmware? This is worth two entries in this list
• No JTAG master serial engine (as mentioned above).

If using an MSP, maybe the MSP430F5528IRGCT may be a better choice: the housing is smaller and it is a few cents less.

Any other comments about using an MPU instead of a purpose-made USB interface? Maybe someone wants to add their favourite MPU family? I did a very little programming with a smaller MSP430 before, but this would be a much larger code base for me.

All in all it is interesting, if we find example schematics in an application note and if the programming turns out to be manageable. If we have an intelligent chip on each DIMM, though, why do we need so many protocols on the bus?

Hello

I've read into the BUS matter a littel and came to the conclusion i will prefere the SPI system with independent slaves over the I2C.
The dulplex could be used for flashing I/O and sensor (temperature?) communication.
It provides plenty of bandwith overhead and higher frequencies(lower latencys)at a fairly low price.
Also i've been told by some collagues at university that SPI is a lot easier to implement in comparison to I2C.


I found a IC wich would provide us with JTAG, SPI (also I2C if needed) and USB:  http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=296-27306-6-ND

Please have a look and tell me if it seems suitable (i dont know if its overpowered).

@Olaf.Mandel    I would also like to put the USB, SPI and JTAG  on the BUS

Let me try to collect the different suggestions and comments made on bus design till now:

Protocols suggested to be on bus:

• JTAG
• I²C
• SPI
• USB

Voiced preferences (by name, alphabetically sorted), Edited:

• lame.duck: Have I²C or SPI, as JTAG produces errors sometimes. SPI is preferred. Opinion on USB?
• O_Shovah: Have JTAG, SPI and USB on the bus.
• TheSeven: Put JTAG, I²C and USB on the bus, use I²C as an option to communicate with FPGAs to have some flexibility. Use of busses on backplane: USB exclusively at first, the others later for intelligent backplanes. Don't connect all DIMMs into one long JTAG chain, use several independent ones. Don't use SPI because of pin-count and single-master design.

Please correct me if I misrepresented your preferences!

My own opinion after some waffling back and forth: USB as the preferred connection. No strong opinion of SPI vs. I²C. Adding JTAG and any serial interface to the bus complicates the DIMM design, as there is no easy way to tri-state the FT2232D/Hs outputs (the datasheet is not very clear on this: can someone confirm this?). So while not adamantly against JTAG and serial on bus, I think that implementing USB in the CPU of an intelligent backplane is probably better than adding tristate drivers to the DIMMs.

I can't speak to the license you get with that board, but I can build designs for the LX150-N3. I have a full license for the Xilinx suite. If anyone needs test designs built, let me know.

Hello

Having decided on the FPGA (XC6SLX150-N3CSG484C),we should decide our BUS system now.
Seems it has been mostly dicussed to use a combination of iC2 and JTAG.We should determine in wich way and wich extend we will use them and wich hardware needed.

Please proceed with this step without me.
I will be back with you on friday afther my next test.

Can you check, please? And also look which variants (transceivers, memory controller, speed grade, package) are supported. If the license is good for all LX150 then I might also be interested in purchasing the developer board... If the license is not valid, you probably don't even see the other chips in the drop-down lists for the device settings. But if they are there, please do a test-compile to make sure. Thanks!


Didn't think of that one. So we have six parameters to select the correct chip, right?

And we want the XC6SLX150-N3CSG484C, right? It's 111.29EUR at Avnet, but is's non-stock. The cheapest on-stock chip with speed grade 3 I can find is the XC6SLX150-3FGG484C: 344 available at Avnet for 122.68EUR and 120 available at Digikey for 134.75EUR.

Hello Everybody

The poll is finished.We have got a clear decission. The Xilinx Spartan 6 LX150 is the winner with 17 votes angainst 7 votes for the Altera Cyclone IV 75k.

So the FPGA is decided on. We shall proceed with the BUS system development.

JTAG and I2C in combination seem to be the most promising aproaches as i've read so far.
But details are to be disscussed further i guess.

It's an LX150T, and you may be right that the license won't let me compile for the preferred LX150. These are things I dislike about Xilinx ... :/

On a related note, for the specific device, there is a -N3 variant:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=XC6SLX150-N3FGG484C-ND

It's cheaper, because it doesn't have the on-chip memory controlled (which an FPGA miner does not need); $158.75 USD, 60 MOQ, as of this post. That's $111 Euros in a direct conversion, so a few dollars cheaper than the one listed in the OP right now. The same applies to the other Xilinx chips, so look for the -N3 variants of those as well.