CellPin WEBWE[0] on RAMB18E1 has no mapped BelPins

[trharoldsen]

This might fall into the issue of determining cell pin -> bel pin mappings for cells which vary based on their configurations, but while packing, I came across this issue. Kind of a show stopper for me.

[trharoldsen]

Did we ever resolve a work around for this situation?

[ttown523]

This is not a bug. BRAM pin mappings change based on how they are configured and we never found a good way in tcl to extract all possible configurations in a reasonable amount of time. Plus rapidsmith needs to be updated to handle configurable pin mappings that are based on a cells properties. On import we generate the correct pin mappings for a placed design, but we don't have this information in general. It is not a trivial problem.

We chose to leave finding the pin mappings up to the user because there were higher priority things to do at the time. The documentation shows how to find pin mappings in Vivado (there is a sample Tcl script). I think I have Tcl code somewhere that tries to find the configurable pin mappings for a cell that you can use and add to your code. I will have to look for it later tonight or tomorrow.

[trharoldsen]

Whether this is what's best or not, this still makes packing for me an impossible task.

[ttown523]

Why is it impossible?

1.) Do you even need pin mappings for BRAM sites? The intrasite routing within these sites is simple, and Vivado can automatically determine the pin mappings once a cell is placed onto a BEL. Seems to me like you don’t need this information for BRAMs, but I could definitely be wrong about this.

2.) But if you do, then why can’t you keep a list of configurable cell types in your code (or add this as a property on the library cell in RS2), and for each of these cells keep a data structure that holds pin mappings for each configuration? In this case, my code described above would be useful.

[nelsobe]

Are you saying that all the other cell pin -> bel pin mappings were there in the design and this one was missing? Or, are none of them there and this is simply the one you have chosen as an example of the problem? Trying to understand the boundaries of the issue.

[nelsobe]

We have done an inventory and for Artix7, the following Cells which have pins with no mappings are limited to just these:

FIFO18E1
FIFO36E1
IDDR
IDDR_2CLK
OBUFDS
OBUFTDS
ODDR
RAMB18E1
RAMB36E1

For each one, there are a few sets of pins that are not mapped, which means they are not connected for the default cell property combination. The logic in the Tcl code looks to be:

place a cell on every BEL in the device (or type of BEL)
for those that succeed:
look at the pin mappings that result and add to a data structure

This is done using default cell property values.

In the case of this issue (#291) , the WEBWE[0] cell pin is not tied to anything when placed on a RAMB18E1. But, this would change if the cell properties were changed appropriately. But, there are too many combinations to try all of them. So, we want to only try the ones that actually get used... :-)

Possible Options:

1. Not support use of the above cells :-(
2. Flag cases when non-default cell properties are encountered for these cells and require the user to manually build a map for the cases that arise.
3. Use VivadoConsole to fire up Vivado, set the cell properties that were encountered, place the cell onto all BELs, and record the mappings. This would be done on an as-needed basis (and would suspend the CAD tool like the packer while it was done). But, once done and the information cached, life would be good...

What are the pros and cons of these? I like option 3 because I assume it could be rare that it has to run but it allows RS2 to be complete. It would make some tools (like Travis' packer) hiccup for periods of time when new designs are encountered, but would at least allow them to handle all designs. Option 2 is better than 1 but would require the user to manually create the info. Might as well figure out how to do it automagically...

@ttown523 - can you comment on the feasibility of option 3 above?

[nelsobe]

Been looking at configurable pin mappings the past few days and have the outlines of an approach done (and some code written).

However, I am not sure if the original issue posted for this really has to do with that (configurable pin mappings) or something else. @trharoldsen, can you comment on the original issue? It sounds like:

• You have a design which actually is using the WEBWE[0] pin on a RAMB18E1 but the RS2 data structures do not tell what BEL pin that should be mapped to.
• The question would then be is this due to configurable pin mappings (meaning the RAMB18E1 has some non-default properties set which would change the mappings)? If so, then the configurable pin mapping fix will address this.
• Or, is it using default properties and this is just an error for some reason which we need to track down?

Can you provide the design so I can take a look at it? Also, can you answer whether the design had originally been packed by Xilinx or not? (If so then the import process would have recorded the mappings. If not, then you would have no way of knowing what the mappings should be).

[trharoldsen]

Waiting on PR #337