Modular FPGA Miner Hardware Design Development

[li_gangyi]

li_gangyi: do you think there will be an inrush current issue with the voltage regulators you suggested?

I don't see it as a problem, if it is, we could always tie a suitable capacitor onto it's softstart pin to ram up the voltages slower.

[TheSeven]

You'd need seperate resistors to each FPGA and yes, 2 seperate oscillators is better then anything. 

The reason why I am harping so much on keeping it down to one oscillator and using a suitable termination: we have the same problem with the SPI bus (clockrate there is 25MHz instead of 100MHz) and to a lesser extend also with JTAG. So I want to learn how to make the bus the correct way, and if at all possible I want to not use a star-shaped bus with the MCU at the centre.

While this might be feasible for JTAG/SPI where we can just choose whatever frequency works consistently at a later point, and aren't really constrained on bandwidth, a non-ideal clock signal for the FPGA directly impacts the maximum achievable hashrate. It's a cost/performance tradeoff, and I don't think the oscillator cost will make up for the performance risks that you'd take otherwise.

[O_Shovah]

Regarding the clock sources:
I agree with TheSeven and li_gangyi. One individual clk soure for each FPGA no matter how many they might become.This would provide the best quality signal for each FPGA with the least noise.
As i also consider the bandwith of the BUS a minor problem(see fpgaminer's post on data rates).

Regarding the copyright:
As i already stated  the GNU GPL v3 and the CERN OHL in combination seem the most reasonable way at the moment.I certainly may not guarantee there isn't another better approach out there but it will take me time to find it. So for the time being this would be my proposal.
Please give me a short comment what you think of it. We may change this later in case we see the need to do so, as we still remain the inventors.


And in own matters:

Yesterday i've been on the second bitcoin meeting here in munich.
Very interesting dicussions and people. We will try to hold those regular.
I got a lot of positive feedback regarding our project and many people reported interest
in the final design or wanted to support us in our development.
So i see again there is a lot of potential in this technology on the market already.     

[Olaf.Mandel]

Regarding the clock sources:
I agree with TheSeven and li_gangyi. One individual clk soure for each FPGA no matter how many they might become.This would provide the best quality signal for each FPGA with the least noise.
As i also consider the bandwith of the BUS a minor problem(see fpgaminer's post on data rates).

If three people agree then there is not much point pretending I know how bad a bussed signal would get. I will add the second oscillator today.

Regarding the copyright:
As i already stated  the GNU GPL v3 and the CERN OHL in combination seem the most reasonable way at the moment.I certainly may not guarantee there isn't another better approach out there but it will take me time to find it. So for the time being this would be my proposal.
Please give me a short comment what you think of it. We may change this later in case we see the need to do so, as we still remain the inventors.
[...]

I think the OHL is ok. The suggestion of packaging everything into an archive is useful for distribution, but not feasible on dropbox or git, because we don't want the developers to always have to download the full archive if only a single file changes. We are required to use the license document in PDF form, changing it is explicitly forbidden. So we cannot concatenate the GPL and OHL licenses into a single text document "COPYING". We will need three different files: "COPYING" containing just the copyright notices, warranty disclaimers and explanations which license applies to which directory, "GPLv3.txt" that contains the GPL license and "OHLv1.1.pdf" that contains the OHL license.

[Olaf.Mandel]

I had a look at the MCU schematics: I prefer the MSP430F550x, because it has the smaller package. For the actual implementation, I suggest the MSP430F5507 because it is in the MSP430F550[4-7] range of the the simplest chips that have a temperature sensor and in that range it has the most memory.

The USB connection seems to be too simplistic. Please look at figure B-33 in the MSP430 Hardware Tools User's Guide (SLAU278F): There is a diode in the +5V line that is also mentioned in the MSP430x5xx/MSP430x6xx Family User's Guide (SLAU208H). Then there are the ESD diodes, and RC filters plus caps on the power supply.

The JTAG connection is done in such a way that it debugs the MSP430, but the required connection to NMI is missing. Please look at figure 2-1 of SLAU278F for a suitable connection. If the idea is to connect these JTAG signals to the FPGAs, then that may also work (these pins work fine as GPIO), but please rename TDI and TDO to TDI0 and TDO1. But then you cannot use the pins to debug the MSP430. If you want to have a combined thing, where a JTAG connector is used to debug the MSP430 and the MSP430 can debug the FPGAs, then you need to add JTAG signals on different pins.

Have you decided on which pins to connect the two SPI busses: one bus for the FPGAs, one going to the DIMM connector?

[Olaf.Mandel]

I uploaded a new version of the FPGA design to github and dropbox. Commit logs:

Added second 100MHz oscillator: The oscillators are now located close to their respective FPGAs. Added SUSPEND signal to FPGAs.

Edit: For everyone who cannot see it in dropbox, these are pictures of the current designs for the FPGAs and li_gangyi's PSU units:

[marcus_of_augustus]

You guys are doing some ambitious stuff here, has been a great thread to follow.
 The first one I click on in new replies section. 
Am very interested to see how the testing phase goes ... keep it up.

[O_Shovah]

Has anybody started merging the parts of MSP 430, FPGA and Power supply yet ?

[Olaf.Mandel]

Has anybody started merging the parts of MSP 430, FPGA and Power supply yet ?

It seems that FPGA and PSU are ready or nearly ready, but the MCU part needs a lot of work, still. For example, the package is wrong (PT instead of RGZ).

[O_Shovah]

Has anybody started merging the parts of MSP 430, FPGA and Power supply yet ?

It seems that FPGA and PSU are ready or nearly ready, but the MCU part needs a lot of work, still. For example, the package is wrong (PT instead of RGZ).

Ok, what else needs to be done to the MSP section?
I'll have a look to change the package tomorrow.
EDIT
Did i miss something ? In the version i uploaded the MSP 430 f 5507 has a RGZ package i thought we agreed to use this one. ?

[Olaf.Mandel]

[...]
Ok, what else needs to be done to the MSP section?
I'll have a look to change the package tomorrow.
EDIT
Did i miss something ? In the version i uploaded the MSP 430 f 5507 has a RGZ package i thought we agreed to use this one. ?

Sorry, my mistake. I started working on the file and decided to copy the device into the project.lbr library. I only looked after doing the copy from the downloaded TI library.

You saw my previous comments on the MCU?

[Olaf.Mandel]

I uploaded a new version of the FPGA design (minor changes) and a new MCU design (completely redone) to github and dropbox. Commit logs:

• Added MSP430550x and TPDxe001 to project library
• Minor: Moved SUSPEND label in FPGA design
• Changed symbol to new entry in library, having better structure
• Changed library and size of caps
• Changed oscillator
• Added USB filters and ESD protection according to SLAU278F

Also added symbols for the still-to-be-connected nets to the MCU design.

[O_Shovah]

[...]
Ok, what else needs to be done to the MSP section?
I'll have a look to change the package tomorrow.
EDIT
Did i miss something ? In the version i uploaded the MSP 430 f 5507 has a RGZ package i thought we agreed to use this one. ?

Sorry, my mistake. I started working on the file and decided to copy the device into the project.lbr library. I only looked after doing the copy from the downloaded TI library.

You saw my previous comments on the MCU?

Seems we had a little missunderstanding here

I thougt you claimed we should use the RGZ package but i was wrong.

So now we gonna go on with you schematic.

I will add the lines for clk and FPGA IO to the schmatic afther lunch.

[Olaf.Mandel]

[...]
Did i miss something ? In the version i uploaded the MSP 430 f 5507 has a RGZ package i thought we agreed to use this one. ?

Sorry, my mistake. I started working on the file and decided to copy the device into the project.lbr library. I only looked after doing the copy from the downloaded TI library.
[...]

Seems we had a little missunderstanding here

I thougt you claimed we should use the RGZ package but i was wrong.

Actually, that is exactly what I want: the PT package is only available for the 5504, 5508, 5509 and 5510. The RGZ package is available for all 5500 through to 5510. So I actually had it right in my first post. But I can see where your confusion comes from: the package in my schematic is named PT48. Actually, I forgot to rename it! If you look at the package or read its description, it should be named RGZ48. I will change that in my version of the package.

So now we gonna go on with you schematic.

I will add the lines for clk and FPGA IO to the schmatic afther lunch.

You will add the lines? Perfect. But which clock lines? The 25MHz CLK signal is already connected. Or do you mean the TCK and SCLK lines?

What is currently completely missing are the connections to the DIMM bus and the 3.3V -> 2.5V converter. I will start adding the power supply to the PSU design today. If there is time, I will also start making a design for the connections to the DIMM bus.

[O_Shovah]

Ok so thats ruled out so far.

I just added the TDI TDO TCK and TMS net.I uploaded the modified schematic into my folder.Just a little mod.

I'm currently reading about the TCK and TDIO for the SPI BUS ( Pin 48 & 47) but im still not sure about the additional requirements.  

[Olaf.Mandel]

Ok so thats ruled out so far.

I just added the TDI TDO TCK and TMS net.I uploaded the modified schematic into my folder.Just a little mod.

I'm currently reading about the TCK and TDIO for the SPI BUS ( Pin 48 & 47) but im still not sure about the additional requirements.  

I think you can leave RST/NMI and TEST unconnected, because you are not actually using the JTAG pins to debug the MSP430. You connected them to the FPGA, so they are used as normal GPIO pins. In that case, nothing should be needed for the RST and TEST pins (maybe an RC-element for the RESET as a brownout detection?). You do realise that in this configuration, you could have used any of the other port pins for the JTAG connection, right?

[O_Shovah]

Ok so thats ruled out so far.

I just added the TDI TDO TCK and TMS net.I uploaded the modified schematic into my folder.Just a little mod.

I'm currently reading about the TCK and TDIO for the SPI BUS ( Pin 48 & 47) but im still not sure about the additional requirements. 

I think you can leave RST/NMI and TEST unconnected, because you are not actually using the JTAG pins to debug the MSP430. You connected them to the FPGA, so they are used as normal GPIO pins. In that case, nothing should be needed for the RST and TEST pins (maybe an RC-element for the RESET as a brownout detection?). You do realise that in this configuration, you could have used any of the other port pins for the JTAG connection, right?

Ok so we will just leave them floating.

I've got a very basic question regarding the SPI net.

One part of our SPI BUS, is between the wo FPGA's and the MSP 430 with the MSP acting as a Master towards the FPGA's wich are independent Slaves.
The other part is the MSP acting as a independent SPI slave towards another master located on the motherboard (another MSP 430 or an ARM cpu).

So the MSP on the DIMM is both slave an Master in SPI  eg using USCI_A as master part and USCI_B as slave part.

So it can either recieve work and instructions via SPI from the motherboard or in standalone operation via USB.   


Am i having the correct idea of the Network or am i running in a totally wrong direction.
I would like to know this so i dont start building nonsens. 
 

[Olaf.Mandel]

[...]
I've got a very basic question regarding the SPI net.

One part of our SPI BUS, is between the wo FPGA's and the MSP 430 with the MSP acting as a Master towards the FPGA's wich are independent Slaves.
The other part is the MSP acting as a independent SPI slave towards another master located on the motherboard (another MSP 430 or an ARM cpu).

So the MSP on the DIMM is both slave an Master in SPI  eg using USCI_A as master part and USCI_B as slave part.

So it can either recieve work and instructions via SPI from the motherboard or in standalone operation via USB.  

Am i having the correct idea of the Network or am i running in a totally wrong direction.
I would like to know this so i dont start building nonsens.

This sounds exactly right! One bus to the FPGAs using SCLK, MOSI, MISO, SSEL0 and SSEL1, and another bus using some other signals. Can we decide on the signal names now? Maybe H_SCLK, H_MOSI, H_MISO, H_SSEL (where H_ stands for "host") or MCU_*, or even *_2 or something. Which are you going to use? Don't forget that MOSI and MISO have different meaning between the two busses: input and output are swapped.

[O_Shovah]

Ok so i'll start wire it this way.
I should be finished soon.
I will use .._Hn for host and ..._Sn for slave parts. So n stands for the devicenumber.

[Olaf.Mandel]

I uploaded a new version of the PSU design and a new MCU design (minimal changes) to github and dropbox. Commit logs:

• Fixed name of MSP430 package: PT48 -> RGZ48
• Updated library after learning about technologies:
  
  • Started using the ? and * keywords in device names, changed several parts
  • Added the PT48 package to the MSP430F55*I part, added attributes
  • This causes an incompatible name change in the MSP430F55XX device: use the replace command
  • Added the LM3671 device
• Refinements on PSU section:
  
  • Added 3.3V -> 2.5V PSU
  • Changed all devices to default libraries
  • This specifically includes changes to the CPOL parts: they were oriented the wrong way around
• Small changes to MCU:
  
  • Changed name of VUSB to +3V3 (by changing the supply symbol)
  • Removed +5V name (by deleting the supply symbol)
  • Named the two USB signals DM and DP
  • Added two V<-> symbols and routed them to DM and DP

@Li_gangyi: Can you verify the capacitors in the PSU? I changed them to something in the default rcl library (your parts were from a non-standard lib). But this turned the CPOL elements around. Please make sure you agree that the negative pin is marked on your parts.

@O_Shovah: You can update you local copy of the MCU.sch that you worked on by doing the following steps (maybe first open my schematic for a quick peek):

• Get the new project.lbr and update the schematic
• REPLACE the MCU device with the MSP430F5507IRGZ
• DELETE the VUSB symbol
• ADD +3V3@supply1 in its place
• DELETE the +5V symbol and the stub of wire connecting to it
• NAME the nets going to the two ESD diodes DM and DP
• ADD two V<-> symbols at these coordinates: (0.8 6.7) and (0.8 6.6). Both are rotated by 180 degrees
• Change the VALUE of each symbol: the upper one to DM, the lower one to DP
• Route a NET to the symbols, starting at the two ESD diodes