This week’s work was very productive in the way that I was able to complete the design flow from synthesis to bitstream generation (excluding bram content replacement) for all 6 fpga types: Xilinx 7 series, Cyclone V, Cyclone IV, Lattice ECP5, Lattice ICE40, and Spartan 6 (which implements the ISE flow). All flows are able to retrieve a Verilog file, a constraints file for determining the pinouts of the design, and additional arguments to generate a single bit file ready to be programmed. Each fpga company uses different formats and file types for the constraints file, and as long as constraints are written with valid format and valid pin names depending on the fpga model, K3rangka should be running fine. As usual, the Quartus software gave me the most problem, as Quartus does not have an explicit pin constraints file. Instead, the pinouts had to be specified using the “set_location_assignment” command through the tcl, before initiating the actual quartus project (before synthesis). Therefore, I solved the problem by requiring the user to input a text file with tcl commands as if it is the pin constraints file.
For example:
# start of document
set_location_assignment -to clk Pin_V11
set_location_assignment -to LED Pin_W15
# end of document
And in the verilog,
module blinky (
input wire clk,
output wire LED
);
<implementation>
Then K3rangka would get this file and append these commands to other sets of tcl commands which would initiate the Quartus project with the correct device name, top module, and path to the Verilog file. I will have to make sure later that this is documented clearly. As the code implements factory method, it should be quite simple for other models of fpgas or design flows to be added in the future.
As good news, the ICE40 up5k board and Xilinx Zedboard was able to be programmed with ‘blinky’ using the bitstream produced by K3rangka. This confirms that the open-source flow for ice40 and the Yosys – Vivado flow for Xilinx works. Next week, I will be focusing on testing the K3rangka and integrating K3rangka with S3padu.
Side note:
I was not able to see much examples of how the Poco input pipe was to be used in a Poco::Process::launch, so I ran into some small troubles. Here is a simple example to make it clear:
Poco::Pipe pipe;
Poco::Process::launch(“command_1”, Poco::Process::Args({…}), 0, &pipe, 0);
Poco::Process::launch(“command_2”, Poco::Process::Args({…}), &pipe, 0, 0);
It is important that the “.wait()” function is not used on the Poco::Process::launch, or else the “pipe” won’t be able to go from the output of command_1 to input of command_2.
0 Comments