MEGAphone FPGA board carrier modules

Time for another couple of modules, neither of which are particularly exotic.  We just need something that can adapt the FPGA modules to our castellated module format. The real benefit of this is so that we can offset the modules by the thickness of the PCB, or mount modules on both sides of the PCB. so that we can reduce the overall thickness of the MEGAphone prototypes, and it gives us more flexibility for the FPGA modules we use.

We'll start with the Trenz TE0725 as the main FPGA.  This has 2x50 pin 0.1" spaced headers.  Our biggest issue is that it has two rows of such pins down each side, which means that if we use our same 0.1" spacing castellated connectors, that the module itself will be quite large.  50 x 0.1" = 5" length for the module.  Annoying, yes. But probably tolerable. Especially since we can put modules on the opposite side of the PCB.  We could save a few pins by reducing the number of GND and power pins. But that doesn't really feel like a sensible idea.

The two connectors on this board are 1.1" apart, and are aligned with 3 pin offset in the other direction.  So let's add those connectors into the schematic and PCB to match what the TE0725 has:

 

I'll place them on the PCB in the right spot, then I can measure the cut-out required, and then use my module generation script to create the footprint.

 

... except it has >64 pins, so my automatic footprint generator doesn't support it. I'll have to hack it to support bigger, and make it just use a simple deterministic gap pin placement algorithm.

Here's the schematic for this board. As said, it's very simple, which kind of makes up for a couple of the other modules that were much more complex.  

 

Ok. Done. I'm really not convinced that this is going to be a good solution, because those double-rows cause pretty horrible routing, as well as being excessively large.

I suspect we'll probably just put the headers directly onto the main assembly boards. But now we know.  I'll still make one up to see just how bad the signal integrity is. Meanwhile, I've come to regard this as a module that I have drawn. Nothing more.  

But in all honesty, if this is the one module that it doesn't make sense to make, then I'm still pretty happy with the whole approach. After all, it would have been a module for a module.

Anyway, let's move on to the FireAnt carrier. That at least has only single rows of 0.1" header down each side -- since it's the double rows on the TE0725 that were the whole problem here.

I was thinking again about whether to instead use an ICEsugar nano as the low-power FPGA board, in part because I have 5 of them sitting here, and I can't for the life of me find where I put the FireAnt boards I'm sure I purchased.  The ICEsugar nanos have 8KB of RAM and the little FPGA is probably big enough for what we need. They are also nice and small. The main problem with them is that they seem to only be possible to power via the USB port.

This is because the power circuit looks like this:

 

The problem is that XC6206-1V2, that is only fed via the 5V USB. It's just a bit important, because it's the power for the FPGA... These aren't step-up/down regulators. So they rely on there being at least ~3.6V or 3.7V to generate the 3.3V output. This is a real shame, as otherwise VBAT (which can drop as low as 2.8V with our single cell LiFePO4 cell) could have been used.

One solution would be to remove U6 and the USB connector, and just run it from 3.3V supplied elsewhere on the MEGAphone.  But removing the USB connector would prevent us from being able to reflash it after initial programming, which is hardly ideal. Or we could leave the USB connector, and risk frying things if we connected it up with some alternative supply.

Another solution would be to feed 5V directly to pin 3 of either U5 or U6, as those pins are large enough to tack to, and fairly accessible.  There could still be back-flow issues if USB is plugged in, but that could be dealt with by putting a diode on it.  

The question then becomes what the power consumption looks like. The ICE40 itself should be very low power, but the RISC-V CPU that talks to the USB bus may well consume a lot more. Hopefully the firmware on it is decent, and it goes to sleep when the USB bus is idle/disconnected.

A bit of quick probing with the multimeter has confirmed which pin on the DC regulators is the 5V input. So I can set my desk supply to 5V constant voltage and to display current consumption, and just measure it.

And it looks ok. My bench supply only shows 10mA accuracy, and it's showing 0.01A @ 5V. If I drop the desk supply to 4V, it's still showing 0.01A. And the same at 3.7V. I could construct the carrier so that if its powered from VBAT it's not physically possible to connect the USB to prevent problems there. 

Actually, you know, we could power this from 3.3V by providing that to the high-side of the 3.3V regulator (so that it gets to the 1.2V regulator's high-side) with a Zener to protect from backflow if the 5V USB supply is connected. Then we could just run it from 3.3V without risk or complication. The 3.3V regulator on the ICEsugar would basically be doing nothing.  

Or I can just cut the traces on the ICEsugar from the 5V pin of the USB-C connector, and require external 3.3V power, connected to both a 3.3V pin on a PMOD and the high-side of the 1.2V regulator. That requires only cutting the trace to the high-side of the 1.2V regulator. That one's a bit more of a pain to get to, but it's totally doable.  Actually, I don't need to cut it: I _can_ use a diode to feed that one, because 3.3V minus a diode drop is still >> 1.2V.  

That's a much better approach, because it's still fail-safe, without needing to modify the ICEsugar board... except that the DC regulators it uses aren't safe for back-power.

But that can be solved by simply removing the 3.3V reg and connecting our 3.3V external power to the high-side pad for that via a diode. A 1N1519 should be fine, and Jaycar sells them.  So I could go buy one today and crock up a test circuit before I commit it to the schematic. Probably wise.

Acquired, regulatorectomy and diodotomy performed, and it all seems to work as expected: I can power and run it from 3.3V, and I can plug the USB in -- or both at once -- and there is a blessed lack of smoke, but happy blinking lights.  I'll solder the diode in place now, and then see if I can talk to the module to program it still. If that works, then I know we're good with this approach. 

I can at least see the USB device:

 

And the power consumption doubles when USB is plugged in, so that's a good sign that the RISC-V CPU might be throttling down when there is no USB. Or just turning off the USB circuit.

So let's see if we can't load an example project onto the ICEsugar, just to wrap it all up. Currently setting up the yosys open-source toolchain.

And we can, using this simple project I made.

I really do like the open-source FPGA synthesis toolchain. Unlike Vivado that takes ~1 minute to synthesise even just a blinking LED, yosys does it in less than a second. And generating the bitstream doesn't take minutes either (no idea why it even should/could in Vivado, but it does).

Apparently the iCEsugar nano can do USB serial as well as its funny fake mass storage device that you just drag the firmware onto to flash the thing.

I'm still mildly concerned that the iCEsugar uses a bit too much power, because of that RISC-V microcontroller on it. But that should be possible to optimise later by writing new firmware for that processor.

But the point is, we have a working low-power FPGA board, and so I can design the carrier board for it.

Annoyingly I can't find drawings of the board, so I have to use my ruler and guess a bit. 

In terms of physical layout, the two rows of pins are 0.6" apart.

The PMOD on the end is not on the same 0.1" grid, however. centre of first row is 18.5mm along from hole at far end of the side PMODs. It's also centred on the other axis. What a pain to get exactly right without a drawing.  You can see what I mean here.

Fortunately their unlabeled diagrams are high enough resolution that I should be able to confirm things to a reasonable degree of accuracy.

Also to add to the fun, pins A1 and B1 are routed to two different PMODs, despite there being 6 unallocated FPGA pins. So while there are potential for 20 pins, and 16 are traced out to headers, we really only have 14. All a bit crap. But it's what we've got.

But this module looks a lot saner than the TE0725 one: 

 

So that's those two. I can try to send them off to PCBWay for ordering now, and then get back to the software side of things for a while.