new changes

[buddynohair]

Hi， Here are the changes i have made

[angl-dev]

Please see comments in bcd2bin.v

There's another problem with the current release in synthesis script generation. Please follow the instructions below:

1. After making the changes I commented in bcd2bin.v, go to examples/target/bcd2bin/tiny_k4_N2_8x8 and run make project
2. Modify 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:

11. Printing statistics.

=== 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

[buddynohair]

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 .

[buddynohair]

changes.zip

[angl-dev]

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.

bcd2bin_host.zip

To apply the changes:

1. Revert your repo back to the state before I commented (you may want to learn about git reset --hard, or git checkout . or similar commands. These commands will overwrite ALL your local changes though, so be careful)
2. Put bcd2bin.v and bcd2bin_host.v in examples/target/bcd2bin
3. Put mux8to1.v in prga.py/prga/renderer/templates/
4. Go to examples/target/bcd2bin/tiny_k4_N2_8x8, run make project
5. Put 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.
6. Run make synth, you should see the same as my results.
7. You can run make till the end, but even if you get a pass, you haven't tested 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.

[buddynohair]

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. ...

[angl-dev]

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.

[buddynohair]

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.

[angl-dev]

@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:

1. All FPGAs contain combinational loops in nature, and so do PRGA. Real FPGA CAD tools would panic because of them.
2. Even if you manage to put PRGA on a real FPGA, you'll need to characterize the timing of PRGA and annotate it back into the VPR XML files. Otherwise the target application you put on PRGA would almost definitely violate setup or hold timing.

[buddynohair]

Hi, really thank you for the infos. I already saw the problems xD. And my teammates will work on this.