How to convert the intermediate result of vpr into a dcp file?

[the-centry]

With the assumption of .route file store the pips's names how to convert f4pag's result into dcp file and generate bit through vivado?

[clavin-xlnx]

Good question! We don't have code already written that can perform this transformation, however it certainly could be done. In order to generate a routed DCP, you'll need 3 major things:

1. The logical netlist - this is the synthesized and mapped netlist that contains all the leaf cells and logical cell net connections. This is most easily imported into RapidWright with EDIF (See Design.Design(EDIFNetlist) and EDIFTools.readEDIFFile(Path)).
2. Placement information - This is all of the data associated with placing the leaf cells onto BELs on the device. You can start by finding all the leaf cells in the netlist with an API like EDIFNetlist.getAllLeafHierCellInstances(). Then, you would need to create Cell objects for each leaf cell and place them accordingly with Design.createCell(String instName, EDIFCellInst instance) and Design.placeCell(Cell c, Site site, BEL bel, Map<String,String> pinMappings) where placement and pin mappings (mappings between physical BEL pins are mapped to logical cell pins). Site routing is also required and RapidWright does have a site router that should produce a valid site routing (Design.routeSites()) which could be invoked after all placements are established, but it hasn't been thoroughly tested for entire design scenarios.
3. Routing information - As you mentioned, there are PIP names that could be imported and assigned to each Net. In order to do this, physical Net objects need to be created as well as PIPs. Ideally, the Net objects would be fully created during placement as they are needed for the site routing. If you have the cannonical name of a PIP (<tile>/<tile_type>.<start_wire><arrow_type><end_wire>) you can use Device.getPIP(String name), otherwise you can get a PIP from the number of PIP constructors.

This assumes that the f4pga flow is targeting a specific AMD/Xilinx device and that all of the device information is accurate. It is probably some work to build the translation process, but it is doable and you are welcome to reach out with any more questions.

[the-centry]

Good question! We don't have code already written that can perform this transformation, however it certainly could be done. In order to generate a routed DCP, you'll need 3 major things:

1. The logical netlist - this is the synthesized and mapped netlist that contains all the leaf cells and logical cell net connections. This is most easily imported into RapidWright with EDIF (See Design.Design(EDIFNetlist) and EDIFTools.readEDIFFile(Path)).
2. Placement information - This is all of the data associated with placing the leaf cells onto BELs on the device. You can start by finding all the leaf cells in the netlist with an API like EDIFNetlist.getAllLeafHierCellInstances(). Then, you would need to create Cell objects for each leaf cell and place them accordingly with Design.createCell(String instName, EDIFCellInst instance) and Design.placeCell(Cell c, Site site, BEL bel, Map<String,String> pinMappings) where placement and pin mappings (mappings between physical BEL pins are mapped to logical cell pins). Site routing is also required and RapidWright does have a site router that should produce a valid site routing (Design.routeSites()) which could be invoked after all placements are established, but it hasn't been thoroughly tested for entire design scenarios.
3. Routing information - As you mentioned, there are PIP names that could be imported and assigned to each Net. In order to do this, physical Net objects need to be created as well as PIPs. Ideally, the Net objects would be fully created during placement as they are needed for the site routing. If you have the cannonical name of a PIP (<tile>/<tile_type>.<start_wire><arrow_type><end_wire>) you can use Device.getPIP(String name), otherwise you can get a PIP from the number of PIP constructors.

This assumes that the f4pga flow is targeting a specific AMD/Xilinx device and that all of the device information is accurate. It is probably some work to build the translation process, but it is doable and you are welcome to reach out with any more questions.

Year, .eblif and .net file contains the information of logical netlist, .place file contains the location information of block and the .route file with pips's names contains the net information! It could covert in theory, and I had done it but only supporting simple designs which only contain lut and iob.
Now I want to support complex design, but I found that the data structure I created could't support!

[eddieh-xlnx]

Unfortunately, RapidWright does not support the formats -- .eblif, .net, .place, .route -- that F4PGA/VPR uses and so you'll have to write custom code to import them into RapidWright's data model (or any other data model for that matter).

Alternatively, you may wish to modify VPR so that it exports the information you need into a format that RapidWright supports (such as the FPGA Interchange Format), but that's also quite a bit of work.

In both cases, as Chris alluded to, you'll need the F4PGA flow to use exactly the same device representation as Vivado (down to identical names for all BELs, Sites, Tiles, PIPs, etc.) such that a precise and lossless translation is possible.

Since there is work involved for both of these -- is there something specific you want to achieve that we might be able to find another way to do?

[the-centry]

I had transfer the vpr file into verilog and vivado's tcl but I met a ploblem that the net with much sinks would run wrong in vivado's shell. could you give me some ideas to sovle the problem?
the verilog file and tcl is here, the device is xcvu3p viv.zip
@clavin-xlnx @eddieh-xlnx

[clavin-xlnx]

This is an interesting way to try to import a placed and routed design into Vivado. I am able to run read_verilog and link_design to import a placed version of the design into Vivado, but I'm not sure how to use the .xdc file you have provided. It looks like Tcl code intended to populate the routing where you have Tcl procs that pick out wires and then nodes to assemble the route and use set_property FIXED_ROUTE to populate the routing of the net.

One issue is that using the net name for the Tcl proc name probably won't work as some of those names are invalid Tcl syntax. You would probably need to just rename them "net1, net2, .... netn".

RapidWright is also capable of importing routing directly from PIP objects if that is more readily available.

[the-centry]

This is an interesting way to try to import a placed and routed design into Vivado. I am able to run read_verilog and link_design to import a placed version of the design into Vivado, but I'm not sure how to use the .xdc file you have provided. It looks like Tcl code intended to populate the routing where you have Tcl procs that pick out wires and then nodes to assemble the route and use set_property FIXED_ROUTE to populate the routing of the net.

One issue is that using the net name for the Tcl proc name probably won't work as some of those names are invalid Tcl syntax. You would probably need to just rename them "net1, net2, .... netn".

RapidWright is also capable of importing routing directly from PIP objects if that is more readily available.

yea, my idea is use tcl to constraint the route net, i use the source node to get the net name. But the problem is that one source with much sink would met problem while use FIXED_ROUTE!
RapidWright also could do this, but i don't know how to transfer file into rapidwright!
Thanks so much!