Topic: Modular FPGA Miner Hardware Design Development - page 14. (Read 119320 times)

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?

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 $$$?

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


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.


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 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?


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


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.


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?

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.

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

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.

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.

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

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'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?

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.

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

There were several guys who promised to help with the software side of things.
I'm generally willing to help, and have limited experience with Xilinx, but could do µC stuff as well if need be.
However there were people who claimed to know the MSPs by heart, so that's probably their job.


The 190MH/s claim originally came from ArtForz as well. He also claimed to build a 6GH/s FPGA rig (~350W total) for ~$6-8k.

Uploaded new sch and brd files to the main folder, which combines both the FPGA routed so far and the PSU, I haven't layed out everything yet, about to hit the sack, it's now 4AM here.

What I've done:
1. Put layer names for better clarity
2. Put in the PSU in a new sheet
3. Layout most of the components on the board


Need to do:
1. Split up the VccInt for both FPGAs (I'm planning to power them seperatly)
2. Complete routing the PSU
3. Maybe provide a little bit of seperation for the Jtag traces, I don't like how they are all in the same plane right now.
4. Put in suitable clock(s).
5. Put in the MSP430

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.

Regarding the IO pins of the FPGA's: If there is no really pressing need for unused IO pins to be accesible for debugging i vote against routing them out as it would produce a lot more work and complicate design.
Altough it might be an option to route a few pins in case they are really nessecary.

Please someone state if we really need those routing out as otherwise we would just skip it.   

Actually, making the voltage on the NC pins selectable pretty much requires you to merge VCCAUX + VCCIO to free up a layer.

Correct me if I am wrong: putting all unneeded pins onto an extra net allows to test things like power consumption during configuration and operation for different connected voltages, maybe check if some weird effect makes one voltage connection more stable than the other. But except for some esoteric problem, there is not much difference between VCCIO and GND on the pins (if the FPGA bitpattern matches that).

The merging of the VCCAUX and VCCIO is "bigger", though: it frees up a layer, but we actually have to test if there is really no filter needed (National Webbench recommends one).

I do have access to the Dropbox. Your new method works perfectly though, so stick with that.


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 have a feeling it's mostly unnecessary and definitely complicates things. Like I said earlier, though, I can't seem to find a good answer in the documentation about how best to handle those unused pins. One possibility seems to be to connect them all to GND, then set them as outputs driven low. We need someone with experience to make a decision about this. You could post a question on the Xilinx forums...

Yeah, that's what I was afraid of, let's not do that, in fact I think we can leave Vccaux and Vccio seperate still and join them upstream later in case we need to put in some filters to make it work. We still need to split the Vccint. I'm trying to route in the PSU as part of the board.

I was trying to route the FPGAs with all unused pins on a new net (for later connection to whatnot). This pretty much destroys my GND layout. GND would have to go to a different layer and the top polygon would have to become this NCPINS signal. How important is that, actually? I would hate to do that if it turns out that this was just a nice to have feature that noone really needs, even for debugging.

I uploaded a new version of the board to both dropbox and github:



The new version fixes a bug where M1 of both FPGAs had the wrong connection (GND instead of VCC_O). I only uploaded the schematic and board, not a new PDF or PNG. You cannot even see it in the bitmap and in the PDF of the schematic: just imagine that M1 is connected differently or open the actual Eagle files   

Alright, so we're pretty much basically set in terms of IOs required. Do we still want to route IOs out? IMO it's a waste of time, but if it helps debugging I'm all for it.