I am getting close to finishing my part of the project, and only have a week and a half left for this internship period. This week, I have completed integrating the K3rangka with S3padu from the synthesis to bit generation to bram data replacement, writing a function similar to icebram that would replace the hexadecimal contents of the ecp5 bram, and finding a way to initialize the bram contents during synthesis so that the software for the fpga could be uploaded first, and then replaced as necessary from the bitstream.
The bram support for the ecp5 in nextpnr seems to have not come out yet, but David Shah (the author of nextpnr) made a Twitter post hinting what the bram block and contents would look like on a post pnr netlist. Therefore, I assumed that the format would be the same if it comes out, and wrote a function similar to icebram.
As for initializing the contents of bram during synthesis, this is possible for ice40 and ecp5 using the $readmemh function in Verilog. The problem was searching for similar methods for Quartus and Vivado. I was able to find the way for Quartus this week referring to “Recommended HDL Coding Styles” in the Quartus handbook: http://www.gstitt.ece.ufl.edu/courses/spring10/eel4712/lectures/vhdl/qts_qii51007.pdf
Quartus accepts both the same hex format given to ice40 or ecp5 using the $readmemh, or a Quartus memory initialization file (.mif) using a vendor-specific syntax. To test this, I used both methods to initialize the data on an inferred ram and blink the led according to the contents of the ram, which was successful.
Next week, I will be finishing and cleaning up the bram replacement stage of K3rangka, searching for the bram initialization method for Vivado, and modifying the synthesis step to insert the software.
0 Comments