FPGA Power Consumption

"Please give me  FPGA power consumption at maximum load"! This is not such an uncommon question. This is what FPGA SoM vendors hear all the time.

Answer? The direct answer is: cannot tell.

FPGA is a very complicated device that can burn a very different amount of power depending on the loaded design. Most FPGA's can be converted to an HEATER that generates lots of heat and burns lots of energy. So the "maximum load" does not make sense, maximum loaded FPGA makes no sense, except being a heater.

The good thing is that with a somewhat reasonable design, the FPGA consumes a reasonable amount of energy. How much? To answer this question, pretty much all FPGA vendors provide power estimator tools in some form. Some versions are Excel worksheets, some are power calculator apps. In both cases they provide an estimation how much power will be used. Important is to notice that the power consumption depends on the FPGA Die temperature. At higher temperatures, the idle current increases a lot. So it may be good to play with the temperature settings in the power estimator tool. The tool may have different names, be it XPE, PDM or PTC or something else.

So if you need to know how much current you must be ready to deliver to the FPGA SoM, run the power estimator first, then calculate the power losses in the onboard DCDC regulators, and you get some indication of how much current is needed.

Ballbark numbers? (For FPGA SoM's):

If you have a very small FPGA running a soft processor core at 100MHz and some low-speed peripherals, chances are that you consume less than 1W total.

AMD Zynq-7 based SoM with small FPGA fabric and low load on the FPGA? Calculate with a minimum of 3W.

SoM power consumption depends on the FPGA power and power losses in the DCDC regulators. While DCDC regulators have decent efficiency, it is peaking usually at 75% of the max load. The power losses at low currents can be rather big. So, for example AXE5000 board consumes about 1.7W doing nothing, whereas Altera PTC tool says that the FPGA consumes 0.67W, so about 1W must be power losses. AXE5000 uses 5x times TDK's FS1606 DCDC converters that can deliver each up to 6A, those DCDC are not optimized for low loads and consume about 200mW each at very light loads. So there is no mystery where the power goes.

So you always need to calculate FPGA power consumption and DCDC power losses.

God may Exist!

 All my life I have been an atheist, never believing I could ever believe in God. But now I truly believe that God may exist. 

USB Blaster III

 Altera Quartus release 24.2 brings some surprising news. The installation includes DLL files with "blaster3" in the filename, so the USB Blaster III support is really in the distribution included. There has however been no public announcement yet. The real release of the UB3 is planned for Quartus version 24.3, so this is the time when it will be announced. 

UB3 is based on FTDI's FT4232H chip. For onboard solutions, FT2232H can also be used. A single RGB LED is used for status. Integration schematics will be made public. No license or fee is required; anyone can use the onboard UB3 solution.

As of today USB-Programmer2 von Trenz Electronic uses UB3 compatible circuitry. For some reason Quartus 24.2 still does not recognize this programmer without Arrow DLL's, so we all need to wait 24.3 release.

LiteX test on CR00103

This is a quick and dirty guide about the process of how I got Litex to work on CR00103 board.

I have to admit that I have not generated any LiteX SoC designs lately. But I had some known working projects, so to start I did take the top.v and mem init files from one of the old known working projects.

Creating a new Radiant project and selecting the device. Adding files. I am copying the VexRiscv_min file also in a local folder so it is easily found in the project. 

Creating PIN constraints. Done.

Well not yet there, the top.v I am using requires 100MHz clock, and I only have 12MHz on CR00103. So starting IP Wizard and generating PLL named mypll.

Changing the top verilog to use newly created wire clk100 and adding at the end:

    mypll __(.clki_i(clk ),

        .clkop_o(clk100 ));

Done. Does it work?

And indeed Litex is booting well. You can see how old the LiteX project is from January 2022.

Maybe I should give LiteX another try and regenerate directly from CR00103. I kind of did give up updating the LiteX board's support when many incompatible changes happened to LiteX. But I guess it is more stable now as a lot of time has passed.

Ah, let us publish the code, so others can experiment as well. Done, here:

https://github.com/micro-FPGA/CRUVI/tree/master/carriers/CR00103/test_litex

Gatemate SoM

Today I got from our production the first samples of the world-wide first GateMate SoM TEG2000.

For initial testing, I grabbed a TEB0707 4x5 SoM carrier board.

Inserting TEG2000 into TEB0707 motherboard. Checking power supply requirements, aha 5V! Need to adjust the lab supply that was previously set to 12V.

Power on! No smoke, so far so good. One RED Led on TEG2000 is on. 

Starting ToolZ, clicking detect! Cool the JTAG ID is reported successfully. The module is not dead.

Do the GateMate programming tools also work? For this, we need to use Zadig first. Replacing the driver for the first instance (channel A) of the FT2232. Executing:

run.bat jtag

the RED led goes off, it seems that it is inverse DONE. So we have the GateMate FPGA configured successfully. The default LED blinky is not blinking as I did not adjust the PIN constraints yet.

Pressing F4 in FAR Commander and looking at the constraints, comparing with the TEG2000 schematic. Aha, the CLK pin happens to be the same, but the LED location is different, adjusting it. What about the reset pin? TEB0707 has a user button that I could use for soft reset, but for LED blinky we do not really need a real reset, a dummy is equally OK. TEG2000 happens to have one I/O pin connected to GND and one I/O pin connected to VCC, so it is ideal to be used as a fake reset. Adjusting the pin-map file for this. 

running GateMate tools again. And we have an LED blinking on TEG2000! Amazing!

TEG2000 has 8 I/Os connected through auto direction sense level shifter to fixed function pins of the 4x5 standard. As example FT2232 channel B UART pins are connected to those I/Os. So we could also test UART function. Adding the rxd and txd ports to the blink.vhd file and in the body of the VHDL file:

    txd <= rxd;

Done! This if all goes well should implement UART echo so we can verify FT2232 channel B. OK, we need to adjust the pin constraints also for the UART. Done! Running the tools and configuring the FPGA. Starting Putty terminal, and indeed we have an echo! So the pin mapping is correct and the level shifter works as well. Great!

What about starting from SPI flash?

run.bat jtag-flash

Can it be that fast? Clicking master reset button on TEB0707. And the LED blinks again, did it really load from SPI flash? To be sure I turn the power off and on again, and indeed the FPGA is loaded and the user LED blinks.

Now all we need is some documentation! But I can list the main features here:

• Format: Trenz Electronic 4x5 (40 x 50 mm)
• B2B Connectors: 2 x Samtec LSHM
• SPI Flash for booting
• JTAG 3.3V (via level shifter)
• 6 I/Os in fixed 1.8V bank
• 8 I/O with 3.3 I/O voltage (via level shifter)
• 48 IO's in variable VCCIO bank A (1.8V...2.5V)
• 48 IO's in variable VCCIO bank B
• 18 IO's in variable VCCIO bank C
• Gigabit Transceiver pins in the connector, one lane
• User LED, Green
• Status LED's Red
• Power supply DCDC converters
• 100MHz differential oscillator as output to the B2B connector (for GT clocking)

That's it, this is a mini-spec of the module we have. Will soon be available from Trenz Electronic online shop.

Xilinx SPI flash programming with MCU

Sometimes we wish we could program the SPI flash connected to Xilinx FPGA using some MCU. This is easy if the SPI flash pins are accessible. But what can we do if they are not?

Option 1:

If we want we still can use an external MCU for this we need to add "SPI bypass" wires into all designs. SPI flash pins are accessible for the design, we can just wire them to the pins that go to the MCU. We need to use STARTUP directive to get access to the SPI clock, other pins are simply assignable in the constraints.

We have to use JTAG tools once to program the SPI flash with the design that includes the SPI bypass. And later we need to be sure only program images that include the bypass logic. To make it failsafe we can also write a golden image to the end of the SPI flash that we never erase, so if the first image is corrupt the FPGA would still configure with the golden image.

Option 2: We connect the SPI flash to FPGA embedded processor (MicroBlaze) and implement the SPI flash update with Microblaze code, while the external MCU simply gives the code bytes to program into the flash.

Xilinx JTAG configuration with MCU

It is sometimes needed to configure a Xilinx FPGA via JTAG with MCU. This is possible and doable.

Option 1: we look at the XC3SPROG source code and implement similar functions in our code. This is possible if XC3SPROG already supports our FPGA. XC3SPROG has not developed much in the last few years so the FPGA you need may not yet supported. You can try to add support your self.

Option 2: we implement a FULL SVF player function in your code. This is a possible way but you need to be able to create a line buffer that is as large as the SVF file. This is possible when you run embedded Linux, but not doable if you have a microcontroller in your system.

Option 3: This is a method that can be implemented on pretty much any MCU. We split the programming into 3 operations:

• playback_tms_tdi(constant_buffer_HEADER);
• playback_tdi( BIT_FILE );
• playback_tms_tdi(constant_buffer_FOOTER);

Function playback_tms_tdi takes a string of bytes and pushes the lower two bits to TMS and TDI pins of the JTAG interface then toggles TCK

Function playback_tdi takes raw data and pushes it to the TDI pin and toggles TCK, this is where the actual bitstream is sent to the device.

Now we only need the header and footer arrays, right? Ok, we can easily get the header/footer from Xilinx generated SVF file, well in SVF format. We can use a text editor to extract the header/footer portion. But how to get the constant array that is suitable for our simple playback function? For this we will use an SVF player from GitHub! This SVF player parses the SVF file and creates an array with TMS TDI in the lowest bits, exactly what we need for our simple playback functions. We can a bit modify the header and footer SVF before conversion by removing all READ commands we do not need them when we are doing plain bitfile programming.