Modular FPGA Miner Hardware Design Development

[phillipsjk]

This MCU, MSP430F55xx, has the ability to be partially bus powered with a built in LDO. The main purpose of this is to set the level of the USB I/Os independently of the other I/Os. We can't power the entire chip with USB, or we will have to use level shifters to interface with the FPGAs. Furthermore, when the board is used in the motherboard, this USB connection will not be present, so it needs to be powered off the ATX supply.

I think you misunderstood my thinking: the 2.5V Linear Regulator Drop-In suggested earlier can run on 5V. With efficiency listed at 87%, it obviously operates in switch-mode. If the MCU power+FPGA I/O is less than 2.5 2.17 Watts, bus power is doable without any level shifters. Last I checked, ATX power supplies can push over 5 Amps on the 5V rail. The motherboad would need a 20 (or 24) pin connector and traces for 5V.

Edit: Barrel connector option my be a problem here. When would that be used?
Edit: To answer that question: when you are using it in stand-alone mode and need extra power.

[fizzisist]

This MCU, MSP430F55xx, has the ability to be partially bus powered with a built in LDO. The main purpose of this is to set the level of the USB I/Os independently of the other I/Os. We can't power the entire chip with USB, or we will have to use level shifters to interface with the FPGAs. Furthermore, when the board is used in the motherboard, this USB connection will not be present, so it needs to be powered off the ATX supply.

I think you misunderstood my thinking: the 2.5V Linear Regulator Drop-In suggested earlier can run on 5V. With efficiency listed at 87%, it obviously operates in switch-mode. If the MCU power+FPGA I/O is less than 2.5 2.17 Watts, bus power is doable without any level shifters. Last I checked, ATX power supplies can push over 5 Amps on the 5V rail. The motherboad would need a 20 (or 24) pin connector and traces for 5V.

I'm confused then what you're proposing. Looking at your other post, it either sounds like something we're already doing or something entirely different. Can you try to explain more, maybe with schematics?

[phillipsjk]

Edit: It has been decided I was going off on an unnecessary tangent here.

I'm confused then what you're proposing. Looking at your other post, it either sounds like something we're already doing or something entirely different. Can you try to explain more, maybe with schematics?

Your Block diagram shows the 2.5Volt supply using the same V_IN as the 1.5 Volt supplies. I am proposing running the 2.5Volt supply from 5V if the power draw is low enough. For USB, you would be limited to 500mA, even with self-powered hubs. I still have not read the USB spec, so am not sure how to ask permission to draw more power (than 100mA). I also have not read the MCU documentation to see if it can do that from the LDO you mention, turning itself on with the enable pin.

[fizzisist]

I'm confused then what you're proposing. Looking at your other post, it either sounds like something we're already doing or something entirely different. Can you try to explain more, maybe with schematics?

Your Block diagram shows the 2.5Volt supply using the same V_IN as the 1.5 Volt supplies. I am proposing running the 2.5Volt supply from 5V if the power draw is low enough. For USB, you would be limited to 500mA, even with self-powered hubs. I still have not read the USB spec, so am not sure how to ask permission to draw more power (than 100mA). I also have not read the MCU documentation to see if it can do that from the LDO you mention, turning itself on with the enable pin.

I might still be misunderstanding you, but I don't see how the USB current limit is relevant, we won't be powering any devices off of USB.

More importantly, though, the decision has already been made that the power will be done this way, to allow for users to power a board off of a "wall wart" AC adapter or laptop power supply. We need to move on with the other parts of the design instead of going back.

[phillipsjk]

I wasn't advocating replacing or adding any parts (except maybe a pull-up resistor to turn the 2.5V supply on when plugged into a backplane). No module will be running with solely the barrel connector: to do useful work, you need I/O. The I/O options include USB (includes 5V) and the backplane (can include 5V).

Is it common for laptops to have underpowered USB ports? The power consumption is important because it is a pointless exercise if we can't meet the USB spec. Bus power is needed for MCU control in off-grid applications where you may want to turn off  some, but not all, FPGAs based on available power. Determining available power is out-of scope (up to the host).

Being able to turn off individual FPGAs is a nice-to have option, but I am the only person really pushing for the idea, as far as I can tell. If the MCU can actually turn on its own power supply, I don't care what voltage the input is. I looked through the MSP430F551x/MSP430F552x datasheet and still don't know what the MCU can do on only bus power.

One thing I did learn is that the Plastic Quad Flat pack requires a thermal pad as a heatsink (Pages 116,117). Presumably the BGA package cools the same way, but will already have pads in place for signal routing.

Edit: Nevermind. I wasn't thinking completely straight. The 2.5V supply should draw negligible power whether drawn from 12V or 5V. As well, both supplies are equally controllable. The ATX 5V Standby line can't be used for powering the MCU from the backplane, because with over 4 boards you likely exceed 2 Amps.

[li_gangyi]

Please guys, use a full unbroken GND plane for the entire board ( preferrably on layer 2 right below the FPGA )
The core voltage should also be a power plane under the fpga (layer 3 is best), extending out to the decoupling caps (as unbroken as possible).  Feedback to the core regulator should come from the power plane so it "sees" what the fpga "feels" ^_^

Just route out the IO pads you get "for free" down the the connector. 4 Layers should give you plenty without having to compromise on power integrity.
Merging VCCAUX  and VCCIO is smart as there is very little IO toggling to generate noise into the PLL's anyway.
Good decoupling is always a must.
Add decoupling footprints at the back of the board directly under the FPGA just in case. (not mounted for now)

Have a look here:  http://www.xilinx.com/support/documentation/user_guides/ug393.pdf   
The decoupling section is kinda overkill but lots of nice tips on several topics.
My recommendation is to add a few 4.7 or 10uf caps and several 100nF as near the power pins as possible for each  rail.
VccInt is the one to give priority if there is a conflict.

I'm sorry if this stuff is well know to you already,  but better safe than sorry

Looks like we're gonna need to redo this, I don't see a quick way to change the current layout to make it happen.

Need to do:
Reroute Layer 2 = GND
Layer 15 = VccINT and split it at the same time
Layer 16 = VccIO+AUX

[TheSeven]

I'm confused then what you're proposing. Looking at your other post, it either sounds like something we're already doing or something entirely different. Can you try to explain more, maybe with schematics?

Your Block diagram shows the 2.5Volt supply using the same V_IN as the 1.5 Volt supplies. I am proposing running the 2.5Volt supply from 5V if the power draw is low enough. For USB, you would be limited to 500mA, even with self-powered hubs. I still have not read the USB spec, so am not sure how to ask permission to draw more power (than 100mA). I also have not read the MCU documentation to see if it can do that from the LDO you mention, turning itself on with the enable pin.

Not that it would make much sense, but I just want to comment on the technical aspects:
- Laptops aren't likely to be an issue here
- Asking for more power is done during enumeration, so you would need to have a way to only power the MCU until that has completed
- Devices asking for more than 100mA will be rejected if they're on a bus-powered hub
- USB has some crazy standby requirements which require the device to be able to go as low as 100µA within milliseconds. The MCU probably can't even be powered down deeply enough for that.

[Olaf.Mandel]

So many posts while I wasn't looking...

[...]
I also agree the MSP should be powered by the power solution of the fpga.The level shifters would add adtitional parts and complicate things so we my use this in another version.
[...]

Careful: you are killing one of the original features here: if the MSP is not powered from the USB connector, then it cannot enable or disable the power for the FPGAs. This was (at least for me) an important feature. And I don't see the problem, actually: you just need an additional small switcher that hangs on the USB power pin and outputs 2.5V. No reason to talk about level shifters or anything.

Please guys, use a full unbroken GND plane for the entire board ( preferrably on layer 2 right below the FPGA )
The core voltage should also be a power plane under the fpga (layer 3 is best), extending out to the decoupling caps (as unbroken as possible).  Feedback to the core regulator should come from the power plane so it "sees" what the fpga "feels" ^_^
[...]

I am sure you have a good reason for that recommendation, but as I am not an electrical engineer, I cannot guess at them, so please elaborate. Here are my reasons for choosing the layout I chose:

• My understanding was that normally the outer layers are the thicker ones (pcbcart can do it differently, but that seems to be the default). So I placed VCCINT and GND there.
• Most pads in the design need GND, so I placed that on top.
• The top layer cannot be used for routing signals at the location of the ball-grid array (too thick traces). So layer 2 is used for most routing needs.
• The feedback line of the switcher may carry quite a bit of noise to the FPGA (no decoupling caps there), so I would prefer to leave that local to the switcher and use more copper to keep the voltage drop between PSU and FPGA small.

[...]
I think you misunderstood my thinking: the 2.5V Linear Regulator Drop-In suggested earlier can run on 5V. With efficiency listed at 87%, it obviously operates in switch-mode. If the MCU power+FPGA I/O is less than 2.5 2.17 Watts, bus power is doable without any level shifters. Last I checked, ATX power supplies can push over 5 Amps on the 5V rail. The motherboad would need a 20 (or 24) pin connector and traces for 5V.

Edit: Barrel connector option my be a problem here. When would that be used?
Edit: To answer that question: when you are using it in stand-alone mode and need extra power.

I said it above, but: you should probably get two sources of 2.5V: one for the MPU and one for the FPGA. The FPGA one gets switched by the MPU, the other one is "always on". As for power consumption: who knows? If we make strong use of the FPGAs internal frequency synthesizers, we would probably exceed your limit on the 2.5V line. Current HDL designs don't do that, but who knows what additional optimisations can be found in the SHA-code?

[...]
I might still be misunderstanding you, but I don't see how the USB current limit is relevant, we won't be powering any devices off of USB.
[...]

The MSP430 is powered by USB. But nothing else should be.

[...]
Being able to turn off individual FPGAs is a nice-to have option, but I am the only person really pushing for the idea, as far as I can tell. If the MCU can actually turn on its own power supply, I don't care what voltage the input is. [...]

As far as individual FPGAs are concerned: you are right. But as far as individual DIMMs are concerned: I wrote that in the preliminary, not ever formally accepted specs near the beginning of this thread.

[...]
- Asking for more power is done during enumeration, so you would need to have a way to only power the MCU until that has completed
- Devices asking for more than 100mA will be rejected if they're on a bus-powered hub
- USB has some crazy standby requirements which require the device to be able to go as low as 100µA within milliseconds. The MCU probably can't even be powered down deeply enough for that.

Exactly: an extra switcher for the MCU is needed. And the MCU won't go to standby: it either is on or off, not doing standby at all. The question is: how can we communicate this to the host in a sane way? How does the MCU power supply know when to power down the MCU, even if there is power on the USB pins?

[li_gangyi]

Ok, I've splitted in the schematic VccINT into 1 and 2, and seperated them + put down the planes that're for power. Also merged Vccaux and VccIO into VccIO, the Vccaux layer is now freed up for IO purposes, renamed the layers to match.

Also merged the schematic properly so the ratnest comes out right.

Still to do:
Optimise the capacitor layout, finish routing the PSU and link it up actually to the board. We can actually afford to route the feedback from the Vccint layer, as long as we keep the resistor physically close to the LMZ module.

Slight OT: Adding blind vias = alot more $$$?

[Olaf.Mandel]

[...]
Slight OT: Adding blind vias = alot more $$$?

I had a look at pcbcart. Assuming I understand the webpage, it is only ~4USD more for one set of blind vias (10 boards). May I ask what you need them for? I could place the small FPGA caps without having problems with the vias. Shouldn't it be even simpler with the power supplies?

[li_gangyi]

With blind vias it'd be easier to put gnd on the 2nd layer and route the gnd pins down to that, it's not strictly necessary though. Can you finish routing up the rest of the board? It's pretty close to done. Look in the main folder.

We still need a clk source and MSP430 hooked up. I've freed up 1 layer of the board, so that should make things easier. We'd need the FPGA and MSP guys to come in now and offer some input on how best which IOs go where and the clock source.

[O_Shovah]

[...]
I also agree the MSP should be powered by the power solution of the fpga.The level shifters would add adtitional parts and complicate things so we my use this in another version.
[...]

Careful: you are killing one of the original features here: if the MSP is not powered from the USB connector, then it cannot enable or disable the power for the FPGAs. This was (at least for me) an important feature. And I don't see the problem, actually: you just need an additional small switcher that hangs on the USB power pin and outputs 2.5V. No reason to talk about level shifters or anything.

So you just call for an additional littel 2.5 V source just for the MCU in order to make it independent from the FPGA power supply? If thats teh case you are cerrtainly right. I thought you wanted to use an centrall power supply controler in addition.
Sorry for the misunderstanding.

[Olaf.Mandel]

With blind vias it'd be easier to put gnd on the 2nd layer and route the gnd pins down to that, it's not strictly necessary though. Can you finish routing up the rest of the board? It's pretty close to done. Look in the main folder.

We still need a clk source and MSP430 hooked up. I've freed up 1 layer of the board, so that should make things easier. We'd need the FPGA and MSP guys to come in now and offer some input on how best which IOs go where and the clock source.

I may get to it tonight.

For a clock source: you will probably need two: one for the FPGA, one for the MSP430. For the FPGA, I suggest the ASEM1-100.000MHZ-LC-T: it's small (3.2x2.5mm²) and should be sufficiently stable. For the MSP430, it seems a 25MHz source is needed, like the ASEM1-25.000MHZ-LC-T.

I am not very happy with using a "normal" crystal, because they are much larger then these SMD-MEMS oscillators. One question I am not sure of: can we maybe get away with feeding the FPGA only 25MHz? Then we could save one oscillator.

[Olaf.Mandel]

Actually: what is the status on the MSP430 schematics? Which signals are used, which signal names (important for merging the designs)?

[grid]

For a clock source: you will probably need two: one for the FPGA, one for the MSP430. For the FPGA, I suggest the ASEM1-100.000MHZ-LC-T: it's small (3.2x2.5mm²) and should be sufficiently stable. For the MSP430, it seems a 25MHz source is needed, like the ASEM1-25.000MHZ-LC-T.

I am not very happy with using a "normal" crystal, because they are much larger then these SMD-MEMS oscillators. One question I am not sure of: can we maybe get away with feeding the FPGA only 25MHz? Then we could save one oscillator.

Consider this design:
https://i.imgur.com/2EtkH.jpg
The ZTEX USB-FPGA 1.15d LX-150 based, with a Cypress EZ-USB for flashing, feeding the FPGA with data and USB communication. Uses only one 24MHz oscillator, some schematics available on their site:
http://www.ztex.de/usb-fpga-1/usb-fpga-1.15.e.html

By the way the price of this one beats the Opal board I mentioned earlier. Got an email quote at a unit price of 357EUR, power supply not included.

[Olaf.Mandel]

[...]
The ZTEX USB-FPGA 1.15d LX-150 based, with a Cypress EZ-USB for flashing, feeding the FPGA with data and USB communication. Uses only one 24MHz oscillator, some schematics available on their site:
http://www.ztex.de/usb-fpga-1/usb-fpga-1.15.e.html

By the way the price of this one beats the Opal board I mentioned earlier. Got an email quote at a unit price of 357EUR, power supply not included.

I find it interesting because of the FX2 chip, but apart from that it has too much: extra DDR SDRAM, extra EEPROM, extra CPLD, microSD card slot. The pricetag is only a factor of 2 above what we hope to achieve (note that they are missing the power supply section and need 3 different voltage rails).

I don't know about the others, but I am in it for the fun of developing a board. The board you linked may be a very good start to get FPGA developers to write code, but once our board is go, it won't be cost effective (unless you figure their support and warranty are worth the price). I am not arguing against the board: it is good for early adopters, but eventually we should beat it.

[O_Shovah]

I have just put a schematic  of my current use of the MSP IO pins into the layout folder.

Its using the naming you have used on your fpga.
Its certainly not complete but a startup.
 

[Olaf.Mandel]

I have just put a schematic  of my current use of the MSP IO pins into the layout folder.

Its using the naming you have used on your fpga.
Its certainly not complete but a startup.
 

Did cosmetic changes to the design: Vccio should point upwards.

[grid]

I don't know about the others, but I am in it for the fun of developing a board. The board you linked may be a very good start to get FPGA developers to write code, but once our board is go, it won't be cost effective (unless you figure their support and warranty are worth the price). I am not arguing against the board: it is good for early adopters, but eventually we should beat it.

I agree 100%, that's exactly why I posted this, perhaps not being too clear about it. I treat this as a reference point, perhaps to learn from the design also.

I might get the board just to get a start with FPGA's, but otherwise it is reassuring that we seem to be on the right track complexity and price-wise.

[Olaf.Mandel]

[...]
I might get the board just to get a start with FPGA's, but otherwise it is reassuring that we seem to be on the right track complexity and price-wise.

I would, too, if there wasn't the issue with the software: where to get the ISE Logic edition for a reasonable price (<<1kEUR)?