Topic: Modular FPGA Miner Hardware Design Development - page 2. (Read 119276 times)
Wow. Respect.
Nice to see you making such huge progress ngzhang.
Seems your outrunning us in development.
How do you intend to go on with this board ?
Will you share some details or is it not to be published or inbound to our project ?
Seems your outrunning us in development.
How do you intend to go on with this board ?
Will you share some details or is it not to be published or inbound to our project ?
Too tired these days, go to sleep after this pic.
My MSP 430 devboard just got here.
Got the SPI code running so far.
And just another thougt why im angainst generalising the board design for other applications than bitcoin.
As far as i see all other devboards that are also meant for other applications not only feature high bandwith databuses alike PCIe,
but also locate a lot of high speed memory like DDR 2 or 3 on the board.
The need for additional high speed memory would make our price bill burst up.
And i'm not the one who is going to implement the SPD DDR control logic on the board ( 480 pins...).
Got the SPI code running so far.
And just another thougt why im angainst generalising the board design for other applications than bitcoin.
As far as i see all other devboards that are also meant for other applications not only feature high bandwith databuses alike PCIe,
but also locate a lot of high speed memory like DDR 2 or 3 on the board.
The need for additional high speed memory would make our price bill burst up.
And i'm not the one who is going to implement the SPD DDR control logic on the board ( 480 pins...).
PM sent.
I will look at the existing design so I can understand the plan for the pinout of these cards better. Sounds like my earlier assumptions that there would be lots of spare IO were wrong.
In the mean time, I think I am going to make a Spartan-6 LX4 (QFP) design with just JTAG and some IO brought out to headers. Basically I want a cheap Spartan-6 to throw some bits at on JTAG. I will probably make 1 or 2 for myself because I don't have a dev board for anything in this series. If everything goes smoothly I should have more accurate price figures by the end of the week but I'm thinking <$30 for it completed. If anyone wants one PM me so I can figure out how many I am going to make.
I will look at the existing design so I can understand the plan for the pinout of these cards better. Sounds like my earlier assumptions that there would be lots of spare IO were wrong.
In the mean time, I think I am going to make a Spartan-6 LX4 (QFP) design with just JTAG and some IO brought out to headers. Basically I want a cheap Spartan-6 to throw some bits at on JTAG. I will probably make 1 or 2 for myself because I don't have a dev board for anything in this series. If everything goes smoothly I should have more accurate price figures by the end of the week but I'm thinking <$30 for it completed. If anyone wants one PM me so I can figure out how many I am going to make.
@ daphreak
K so we see the same ARM technology for that purpose so far.
Reagarding the Layouts. We share a dropboxfolder and use eagle to create the layouts.
Please pm me your email adress so i may add you to the folder so you can have a look on the layouts and make improvements.
Reagarding the free I/O lines; We were supposed to use a DIMM 240 Pin connector.
This should provide the bus connection to the motherboard and the power supply with the 12V rails as you might have read.
( The molex and barrel connectors were meant for standalone purpose or for future applications with more FPGA's an higher currents)
There already has been a huge disscussion if the number of pinns used for the current is sufficient or not.
So if we strip away another 60 of them for the bigger bus we might run into trouble there at least with this connector.
So basically i may be ok with a more general purpose setup if it is granted that it does not dealy the development by a large margin.
Remember: We are currently 4 maximum 5 people working part time on this project and a too big amount of work ,and therefore time dealy, will make us fail against any other comercial or other solution.
We are not the only ones working on FPGA's now afther all.
K so we see the same ARM technology for that purpose so far.
Reagarding the Layouts. We share a dropboxfolder and use eagle to create the layouts.
Please pm me your email adress so i may add you to the folder so you can have a look on the layouts and make improvements.
Reagarding the free I/O lines; We were supposed to use a DIMM 240 Pin connector.
This should provide the bus connection to the motherboard and the power supply with the 12V rails as you might have read.
( The molex and barrel connectors were meant for standalone purpose or for future applications with more FPGA's an higher currents)
There already has been a huge disscussion if the number of pinns used for the current is sufficient or not.
So if we strip away another 60 of them for the bigger bus we might run into trouble there at least with this connector.
So basically i may be ok with a more general purpose setup if it is granted that it does not dealy the development by a large margin.
Remember: We are currently 4 maximum 5 people working part time on this project and a too big amount of work ,and therefore time dealy, will make us fail against any other comercial or other solution.
We are not the only ones working on FPGA's now afther all.
As for a bus: you could just connect a bunch of unused pins on the DIMM connectors to each slot and reserve them for future use. That way the motherboard is more universal and any existing card designs can just not connect to those pins.
Yes exactly. It would just be a parallel data bus. Lots of I/O lines that go between FPGAs and to the DIMM connector. I think 64 should be sufficient? As for system purpose, I think it makes more sense to spend a little more time to make the hardware more general purpose. Yes we could easily make a bitcoin specific cad but with the significant amount of money involved to do this is would really be nice if it was possible for the hardware to have another use outside of bitcoin. I defer to copacobana
@O_Shovah
The part I was talking about is a Cortex M3 from NXP. Looks like we independently arrived at the same conclusion
I am still not comfortable with trying to redesign the current setup to a lot more universallity without having a working design at all.
You mention the "current design". Is it in a repo somewhere? I'd like to take a peek...
As for a bus: you could just connect a bunch of unused pins on the DIMM connectors to each slot and reserve them for future use. That way the motherboard is more universal and any existing card designs can just not connect to those pins.
The part I was talking about is a Cortex M3 from NXP. Looks like we independently arrived at the same conclusion
I am still not comfortable with trying to redesign the current setup to a lot more universallity without having a working design at all.
As for a bus: you could just connect a bunch of unused pins on the DIMM connectors to each slot and reserve them for future use. That way the motherboard is more universal and any existing card designs can just not connect to those pins.
Well wich BUS standart different from SPI would you propose for gaining more bandwith?
I am still not comfortable with trying to redesign the current setup to a lot more universallity without having a working design at all.
@ daphreak
We already considered the ethernet capability of the setup. But we resceduled it to be implemented in a future succesor to the motherboard.
We thought of using an ARM cortex to do this. But i would also appreciate any proposal for a different IC if you have some experience.
So i woul be glad to have you join our development.
So maybe we should redisscus some parts of the current setup. Specifically:
- Bus System (higher bandwith ?)
- System purpose ( different applications than bitcoin ?)
I am still not comfortable with trying to redesign the current setup to a lot more universallity without having a working design at all.
@ daphreak
We already considered the ethernet capability of the setup. But we resceduled it to be implemented in a future succesor to the motherboard.
We thought of using an ARM cortex to do this. But i would also appreciate any proposal for a different IC if you have some experience.
So i woul be glad to have you join our development.
So maybe we should redisscus some parts of the current setup. Specifically:
- Bus System (higher bandwith ?)
- System purpose ( different applications than bitcoin ?)
Something I've been mulling over is that the current design wouldn't be much use for anything other than bitcoin. Using SPI as the sole data bus is very limiting in terms of bandwidth. Granted, I still have a lot of research to do, but I think we should consider exposing more of the I/O lines both on the DIMM connector and an the FPGA's themselves. We can still use SPI for communication, but if the FPGA hardware was ever to be re-purposed, it would be great to have 32-64 data lines interconnecting everything that can be used as a super fast data bus. It requires a bit of redesign now but should allow MUCH greater flexibility in software in the future.
Thoughts?
Thoughts?
uC's have UART's as well so I could use the serial interface as a holdover.
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...
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.
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.
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 ?
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 ?
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: [email protected], 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.
In either case, you need the boards to be able to identify their make/model for bitstream updates.
You can email me at: [email protected], 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. 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..
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 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?
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
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?
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.
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
Jump to: