UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer stefan_v
Observer
696 Views
Registered: ‎08-28-2018

Simulating XPM makros using GHDL

Jump to solution

Hi,

I am planning to automatically verify my projects and components using Vunit. In order to simulate my test cases in parallel I would like to use the GHDL simulator. This methodology works fine as long as I am not using any XPM RAMs and FIFOs in my designs.

So, my question is: Is there a way to simulate XPMs in GHDL?

 

Best regards

Stefan

0 Kudos
1 Solution

Accepted Solutions
Scholar brimdavis
Scholar
626 Views
Registered: ‎04-26-2012

Re: Simulating XPM makros using GHDL

Jump to solution

@stefan_v    "As for your suggested workarounds I have problems with both"

Another possibility is to write your own structural wrappers, using the memory primitives, that are family aware.

While this is vendor specific, it is less likely to break than RAM inference in new versions of the synthesizer. (That said, I've had fairly good results in Vivado with memory inference[1], especially if you put the RAM and all address/data registers in their own level of hierarchy with a KEEP_HIERARCHY attribute, which prevents the registers from migrating elsewhere during optimizations.)

As Richard suggested, one can make the top level look the same for the inferred/structural designs, and just switch the library or architecture to the desired component.

Also worth noting, it actually looks fairly straightforward to modify the UNIMACRO RAM/FIFO generators to handle Ultrascale as well, the VHDL sources are located in Vivado/2018.3/data/vhdl/src/unimacro

> I think most of his problems were related to initializing the RAM from a file

The last time I tried, Vivado synthesis file I/O still seemed much less capable than XST; I've seen similar problems with file parsers for memory initialization, that worked in XST but failed in Vivado.

-Brian

[1] One sneaky memory inference bug in Vivado to be aware of is that RAM inference doesn't work unless the address index range includes zero, see:

  AR# 64033 2015.1 Vivado Synthesis: ERROR: [Synth 8-5548] Non zero range declaration for RAM (mem_reg) not supported. Use 0 for MSB or LSB for RAM declaration

This can easily crop up when doing width/depth expansion in a generate loop, so when slicing the address input you need to create an intermediate address signal, with an end range of zero, to use for the inference array indexing.

In recent versions of Vivado I've seen this problem without any synthesis error message, but Vivado creates the memory using a gazillion flip-flops instead of BRAMs.

6 Replies
Scholar richardhead
Scholar
676 Views
Registered: ‎08-01-2012

Re: Simulating XPM makros using GHDL

Jump to solution

No

The XPM library is written purely in SystemVerilog, and GHDL is VHDL only.

0 Kudos
Scholar brimdavis
Scholar
662 Views
Registered: ‎04-26-2012

Re: Simulating XPM makros using GHDL

Jump to solution

@stefan_v  "This methodology works fine as long as I am not using any XPM RAMs and FIFOs in my designs."

I asked Xilinx about the lack of VHDL simulation models for the XPM library a while back, without making much headway:

  https://forums.xilinx.com/t5/Simulation-and-Verification/no-VHDL-simulation-models-for-XPM-s/m-p/813397

On the above thread, Xilinx said they filed an enhancement request CR against the XPM library, but I've seen no evidence (as of 2018.3) that they have done anything about the problem.

Possible Alternatives to XPMs:

  • if you're not targeting Ultrascale, the UNIMACRO library provides memory/FIFO functionality for the earlier device families
  • write your own inferred-memory models for FIFOs and RAMs

-Brian

0 Kudos
Observer stefan_v
Observer
645 Views
Registered: ‎08-28-2018

Re: Simulating XPM makros using GHDL

Jump to solution

@brimdavis Thanks for the info. I did not find your thread when searching for my problem.

As for your suggested workarounds I have problems with both:

1) While still maintaining older project my next project is targeting US+, so I will probably have an issue there.

2) A colleague of mine is using his own VHDL models for RAMs. Every time he upgraded his Vivado version Xilinx changed something and he spent quite some time changing his code and hacking into Vivado in order to have everything working as before. I think most of his problems were related to initializing the RAM from a file. At that times I was always happy to just use the native Xilinx solution. But times seem to change. I will ask him and maybe inferred memory models can be a solution for me, too.

0 Kudos
Scholar richardhead
Scholar
639 Views
Registered: ‎08-01-2012

Re: Simulating XPM makros using GHDL

Jump to solution

If possible, then inferred would always be the prefered solution as it is also supported by other vendors. But be careful as there can be some subtle differences. At a previous job we had separate libraries for Altera, ISE and Vivado, but there was a common top level interface (ports and entity names were all the same). You would instantiate it the same but just include the relavent vendor library in your project.

0 Kudos
Scholar brimdavis
Scholar
627 Views
Registered: ‎04-26-2012

Re: Simulating XPM makros using GHDL

Jump to solution

@stefan_v    "As for your suggested workarounds I have problems with both"

Another possibility is to write your own structural wrappers, using the memory primitives, that are family aware.

While this is vendor specific, it is less likely to break than RAM inference in new versions of the synthesizer. (That said, I've had fairly good results in Vivado with memory inference[1], especially if you put the RAM and all address/data registers in their own level of hierarchy with a KEEP_HIERARCHY attribute, which prevents the registers from migrating elsewhere during optimizations.)

As Richard suggested, one can make the top level look the same for the inferred/structural designs, and just switch the library or architecture to the desired component.

Also worth noting, it actually looks fairly straightforward to modify the UNIMACRO RAM/FIFO generators to handle Ultrascale as well, the VHDL sources are located in Vivado/2018.3/data/vhdl/src/unimacro

> I think most of his problems were related to initializing the RAM from a file

The last time I tried, Vivado synthesis file I/O still seemed much less capable than XST; I've seen similar problems with file parsers for memory initialization, that worked in XST but failed in Vivado.

-Brian

[1] One sneaky memory inference bug in Vivado to be aware of is that RAM inference doesn't work unless the address index range includes zero, see:

  AR# 64033 2015.1 Vivado Synthesis: ERROR: [Synth 8-5548] Non zero range declaration for RAM (mem_reg) not supported. Use 0 for MSB or LSB for RAM declaration

This can easily crop up when doing width/depth expansion in a generate loop, so when slicing the address input you need to create an intermediate address signal, with an end range of zero, to use for the inference array indexing.

In recent versions of Vivado I've seen this problem without any synthesis error message, but Vivado creates the memory using a gazillion flip-flops instead of BRAMs.

Observer stefan_v
Observer
574 Views
Registered: ‎08-28-2018

Re: Simulating XPM makros using GHDL

Jump to solution
Thank you guys for your answers! I am a little afraid to modify the unimacro library for Ultrascale, because I fear to I checked the our RAM inference modules, but it seem we only have files available for memory, but not for FIFOs. I also checked the Xilinx VHDL coding guide (contained in the Vivado synthesis guide), but there too only memory inference is described. It seems I will have to write some code around our memory modules in order to get a working FIFO implementation, but there is plenty of templates available on the net. Once I am at it I can also integrate some technology awareness. @brimdavis Also thanks for the hint about the Vivado 2018 bug. I am not using Vivado 2018.x, because of a FSM synthesis bug. I already filed a webcase because of it and Xilinx is working to fix it. Thanks again for helping me decide how to proceed. Still, it is very sad that Xilinx does not offer any solution for this.
0 Kudos