Wednesday, May 24, 2023

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.







Wednesday, February 8, 2023

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.

Friday, November 4, 2022

Xilinx FTDI without a Digilent license

Xilinx FTDI without a Digilent license. Starting from 2022.2 (or earlier?) Vivado distribution includes an FTDI programming utility that makes the FTx232 devices visible in the Vivado hardware manager. So no need anymore for the secret and invisible Digilent license string! UPDATE the invisible license is still needed, it is silently written...

https://docs.xilinx.com/r/en-US/ug908-vivado-programming-debugging/Programming-FTDI-Devices-for-Vivado-Hardware-Manager-Support 

This is nice that we do no longer need to use the licensed FTDI tool to write into the hidden User EEPROM for Xilinx tools to recognize the programmer dongle. Well, the hidden EEPROM is still used and needed, so if we use FT_PROG to write the FT2232 EEPROM, the hidden license will disappear and the programmer will not be recognized anymore.

Interestingly the provided schematic does not provide support for the Zynq SRST pin :(

Interestingly this Xilinx forum post seems to describe some more used pins:



Thursday, October 27, 2022

Configuration of FPGA with MCU.

 How to configure Xilinx FPGA with MCU using JTAG? This is actually pretty simple, pseudocode:

send_header();

send_raw_bistream(bitstream);

send footer();

The functions send_header and send_footer do some TDI/TMS toggling, send_raw_bistream sends raw bitstream data from the bitstream to FPGA TDI pin (note bit order in the bitstream!).

How to implement send_header/send_footer? The easiest and smallest footprint for the MCU is to implement 2 bit playback function, so the pseudocode would look like this:

send_tdi_tms_bits(header_2bit_file);

send_raw_bistream(bitstream);

send_tdi_tms_bits(footer_2bit_file);

How to get the 2 bit sequences for the header/footer? OK, this is one known working and relatively simple approach:

1) You generate with Xilinx Vivado an SVF file for your target device. If you look at the generated SVF you can quickly see three sections there, there is a header, then raw content, then a footer. Look at header/footer only, you do not want to convert to 2bits the raw data.

2) cut out the header and footer with some text editor

3) remove the ID code check lines from the header, you do not need that! And your MCU playback would be WRITE only with no readback or verify functions.

4) get SVF player code from say maybe here: https://github.com/xaxaxa-dev/svfplayer it looks like useable but I have not compiled this code myself

5) modify the SVF player to emit 2 lower bits of each processed byte, this is an easy exercise for anyone with moderate C experience.

6) play header and footer SVF files with your SVF_to_2bitsfile.exe you created in the previous step.

7) implement for your embedded MCU function send_tdi_tms_bits() and send_raw_bistream(). Use the pseudo code from above on your MCU to configure the FPGA.

OK, there is a little bit of tweaking required, you possible need to insert a delay during header playback, and the line RUNTEST 10000 TCK; should possible also be implemented as direct code with your MCU sending 10,000 TCK cycles without change on TDI/TMS.

OK, the idea should be clear. Happy bit toggling!

How to do it on Rasperry Pi PICO? First of all we need wiring, to save time on the documentation we can take the Pico pin mapping from here: https://github.com/phdussud/pico-dirtyJtag/ Already saved some minutes of work :)

Now we need the function send_tdi_tms_bits as this function is rather short compared to the main junk bitstream pushing we can use machine.Pin class it will be slow but it does not matter. We assume that the 2bit file is generated with the svfplayer with TMS being bit 0 and TDI being bit 1 in the saved file.

from machine import Pin

tms = Pin(19, Pin.OUT)   # TMS: create output pin on GPIO19
tms.on()                 # set TMS to "on" (high) level
tdi = Pin(16, Pin.OUT)
tdi.on()
tck = Pin(18, Pin.OUT)
tck.off()
The above creates pins for TCK, TDI, and TMS, as we are WRITE only interface we do not need to assign TDO to anything, we will not use TDO at all.

Now my python skills are not enough :( but let's give some hints how to proceed:

def send_tdi_tms_bits(byte_with_2bits_in_it)
    tms.value(byte_with_2bits_in_it & 1)
    tdi.value(byte_with_2bits_in_it >>1 & 1)
    tck.on()
    tck.off()

ready :) OK I mixed C and python programming(or did I?). This function needs to be called with the bytes our svf_to_bits converter wrote for the header and footer.

Now, what's next? We need to send the bitstream too right? OK, we can do it using the machine.Pin functions but it would be really slow. OK, for the proof of concept it does not matter.

Later we should optimize the bitstream push using the Pico PIO peripheral, some links:



This is now beyond my current python skills, so it is left to the reader to implement the bit sending with PIO.


Thursday, June 30, 2022

Lattice AVANT is coming

There is not much info published yet, but if you google "Lattice Avant" you get some stories about it. What is known: released date H2 2022, so at the end of the year we should hear more about this product. FPGA core size at least 300,000 Logic Cells. That's about all that is known without NDA. Excited, only a few more months to wait.

Avant official release will be 5 December 2022! So then we can all talk more.


Friday, June 3, 2022

Java to FPGA

Surprise, surprise, at least two projects promise java 2 RTL (VHDL, Verilog) conversion suitable for execution on FPGA!

Java2VHDL is currently only experimental but LED blink at least works. The current work seems to support directly only Lattice Diamond tools. Here is a link to the project Java2VHDL. The LED blink and other examples are tested on this tiny board XO2000.

---

There is another Java converter, called synthesijer, with web and GitHub for project code. This project uses Xilinx evaluation boards as target hardware.


Monday, May 30, 2022

ArrowBlaster Internals


 ArrowBlaster (TEI0004) and ArrowBlaster SMD (TEI0005) are both based on FT2232H USB FIFO chip. There are no custom OS drivers involved, the standard FTDI drivers are used for both. What is downloadable from Trenz Electronic website as "driver" is actually a DLL/SO dynamic library for Windows/Linux for Quartus to recognize the programmer hardware. This DLL uses channel A (ADBUS0..3) in MPSSE mode to access the standard mapping JTAG pins connected to it. ADBUS7 is connected to RED LED (active low) and it is used as a busy indicator by the Arrow software DLL.

Quartus <> Arrow "driver" DLL <> D2XX library DLL <> FTDI USB drivers

ADBUS4 (named PROC_RST on TEI0004) is described in the documentation as "for future use" but it is highly unlikely that the Quartus DLL will ever utilize this pin. So it is free for use by the end-user applications. So at any time when the Quartus is not accessing JTAG ADBUS4 can be controlled by the user application over D2XX DLL/SO. One example of usage would be control of the JTAG Enable signal - some FPGAs (like MAX10) can use the dedicated JTAG pins in User Mode. During programming and debugging the JTAG would be enabled, and then in user mode, the end-user application would access ADBUS0..3 via D2XX say like an SPI port between the user application and the FPGA code. FTDI provides lots of examples of D2XX library use.

Arrow driver does not access channel B at all, so it is free for the end-user at all times. Channel B is free for end-user to be used as an extra UART channel to the FPGA. On TEI0005 there is one more pin BCBUS0 available to the end-user. This could be controlled over D2XX DLL easily. It is also possible to control the UART function over D2XX so in this case, the end-user could use port B UART and one GPIO pin at the same time. Another use case could be channel B as UART via VCP drivers, and channel B ADBUS4 as GPIO over D2XX at the same time (Quartus not active).

Third-party software that supports FT2232H can also use these adapters. One example application is SVF player.

FT2232H EEPROM is programmed with "Quartus License" information, if you erase or over-write it, then Quartus would no longer recognize the dongle. It is possible to convert the adapters to Microsemi programmer (TEI0004 VREF pin would not map to Microsemi pinout so custom wiring is needed in that case).

Some use cases:

Case 0:

  • Channel A - Quartus or 3rd party FT2232 JTAG software active
  • Channel B VCP UART
  • ADBUS4 not usable
  • BCBUS0 not usable

Case 1: 

  • Channel A - No JTAG software active, or custom D2XX software
  • Channel B VCP UART
  • ADBUS4 D2XX custom software GPIO1
  • BCBUS0 not usable

Case 2: 

  • Channel A - No JTAG software active, or custom D2XX software
  • Channel B D2XX UART
  • ADBUS4 D2XX custom software GPIO1
  • BCBUS0 D2XX custom software GPIO 2