I have finally begun making changes to the K3rangka code, trying to isolate the implementations of running yosys, nextpnr, and other tools into separate classes. Previously, the implementation was within the resource file that handles the HTTP requests. The implementation handled different type of FPGAs through if statements, which was possible for the ice40 and ecp5 due to their similarities in the open-source design flow. However, the implementation would be very different for the Xilinx 7 series and the Cyclone V as they are not supported with the open-source flow and require Vivado and Quartus to be run.

I decided that the factory method would be the most suitable structure for making these classes because the implementations had differences such as the type of FPGA model they are dealing with, or the command that executes those tools, but similarities as well, such as the input file from the http request and output file to write into. Therefore, those similarities could be inherited from a parent function and the daughter classes could be created based on the FPGA type. This was done for all of the design method stages. I was able to complete making the parent classes for each of the design stages, making the resource file for bitstream generation, and creating daughter classes for the ice40. My next job would be to do the same for the other models of FPGAs.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.