Exception at com.xilinx.rapidwright.design.Cell.getCompatiblePlacements(Unknown Source)

[zslwyuan]

Hi all!

Thanks for your great effort to implement RapidWright.

I am facing a problem where I call getCompatiblePlacements() with a cell in type of LUT3:

Exception in thread "main" java.lang.NullPointerException
at com.xilinx.rapidwright.design.Cell.getCompatiblePlacements(Unknown Source)
at com.xilinx.rapidwright.examples.ReadDCPAndAnalyze.main(ReadDCPAndAnalyze.java:112)

I am confused. Another question is that whether we have the approach to inquiry via RapidWright to get the available location of the specific cell type in the current design?

Thanks in advance for your suggestion!

Best regards,

[clavin-xlnx]

Thanks for pointing out the error, it looks like Cell.getCompatiblePlacements() could use some attention. Its hard to say without looking at your specific design, but each Cell should have a logical netlist cell instance equivalent (EDIFCellInst). You can check this by calling Cell.getEDIFCellInst() on the LUT3 instance in question and it coming back non-null. Feel free to post the design DCP if you would like me to confirm.

I will rewrite this method to avoid the error and be more robust in the face of inconsistent netlists and will put it in the next release.

To answer your other question, if you would like know the placement of the Cell, you can call getSite() and getBEL() or getSiteName() and getBELName() to get the placement information. If those methods return null, then the cell is unplaced.

[zslwyuan]

Hi Chris,

Thanks a lot for your prompt reply and continuous effort! ^_^

You are right. Actually, when I call Cell.getEDIFCellInst(), it returns null.

In this link of Google Drive is the checkpoint archive with EDIF files (because I am not sure whether you can open the encrypted dcp file.)

Below is my simple code to read the files:

        Design design = Design.readCheckpoint(args[0], CodePerfTracker.SILENT);
	Device device = design.getDevice();
	
	System.out.println("The name of the device is: " + device.getName());
	System.out.println("The Num Of Clock Region Rows is: " + device.getNumOfClockRegionRows());
	System.out.println("The Num Of Clock Regions Columns is: " + device.getNumOfClockRegionsColumns());
	System.out.println("The Num Of SLRs is: " + device.getNumOfSLRs());
	
	System.out.println("Some cells in the design: ");
	int tmpCnt = 0;
	for (Cell tmpCell : design.getCells()) {
		System.out.println("    " + tmpCell.getName() + " ==>Type: " + tmpCell.getType() + " siteInst: " + tmpCell.getSiteInst()+ " BEL: " + tmpCell.getBEL());
		tmpCnt ++;
		if (tmpCnt>9) break;
	}

Thanks again for your time and patience! ^_^. I am trying to implement a more fine-grained placer with RapidWright so I wonder whether the related part can be open and maybe we can try to contribute to the tool too.

[zslwyuan]

Hi Chris,

Hope things go well!

I am facing another problem of the variable "private Map<String,EDIFNet> internalPortMap" in EDIFCell.

I found that for some EDIFcells, which are encrypted in EDN files, even there are internal nets mapped to the corresponding EDIFPorts, after EDIF parsing, the variable internalPortMap could be still null.

In the same DCP file I uploaded in the last reply, you can repeat the problem by checking the instance:

design_1_i/face_detect_0/inst/face_detect_fdiv_4jc_U141/face_detect_ap_fdiv_3_no_dsp_32_u/U0/i_synth

The cell type of this instance is design_1_face_detect_0_0_floating_point_v7_1_10_viv__parameterized15__1, a HLS-generated floating-point FU, where there are internal nets which can be found in Vivado. I notice that this problem is caused by encrypted cells (in EDN files) but I wonder how we can handle this situation?

However, the cell are NOT really encrypted. As I checked, this module is not encrypted in Vivado implementation, which means that actually I can somehow extract those information via get_cells, get_nets and get_pins, but when I use Tcl command write_edif to try to extract its netlist, the output will be an EDN file. Therefore, I am confused.

Any suggestion will be REALLY APPRECIATED! T_T

Thanks again!!

[clavin-xlnx]

Thanks for sharing your design. In reference to your previous comment, yes there are some APIs in RapidWright where the source code is closed at the current time. Not sure when if/when we might be able to make that available, but I am happy to work with you to come up with creative solutions around it.

You are also correct in your assessment of the encrypted cells that are stored in .edn files. Currently, several IP blocks that are synthesized in Vivado are also encrypted post-synthesis. RapidWright is unable to read/modify the contents of those cells that are encrypted, but it can make some changes related to placement and/or routing. The internal nets are missing as RapidWright must treat those EDIF cells as a black box when loading because it is unable to read the .edn files.

In the netlist view of Vivado, you can browse the netlist but certain elements of it are still encrypted when written out as EDIF. Even in the GUI, some parameters are not visible and so it is not possible to reconstruct the netlist perfectly using Tcl commands. I recognize this is not ideal, but in the short term, I would just suggest possibly avoiding encrypted IP if you need to perform fine-grained manipulation or analysis on the design.

[zslwyuan]

Hi Chris,

Thanks a lot for your patient explanation!

I check the encrypted cells in Vivado and it seems that actually only the truth table of LUTs and the initial value of FFs will be hidden when the instances are encrypted. Therefore, I am trying to reconstruct the netlist in RapidWright with information exported from Vivado Tcl.

Thanks for your time, effort and suggestion!