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?