Closed buddynohair closed 3 years ago
Please see comments in
bcd2bin.v
There's another problem with the current release in synthesis script generation. Please follow the instructions below:
bcd2bin.v
, go to examples/target/bcd2bin/tiny_k4_N2_8x8
and run make project
synth.ys
:
read_source:
read_verilog ../bcd2bin.v
begin: script /path/to/prga/examples/fpga/tiny/k4_N2_8x8/syn/synth.ys read_library hierarchy -check -top bcd2bin
synth: script /path/to/prga/examples/fpga/tiny/k4_N2_8x8/syn/synth.ys coarse:
backend: write_blif -conn -param bcd2bin.blif
3. Run `make synth` and make sure you get this at the end of the log:
=== bcd2bin ===
Number of wires: 40 Number of wire bits: 96 Number of public wires: 16 Number of public wire bits: 55 Number of memories: 0 Number of memory bits: 0 Number of processes: 0 Number of cells: 63 $_DFFP 22 $lut 40 mux8to1 1
Hi, i followed your steps, but i didn't get the same result as yours . And i don't understand why i can't push the changed files to my GitHub, that's why i give you the zip folder instead, which includes the changed files .
Hi @buddynohair I'll simply include my changes in this reply. You can follow these changes as a starting point, but I suggest you learn more about synthesis in general, and how synthesis serves as the first step in the FPGA CAD flow.
To apply the changes:
git reset --hard
, or git checkout .
or similar commands. These commands will overwrite ALL your local changes though, so be careful)bcd2bin.v
and bcd2bin_host.v
in examples/target/bcd2bin
mux8to1.v
in prga.py/prga/renderer/templates/
examples/target/bcd2bin/tiny_k4_N2_8x8
, run make project
synth.ys
in examples/target/bcd2bin/tiny_k4_N2_8x8
. This must be done after make project
. We want to overwrite the synth.ys
generated by it.make synth
, you should see the same as my results.mux8to1
yet. This is because in your bcd2bin_host.v
, you don't have any testing logic for the module yet. That is another topic though.Hi, i followed your steps and tried out if i can generate a new FPGA with the mux8to1. However there's an error, what means the submodule "mux8to1" has no out-going edges. ...
Hi @buddynohair this is a VPR error. The reason is there are no timing arcs associated with the pins.
Workaround: in build.py
, change your mux8to1
definition to:
mux8to1 = ctx.build_primitive("mux8to1")
out = mux8to1.create_output("out",1)
sel= mux8to1.create_input("sel",4,vpr_combinational_sinks=("out", ))
data_in= mux8to1.create_input("data_in",8,vpr_combinational_sinks=("out", ))
NetUtils.connect([sel,data_in],out,fully = True)
mux8to1= mux8to1.build_logical_counterpart(verilog_template = "mux8to1.v").commit()
Also, remember to fix the grammar errors in mux8to1.v
. You'll then be able to see all tests passed
. Again, mux8to1
is NOT tested in this flow.
Hi, thank you very much for your help, the FPGA is finally generated. And thank you for your warning, but i don't think it's necessary to test the mux8to1 here , because i wanna put the whole PRGA on the xilinx developing board later and test it again.
@buddynohair no problem. But be aware that putting PRGA onto a real FPGA is yet another big challenge (this is called FPGA overlay and there are previous studies on this). PRGA is mostly intended for tape-out and not for FPGA overlay.
Let me be more specific here. PRGA generates RTL that IS an FPGA, NOT something that should be MAPPED onto a real FPGA. Most synthesizable RTL can be either put on a real FPGA, or synthesized with standard cell libraries for ASIC tape-out. PRGA is for the latter.
The problems with putting PRGA onto a real FPGA are two-fold:
Hi, really thank you for the infos. I already saw the problems xD. And my teammates will work on this.
Hi, Here are the changes i have made