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.

Xilinx SDRAM IP Core

 I have used plain old SDRAM with different Intel (Altera) FPGAs - as Intel used to have IP core support in the Quartus for free. Well, it used to be free, but now it is removed from Quartus Lite (the option is to install from an older version).

But I always thought that using SDRAM with Xilinx is complicated as Xilinx does not offer plain old SDRAM IP core in the IP catalog.

Until today - I was challenged to test SDRAM on the new version of the MEGA65 home computer. So here is how it did go:

First google: "AXI SDRAM IP core"

taking the first hit, it goes to opencores that has link to the GitHub repository. 

Downloading from GitHub.

Vivado new project, create new peripheral, assigning nets to AXI memory mapped slave, packaging the IP core.

Vivado, add SDRAM IP Core

Vivado, add a new VHDL module - this was needed to have proper tristate buffers.

Vivado add Microblaze, run automation.

Connecting buses, clock and reset and making SDRAM IO's external.

This is what the new IP and tristate module looks like. Synthesize, open the IO window, type in the constraints for the clock, reset, and SDRAM. Starting to Generate Bitstream. Done, starting Vitis, new platform, new application, selecting memory test. Build, debug:

!?! it does not work, there comes memtest starting text then all is frozen. It does not work. What can it be? I did take an untested IP core in the hope it works. I have no intention of debugging this IP core. Looking at the IP core in block design. Ha, reset polarity is wrong! Changing, starting the build. Ready go, starting to debug in Vitis.

And it works!

We now have a free and working solution to support SDRAM on the Xilinx platform!

Easy as that. It did take less than two hours to verify this solution. So SDRAM on MEGA65 R4 is functional! 

It is interesting that it works the way I did it because the original IP core docs show that ODDR primitive has to be used for CLK output with clock inversion. I did not implement this! It is possible pure luck that it worked out of the box.

Adding clock forward block, connecting it to extra clock output from MMCM. Trying a 100MHz clock, working. Trying 133MHz clock working! Trying 166MHz clock, failing :(

Adjusting SDRAM clock phase on the MMCM, setting it to 180 degrees, and voila SDRAM is finally working at 166MHz! Changing SDRAM size to 32M bytes. Testing, working!

OK, trying to give the project for others to test out with the source files. Placing all source code to GitHub, done! Trying myself to open the GitHub project with Vivado 2022.2

OK, some manual tweaking seems to be needed, but with a few minutes of trying the project is compiling again. Seems that the version upgrade from the files provided in github is possible. There is also a MEMT.ELF file that runs 32Mbyte Xilinx memorytest application, it is included as file to initialize the brams so it will start if you program the bit file. Testing new bitfile and working. So the files from GitHub can be used to create working SDRAM test application for MEGA65. What I had todo was adding new IP repository path, changing the ELF file and removing and adding again the RTL modules.

HyperRAM test ok on new FPGA board CR00107

 This board CR00107 arrived yesterday from the production downstairs:

Getting LED blinking was simple but does the HyperRAM also work? Testing out the OpenHBMC IP core. Creating the project and changing constraints. And trying out. And it works, memory tests are passing on the AXI HyperRAM. Cool.

Not so cool, there are random errors when running the memory test in the loop. It seems the issue is related to the relation of axi clock to hyperbus clock. If they are the same 100MHz this causes most failures. Using axi clock of 81.81818MHz and we have way fewer failures.

Changing the hyperBus IP core clocking from BUFG to BUFIO/BUFR mode. And this fixed the issue, no more failures, and also with 100MHz axi clock!

Cool, it REALLY works!

Was happy to fast, after one week of continuous testing, the memory test failed. Pretty hard case to troubleshoot a problem that may come once a week. Next tests seem to fail about once a day, but last test has run over two weeks without failing. Complicated.