Vivado Vs Quartus for virtual pins

[kaz1]

I have been struggling to find out how to do a sanity check at "module level" design for device fitting.
The problem is that my module interface has so many pin requirements that it just wouldn't fit.
In Quartus we set ports as virtual and get fitting going.
In Vivado I tried all the suggestions on the Internet but all ended up waste of time. I tried:
1) set io buffer to none in vhdl, or in xdc but didn't work.
2) set the "out of context" property but is not available as it is greyed for top interface module.
3) The only way that worked somehow was to have a funny wrapper to reduce pins but this is not that efficient.

So how do people work with Vivado at module level or have Xilinx missed this useful requirement.

Any help appreciated.

 

[dpaul]

The problem is that my module interface has so many pin requirements that it just wouldn't fit.

You need to share the details about your interface in oder to have an appropriate answer.

Otherwise <3> is the way to go, where the Wrapper logic does bus multiplexing.
Else you use a larger FPGA with more number if IO pin count.

 

[kaz1]

Thanks dpaul,

So in short virtual pins are not supported by Vivado and we have to go for various work-arounds.
This is surprising for an advanced tool like Vivado.
Module level fitting for initial resource/timing is simple and essential step before it is passed to integration team.
And should be routine part of development.

 

[ads-ee]

I didn't spend time looking for the specific version of the user guide file for the version of Vivado you use, but look for the hierachical design user guide. On page 4 it describes exactly what you want to do.

Vivado uses partitions to perform this function. You create a partition for the logic and perform elaboration, synthesis, placement, and routing without inserting any I/O. The resulting hierarchical block can then be saved as a DCP (design check point), which can be reused by the team integrating the block.

Xilinx uses this feature for partial reconfiguration and it works quite well.

 

[kaz1]

Hi ads-ee,

That applies to hierarchical design methodology. That requires changing methodology of project. I am not sure about this method and would rather avoid it in team work. Just like in team work we can't do logic lock or floor planning for timing closure...etc as development and changes are dynamic and can't be maintained across until sign off at final release.

I thought setting a module interface directly not to care about using pins for ports is a simple task for tools without the need for specific development plan.

 

[ads-ee]

Using the feature doesn't require that the design methodology for the project be hierachical design, it is just the way to implement a DCP that has the information you require. i.e allows you to check the resource utilization, placement, and timing.

I have been struggling to find out how to do a sanity check at "module level" design for device fitting.
The problem is that my module interface has so many pin requirements that it just wouldn't fit.
.....
So how do people work with Vivado at module level or have Xilinx missed this useful requirement.

Any help appreciated.

Which fulfills the above request.

You don't have to give the integrator the DCP or do anything else with the results, except commit your RTL into your source control with any other handoff information needed by the integrator.

--- Updated Apr 29, 2021 ---

I thought setting a module interface directly not to care about using pins for ports is a simple task for tools without the need for specific development plan.

It is simple, just use a partition flow for implementing the block without I/O, which is what Xilinx has even suggested in the past to perform a "virtual" I/O build. Don't know where I saw or heard this, but it's either on their support site or was something the FAE told me.

 

[kaz1]

I came to think that the document you referred to is talking about same thing as my point 2 (out of context approach). But such selection is greyed on me and is only available for some lower level modules in my level of work. I am not building whole project but just my modules with their top level as mini-project work before being integrated by team.

 

[ads-ee]

I came to think that the document you referred to is talking about same thing as my point 2 (out of context approach). But such selection is greyed on me and is only available for some lower level modules in my level of work. I am not building whole project but just my modules with their top level as mini-project work before being integrated by team.

If I recall correctly OOC is not the same flow, you have to create a partition first then assign logic to that partition, which can then be run out of context and build as a separate block without I/O. Unfortunately I can't create a simple test case and instructions to go along with it as I don't have any Vivado tools installed at this time.

If it is having a problem with making a partition of the "top" level file then put a simple wrapper around it and partition the "wrapper" design, which means you are putting your "top" in the partition.

You'll have to forgive the vague explanations, last time I used this feature was about 8 years ago. Haven't had any need to use it since and have been mostly working with a different vendor's tools.