Modular FPGA Miner Hardware Design Development

[Olaf.Mandel]

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.

I don't quite get it: n stands for what, exactly? There is only three chips here and there is only two busses: host and FPGAs. Actually, for the two FPGAs, the signal names already encode the number: SSEL0 or SSEL1.

[O_Shovah]

I uploaded a merged variant of your and my MCU parts.

I used the following line syntax:

eg  SSEL_D1;  SSEL is the slave select line   "D" stands for : The line is located on the DIMM so in this case the MCU is Master  "1" is the number of the FPGA this line is headed for

And SSEL_M;  SSEL is the slave select line   "M" stands for : The line is headed to the Motherboard so in this case the MCU is Slave  

Im still in route for the second SSEL pin to the FPGA's and The clock in/output
EDIT

Please correct me if im wrong.
But it seems as we dont have a second SSEL pin here for the FPGA's and in addition we need a MSP modell with two A and B USCi blocks so we may use all signals on correct pins ?
Or are we supposed to use the Pins  35 and 36 for this purpose. ?
 

[Olaf.Mandel]

[...]
Im still in route for the second SSEL pin to the FPGA's and The clock in/output
EDIT

Please correct me if im wrong.
But it seems as we dont have a second SSEL pin here for the FPGA's and in addition we need a MSP modell with two A and B USCi blocks so we may use all signals on correct pins ?
Or are we supposed to use the Pins  35 and 36 for this purpose. ?

I just uploaded a DIMM connector, and of course I got the _D to _M wrong. I will upload a corrected version soon. I think one USCI_A and one USCI_B block should suffice. My only uncertainty: how to generate two SSEL signals from one block? Could be that those two pins can be used, but I don't know for sure.

And I made a mistake in a previous post: we need to preserve the +5V symbol on the USB pin 1: this needs to route to the DIMM connector also, so that the MCU can detect a USB connection. Can you restore it?

And the SSEL_D signal can be routed in a bus (the blue lines) the correct name in this case is SSEL_D[0..1] .

[Olaf.Mandel]

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

• Changed names of SPI signals in DIMM
• Copied in MCU design by O_Shovah
• Repaired MCU design: There were several defective wires: not attached to pins and wrong names

@O_Shovah: You still have some trouble with using eagle. Some of your wires were not connected to the pins they touched. The order is important here: either place a part on top of existing wires or draw a wire to touch a pin. Moving a wire to touch a pin does not work. Also, you cannot change the signal carried by a wire by placing a suitable label close to it. You need to use the NAME command. It is usually a good idea to first use the label command to actually get the name displayed and then use the NAME command to change it and see the change in the label.

I currently placed two MCU supply voltages on the DIMM connector: +5V which is connected to the USB 5V, and +3V3, which is connected to the output of the LDO inside the MSP430 (this LDO is fed by the +5V). I wanted to have the backplane supply 5V only if it used the USB connection and supply 3.3V otherwise. But there should be a different way to detect the presence of the USB host. So any concerns about removing the +3V3 signal from the DIMM?

[Olaf.Mandel]

I just read through the MSP430 docu and found two things:

Good news: multiple SSEL signals are no problem. The STE signals provided by the serial engine are different from the SSEL signals. They are to facilitate multiple masters on one bus, so we don't need them. This means we can set UCMODEx=00 (3-wire mode) in both UCA1CTL0 and UCB1CTL0.

Bad news: the way the two serial engines are multiplexed onto the output pins, it is impossible to configure one engine to 4-wire mode and use the second engine at the same time. We don't need to to that, but this raises the question if two concurrent 3-wire SPI engines on the same port are even possible at all. Can anyone who knows their MSP430 forward and backward answer this? Alternatively we could use a 64-pin package (the 5510IRGC).

[O_Shovah]

[...]
@O_Shovah: You still have some trouble with using eagle. Some of your wires were not connected to the pins they touched. The order is important here: either place a part on top of existing wires or draw a wire to touch a pin. Moving a wire to touch a pin does not work. Also, you cannot change the signal carried by a wire by placing a suitable label close to it. You need to use the NAME command. It is usually a good idea to first use the label command to actually get the name displayed and then use the NAME command to change it and see the change in the label.
[...]

I m sorry for making you clean up my mistakes. I hope i produce more advance than work.

I just read through the MSP430 docu and found two things:

Good news: multiple SSEL signals are no problem. The STE signals provided by the serial engine are different from the SSEL signals. They are to facilitate multiple masters on one bus, so we don't need them. This means we can set UCMODEx=00 (3-wire mode) in both UCA1CTL0 and UCB1CTL0.

Bad news: the way the two serial engines are multiplexed onto the output pins, it is impossible to configure one engine to 4-wire mode and use the second engine at the same time. We don't need to to that, but this raises the question if two concurrent 3-wire SPI engines on the same port are even possible at all. Can anyone who knows their MSP430 forward and backward answer this? Alternatively we could use a 64-pin package (the 5510IRGC).

So that verifiys my first impression.
I also considered the 64 pin package. I doesn't need much more space and would provide plenty of additional pins with the second block for SPI in the 5510.
And we should also consider the case of using more than 2 FPGA's.

[Olaf.Mandel]

[...]
I m sorry for making you clean up my mistakes. I hope i produce more advance than work.

Not much work. I said it to make you learn the "eagle way" of schematic entry. I guess transitioning from a different program is tough.

[O_Shovah]

[...]
I m sorry for making you clean up my mistakes. I hope i produce more advance than work.

Not much work. I said it to make you learn the "eagle way" of schematic entry. I guess transitioning from a different program is tough.

Thank you

In Altium its impossible to lay a line to a pin, without either connecting it automatically or getting a dialogue wich ask wich network the whole setup should be assigned to.

[TheSeven]

• Refinements on PSU section:
  
  • Added 3.3V -> 2.5V PSU

I currently placed two MCU supply voltages on the DIMM connector: +5V which is connected to the USB 5V, and +3V3, which is connected to the output of the LDO inside the MSP430 (this LDO is fed by the +5V). I wanted to have the backplane supply 5V only if it used the USB connection and supply 3.3V otherwise. But there should be a different way to detect the presence of the USB host. So any concerns about removing the +3V3 signal from the DIMM?

So you want to feed the FPGA's 2.5V rail through the MSP's built-in LDO? Doesn't sound good

[Olaf.Mandel]

• Refinements on PSU section:
  
  • Added 3.3V -> 2.5V PSU

[...]
So you want to feed the FPGA's 2.5V rail through the MSP's built-in LDO? Doesn't sound good

Of course not. There are two 2.5V supplies in the PSU design:

VCC: Fed by the 3.3V LDO in the MSP430. Powers the MSP430 and nothing else.

VCCIO: Fed by the +12V connector. Powers the VCCio rail of both FPGAs.

[li_gangyi]

Been busy with another related project recently. I've looked at the PSU section, everything looks ok except for 1 thing that I missed earlier, pin 3 (1 and 2 are for Vin) needs to be grounded, that mistake was probably there when I created the LMZ library.

Can't comment on the current discussion about how to hook up the respective busses with the MSP430, really no experience in this area.

[O_Shovah]

Just to give information.
I will be on an buisness trip untill next monday so i'll be with you again monday evening.

[fizzisist]

I just returned from vacation and it's wonderful to see that you guys have made so much progress. Two questions:

1) When did we settle on the MSP430F5507? At one point, li_gangyi recommended that we stay away from the QFN package, but that part is available only in QFN. Also, the 32 kB flash memory could end up being a limit, although probably not. I still don't understand how the USCI ports work exactly, but would it be helpful to get one of the chips that has 2x2 USCI? Forgive me if I'm missing something, I just want to make sure this important decision is being made carefully.

2) Is anyone checking for the availability and prices of these components? I've been in trouble before because I designed a board using Eagle's libraries, then looked for the parts on Digikey and many of them weren't available. It's good practice to build a BOM with supplier part numbers and prices as you go. If this still needs to be done, I'll gladly work on this.

[Olaf.Mandel]

[...]
1) When did we settle on the MSP430F5507? At one point, li_gangyi recommended that we stay away from the QFN package, but that part is available only in QFN. Also, the 32 kB flash memory could end up being a limit, although probably not. I still don't understand how the USCI ports work exactly, but would it be helpful to get one of the chips that has 2x2 USCI? Forgive me if I'm missing something, I just want to make sure this important decision is being made carefully.

Didn't pay attention to that. On the other hand: the schematic symbol is identical, so changing that is easy.

2) Is anyone checking for the availability and prices of these components? I've been in trouble before because I designed a board using Eagle's libraries, then looked for the parts on Digikey and many of them weren't available. It's good practice to build a BOM with supplier part numbers and prices as you go. If this still needs to be done, I'll gladly work on this.

Availability: yes. And li_gangyi has an XLS BOM on dropbox. But I would prefer an Eagle database for the bom.ulp program. If you could get started, that would be cool!

[fizzisist]

I started creating a BOM database for Eagle's bom.ulp program. This is new to me, but it's easy enough to figure out. The database is in Layout/BOM/bom_eagle_database.tsv. I also exported the first BOM for "Parts_Combined" to the same folder.

Is everyone ok with Digikey as the preferred supplier?

I'm wondering about all of these package sizes for the passive components. Were these all chosen intentionally? Particularly strange is the 2220 package. Is there any reason to not reduce this to a more standard 1206? The others are at least standard sizes, but we could probably reduce the number of different sizes to one or two.

For the 390uF electrolytics, we have ones rated for 2.5V on the 1.2V rail and rated for 4V on the 2.5V rail. It would make sense to make them all 4V, right? Maybe even higher...

[Olaf.Mandel]

[...]
Is everyone ok with Digikey as the preferred supplier?

I am happy with that choice. But please consider avnet for the actual FPGAs and switchers, as they are significantly cheaper. I just had a look at the switchers: there is not much stock (64 and 90, respectively) for the LMZ12010.

I'm wondering about all of these package sizes for the passive components. Were these all chosen intentionally? Particularly strange is the 2220 package. Is there any reason to not reduce this to a more standard 1206? The others are at least standard sizes, but we could probably reduce the number of different sizes to one or two.

For the 390uF electrolytics, we have ones rated for 2.5V on the 1.2V rail and rated for 4V on the 2.5V rail. It would make sense to make them all 4V, right? Maybe even higher...

For the caps in the FPGA section, these are based on the recommendations in the XIlinx PCB design guide. I would opt not to change those. The resistors in the FPGA section were chosen by me: no particular reason for this size, I just wanted something small that should still be able to stand the dissipated power. For the PSU section, li_gangyi chose the component sizes. I replaced all packages with something found in the rcl library (I prefer to have a common look of the symbols and I try not to have several non-standard libraries in the project). If any of the parts there strike you as odd, I either made a mistake when doing the conversion or you should get li_gangyi's input as to his package choices (I am really bad at analogue stuff, so I wouldn't want to comment). As for the MCU section: I replaced most of the choices in O_Shovah's original design with something else. The idea was to minimise the number of different components: for example in several places where 100nF would have been sufficient I wrote 470nF instead so as to use the same parts as for the FPGA.

[Olaf.Mandel]

I uploaded new versions of the FPGA, MCU and PSU designs to github and dropbox. Commit logs:

• Updated LMU22010 in library and in PSU:
  
  • Changed pin SMD pad sizes and count to match datasheet
  • Changed schematic symbol to have correct number of pins
  • Updated PSU schematic and board to use new device
  • Set SYNC pins to GND as per li_gangyi's instruction (and datasheet)
• Renamed SPI bus to FPGAs and synced designs:
  
  • Renamed the SPI bus to the FPGAs in the MCU section from *_D to *_F (F standing for FPGA)
  • Changed the names in the FPGA design to match these
• Finished MCU connection:
  
  • Connected SPI clocks to multiplexed pins (CHECK THAT THIS IS USABLE!!!)
  • Connected all other signals to some GPIO

[fizzisist]

For the caps in the FPGA section, these are based on the recommendations in the XIlinx PCB design guide. I would opt not to change those. The resistors in the FPGA section were chosen by me: no particular reason for this size, I just wanted something small that should still be able to stand the dissipated power. For the PSU section, li_gangyi chose the component sizes. I replaced all packages with something found in the rcl library (I prefer to have a common look of the symbols and I try not to have several non-standard libraries in the project). If any of the parts there strike you as odd, I either made a mistake when doing the conversion or you should get li_gangyi's input as to his package choices (I am really bad at analogue stuff, so I wouldn't want to comment). As for the MCU section: I replaced most of the choices in O_Shovah's original design with something else. The idea was to minimise the number of different components: for example in several places where 100nF would have been sufficient I wrote 470nF instead so as to use the same parts as for the FPGA.

You've done a great job keeping these various schematics clean and uniform, and reducing the number of different components. The only strange ones to me are the PSU ones, so we need li_gangyi to answer about these.

I added most parts from the FPGA, PSU, and MCU schematics to the BOM database. I also created BOMs for each. A few questions that came up while doing this:

1) Surface mount power connectors? These would really be much better as through-hole, for strength.

2) I think I remember li_gangyi asking us to keep components above 0402 (1005 metric). Can these little guys be switched to 0603 or larger? For prototyping and debugging, it's also better to keep things larger (easier to probe and rework if needed).

3) Are we using the LMZ22010 or the LMZ12010? I'm seeing some confusion in the various schematics here. The difference between the two seems to be the SYNC pin, which we aren't using, so I don't see why we shouldn't use the cheaper one.

4) Speaking of the LMZx2010, the datasheet is calling for slightly different resistor values on R_FBT and _FBB. Am I just reading this wrong or was this a mistake?

[Olaf.Mandel]

[...]
I added most parts from the FPGA, PSU, and MCU schematics to the BOM database. I also created BOMs for each. A few questions that came up while doing this:

1) Surface mount power connectors? These would really be much better as through-hole, for strength.

There are currently only SMD connectors, but as li_gangyi already pointed out these should be changed (in some cases: changed back) to through-hole. I just haven't done it, yet.

2) I think I remember li_gangyi asking us to keep components above 0402 (1005 metric). Can these little guys be switched to 0603 or larger? For prototyping and debugging, it's also better to keep things larger (easier to probe and rework if needed).

That is a bit problematic: the Xilinx PCB design guide calls for 0402 imperial size caps. Does anyone have a good feel what happens if that size is changed? If the caps should stay 0402, then my second question is: does it make sense to keep the 0402 caps for the FPGAs but make all other 0402 size devices larger (for the MCU for example) or is there no extra difficulty on using more 0402 packages than absolutely necessary?

3) Are we using the LMZ22010 or the LMZ12010? I'm seeing some confusion in the various schematics here. The difference between the two seems to be the SYNC pin, which we aren't using, so I don't see why we shouldn't use the cheaper one.
[...]

Didn't even notice that. The thing had different names in the library: the symbol was called LMZ22... and the device LMZ12... I just selected the symbol name to open the datasheet and then renamed the device. As far as I can see the current design is fit for both devices, though: pin 3 (the only difference between the devices) is grounded, which it needs to be in both cases. For the LMZ22..., it also needs to be grounded because we do not connect a frequency source.

[fizzisist]

That is a bit problematic: the Xilinx PCB design guide calls for 0402 imperial size caps. Does anyone have a good feel what happens if that size is changed? If the caps should stay 0402, then my second question is: does it make sense to keep the 0402 caps for the FPGAs but make all other 0402 size devices larger (for the MCU for example) or is there no extra difficulty on using more 0402 packages than absolutely necessary?

In general, a smaller capacitor will be able to get closer to the pin and therefore do a better job decoupling. I think it would make sense to just use as few 0402s as possible: the probability of making a mistake soldering is just going to be increased for each additional capacitor. I don't think we have to think about it like reducing trace width or such (therefore raising the cost of the whole board). When these boards are eventually loaded by a professional shop, they won't even blink when we ask them to load 0402s.

Anyway, we need li_gangyi's input on this, because he's the one who'll be doing the actual soldering on this prototype.