VHDL design flatten compilation

[ronhk25]

Hi all,

I have a hierarchical vhdl design, i would like to remove all the hierarchies during the design compilation ("flatten compilation").
My purpose is to import this flattened compiled design into a multiple FPGAs simulation environment in order to prevent duplicate name conflicts during the environment compilation and elaboration.

I'm not sure that "flatten compilation" is the accurate terminology but a good example might be an importing of a third party IP core from FPGA vendor, when i import a FIFO (for example) from Altera of Xilinx all i need is a VHD wrapper file that points to only one vendor compiled library which is mapped to my project (no need to import the whole hierarchical design).

I would like to import my compiled design into my simulation environment inthe same way, does someone know how to do that?

p.s. I tried to import the design as a gate level technology dependent flatfile (VHO file) but the result was a very slow simulation so i would be happy to learn about a better solution...

Thanks,

Ron

 

[Thomas Stanka]

Am Dienstag, 14. Januar 2014 10:17:12 UTC+1 schrieb ronhk25:

My purpose is to import this flattened compiled design into a multiple FPGAs simulation environment in order to prevent duplicate name conflicts during the environment compilation and elaboration.

I understand you assume, that you avoid name conflicts between several designs when importing each design as "flat netlist" instead of hierarchical design.
A flat netlist really requires to synthesis flat and simulate netlists, which is a pain, when doing a simulation containing several complex designs.

The solution to this problem is to use dedicated libraries instead of compiling all into library work. Configurations allow you to be specific about what architecture should be used in which location.

Eg. you have design1 and design2 with both using an entity "rxif", you can configure design1 to use design1_lib.rxif and design2 to use design2_lib.rxif.
This mechanism allows you to haven even several different entities of same name in design, if you use eg. uart_lib and pci_lib for different ipcores for uart and pci. You have an initial overhead when configuring all vhdl code, but in the end it solves a lot of naming problems and is the only possibilty in complex code reuse.

regards Thomas

 

[ronhk25]

Thomas,

I understand that this solution will solve conflicts during the compilationbut won't it be problematic during the elaboration? Does the simulator "knows" to search for the compiled entity in the correct library and bind it correctly? Are you sure that it won't just bind the first compiled entity with the searched name?

Regarding the flat netlist, do you mean that there is no way to create a technology independent flat netlist/compiled file?

Thank you for your help!

Ron

 

[KJ]

I have a hierarchical vhdl design, i would like to remove all the hierarchies during the design compilation ("flatten compilation").

My purpose is to import this flattened compiled design into a multiple FPGAs simulation environment in order to prevent duplicate name conflicts during the environment compilation and elaboration.

What sort of 'duplicate name conflicts' are you talking about? Elaborate abit on what you are actually trying to do and what problem you are actually having.

I'm not sure that "flatten compilation" is the accurate terminology but a
good example might be an importing of a third party IP core from FPGA vendor,
when i import a FIFO (for example) from Altera of Xilinx all i need is a VHD
wrapper file that points to only one vendor compiled library which is mapped
to my project (no need to import the whole hierarchical design).

In what way is what you are trying to do then any different than this example with the FIFO? There is nothing inherently special about a third party IP core, when you instantiate multiples of your own hand written entity it works the exact same way.

I would like to import my compiled design into my simulation environment in
the same way, does someone know how to do that?

You don't "import" designs into VHDL. Within an architecture, you instantiate entities. All of those entities and the architectures for those entities must exist in the library (typically 'work') or you won't sim. There isnothing special that is being done for third party IP that you think you are "importing".

Kevin Jennings

 

[ronhk25]

בת×ריך ×™×•× ×©×œ×™×©×™, 14 בינו×ר 2014 13:54:16 UTC+2, מ×ת KJ:
Kevin,

What sort of 'duplicate name conflicts' are you talking about? Elaboratea bit on what you are actually trying to do and what problem you are actually having.>

I will try to clarify this- Lets assume that i have a hierarchical design, in one of the hierarchies I have an entity which is called "Counter". Now iwould like to simulate my design and i want to buy from you a simulation model of some component, your simulation model is also hierarchical and contains entity which is also called "Counter". Now I have in my simulation environment two different entities with the same name- "Counter", that's what I call a "duplicate name conflicts".

In what way is what you are trying to do then any different than this example with the FIFO? There is nothing inherently special about a third party IP core, when you instantiate multiples of your own hand written entity it works the exact same way.

In the example with the FIFO i have to add into my design a wrapper vhd file which points to a vendor library (e.g. altera_mf if the FIFO was generated in Quatus MegaWizard) which is mapped to my project. In altera_mf there is a folder with the compiled files of that component (e.g. dcfifo). Now, i don't know if the designer of this dcfifo component designed it as a flat or hierarchical design and if he instantiated an entity called "counter". The nice thing is that i also don't have to worry about it because all i needis the wrapper file and the dcfifo folder with the compiled files.

Now back to my first example, if you would like to send me a vhdl simulation model of a component (a fifo for examole ), that you designed by instantiating 50 different entities into one top file. Would you send me all the 50 folders (each one of them contains compiled files of one entity) that you have in your "work" directory? in this way if you have an entity called "counter" you will send me a folder called "counter" and then we go back to the duplicate name conflict... it seems to be more reasonable that you willhave the ability to remove all the hierarchies by flatten compilation intoone and only one folder, exactly like the FIFO example. The thing is that i don't know how to do that and if its possible.

 

[Thomas Stanka]

Am Dienstag, 14. Januar 2014 12:25:59 UTC+1 schrieb ronhk25:

I understand that this solution will solve conflicts during the compilation but won't it be problematic during the elaboration? Does the simulator "knows" to search for the compiled entity in the correct library and bind itcorrectly? Are you sure that it won't just bind the first compiled entity with the searched name?

If you have a configured design, there exist no problems in any stage. The simulator uses exact the entity-architecture(-configuration) you tell him to use in configuration.
That is one of the real strong points in VHDL.

Regarding the flat netlist, do you mean that there is no way to create a technology independent flat netlist/compiled file?

There is no real benefit in simulation time between netlist that is vendor dependent and netlist that is vendor independant.

regards Thomas

 

[Andy]

The entity name-space (actually the signature name-space) in VHDL is the library. If you have multiple counter entities with the same signature (including number and types of ports/generics, and names of them if named association is used in the instantiation), then they must be compiled into (and instantiated from) separate libraries. You specify the library by prefixing the entity name with the library name. The same holds for packages.

"Work" is a predifined alias for the library into which the unit is being, or was, compiled. So if, in one entity/architecture, I instantiate "entity work.mycomp", then mycomp is expected to be compiled into the same library as the instantiating entity/architecture.

Using "work" library prefix helps keep library naming independent of physical libraries until they are actually compiled into the library. Always use "work.whatever" when instantiating an entity (or using a package) from the same library. Use "lib_name.whatever" when instantiating an entity (or using a package) from a different library. This allows you to choose the actualname of the library only when you actually compile things into it. And someone else that needs to use the same body of code can compile it into a differenly named library in their environment, in case they already had a library named the same.

Just to be clear, simulators don't compile HDL into netlists, synthesis tools do that. The synthesis tool may also create an HDL model of the synthesized netlist. Place and route tools may also create an HDL model of the post-place & route netlist, back annotated with actual routing-induced timing delays. Simulators compile HDL into an executable. There is a huge performance difference (wall-clock time) between a simulation of an RTL model and a netlist model (an hdl model that only instantiates primitives, as generatedfrom the synthesis or P&R tool). The RTL model will generally be MUCH faster to simulate (in wall-clock time, not the clock speed of the simulated circuit).

Andy

 

[ronhk25]

בת×ריך ×™×•× ×¨×‘×™×¢×™, 15 בינו×ר 2014

Thank you Andy, this explanation was very helpful!

Ron