cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Mentor
Mentor
4,465 Views
Registered: ‎02-24-2014

Request for VHDL2008 simulation improvement: Unconstrained Array Type as Subtype in Array Type Definition

I just installed the BITVis UVVM testbench packages for simulating an axilite master core in my Ultrascale design, and found that Vivado 2018.2 still lacks essential VHDL2008 language support.

 

ERROR: [XSIM 43-4187] File "D:/test_ip/test_axi_lite_master_1.0/src/types_pkg.vhd" Line 39 : The "Vhdl 2008 Unconstrained Array Type as Subtype in Array Type Definition" is not supported yet for simulation.

 

This problem, along with the lack of support for VHDL2008 Contexts,  is very annoying.    Please upgrade the priority of this language feature for Vivado.

 

REQUEST FOR OTHER VHDL USERS:     Please append your vote of support to this thread if you need this language upgrade in Vivado.

Don't forget to close a thread when possible by accepting a post as a solution.
29 Replies
Highlighted
Scholar
Scholar
4,430 Views
Registered: ‎08-01-2012

I support this.

Although if all it is doing is pushing users to 3rd party sim tools, I dont really see a business case for Xilinx.

Highlighted
4,400 Views
Registered: ‎01-22-2015

I support this  - and the need to make Vivado simulation better support all versions of VHDL.

 

For example, Vivado 2018.2 seems unable to do post implementation timing simulation (see <this> post) - even with older versions of VHDL.

 

Highlighted
Moderator
Moderator
4,365 Views
Registered: ‎04-24-2013

Hi markg@prosensing.com,

 

As per UG900 Post Synthesis and Post Implementation timing simulations are not supported for VHDL

 

Capture.JPG

 

Best Regards
Aidan

 

 

------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if this answered your question
Give Kudos to a post which you think is helpful and may help other users
------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
4,359 Views
Registered: ‎01-22-2015

@amaccre

 

     ....timing simulations are not supported for VHDL

That's actually part of our overall complaint.   Why doesn't VHDL get equal footing with Verilog?

 

However, I did not write my original complaint clearly - sorry.

 

Yes, I do use VHDL.  However, as @graces explained to me "You can have a pure VHDL RTL design but write out a Verilog simulation netlist (write_verilog) from synthesized or implemented design. That netlist still allows you to perform timing simulation."  As shown in the post that I referenced, using write_verilog this way did not result in correct results for post-implementation timing simulation. 

 

It is still unclear to me whether this is a problem with post implementation timing simulation in general or whether it is a using-VHDL problem.

 

Thanks,

Mark

Tags (1)
Highlighted
Moderator
Moderator
4,345 Views
Registered: ‎04-24-2013

 

Hi markg@prosensing.com,

 

If you have a sample project that shows incorrect results / results different to another third party simulator and are willing to share it then let me know and I can send you an EzMove link to transfer the files securely.

 

If I can replicate the issue then I will be happy to file a Change Request to have the issue investigated and fixed.

 

Support for VHDL Timing simulations in Vivado Simulator are not likely to be included in the near future.

 

It is my understanding that full coverage for SystemVerilog and VHDL-2008 in synthesis currently has higher priority.

 

Best Regards
Aidan

 

------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if this answered your question
Give Kudos to a post which you think is helpful and may help other users
------------------------------------------------------------------------------------------------------------------
Highlighted
4,340 Views
Registered: ‎01-22-2015

@amaccre

 

The following post has a lengthy discussion with @graces about my problem with post-impl timing simulation.  Message 16 in that post summarizes the problem and contains my archived project from Vivado v2018.2.

 

https://forums.xilinx.com/t5/Simulation-and-Verification/Simulation-behavioral-structural-functional-timing/td-p/878113/highlight/true/page/2

 

Thank you for help with my problem and for letting us know that we can expect improved support for VHDL-2008.

 

Mark

0 Kudos
Highlighted
Moderator
Moderator
4,326 Views
Registered: ‎04-24-2013

Hi markg@prosensing.com

 

I retrieved the project that you uploaded, implemented it and ran post implementation timing simulations in both Vivado Xsim 2018.2 and ModelSim 10.6c and the results were identical.

 

ModelSim

 

ModelSim.JPG

 

Vivado

 

Xsim.JPG

 

Let me know if I should have tried something different?


Best Regards
Aidan

 

------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if this answered your question
Give Kudos to a post which you think is helpful and may help other users
------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
4,317 Views
Registered: ‎01-22-2015

Hi Aidan,

 

Thank you for continued help!

 

I did not compare results from ModelSim and Vivado for Post-Implementation Timing Simulation (PITS). However, results from Vivado PITS and Vivado Post-Implementation Function Simulation (PIFS) were found to be identical  - which is an indicator of the problem.

 

Specifically, please consider the circuit shown below whose behavior I am simulating.  In short, after the asynchronous clear, CLR1, for register, REG1, goes low then the output of REG1 (and output, OUT1) should go high “shortly after” the next rising edge of CLK1.

pulse_stretch.jpg

 

However, PITS and PIFS both show that OUT1 goes high on (and not “shortly after”) the rising edge of CLK1. For Kintex-7, I estimate “shortly after” to be the sum of delays through IBUF (~1ns), BUFR (~1ns), FDCE (~0.5ns), and OBUF(~2ns) – or about 4.5ns in total.

 

Since PITS shows that OUT1 goes high simultaneously with the rising edge of CLK1 (and not ~4.5ns after rising edge of CLK1) then I believe that PITS is not working properly (or I am not using PITS properly).

 

Thanks,

Mark

0 Kudos
Highlighted
Explorer
Explorer
4,266 Views
Registered: ‎05-22-2008

I ran across this thread after encountering an almost identical issue, wherein Vhdl2008 unconstrained record types are unsupported in simulation. This was a pretty simple piece of code, where I'm creating an AXI-Stream type and I don't want a bunch of types; one for 32 bits of tdata, 16 bits of tuser; another for 24 bits of tdata, 16 bits of tuser; and on an on ad infinity.

 

If the naming is accurate, VHDL-2008 is 10 years old now. Xilinx at least let us know what we can expect when. Will VHDL-2008 be supported in vivado simulator by 2020? 2025?

0 Kudos
Highlighted
3,982 Views
Registered: ‎10-03-2018

I fully support the request. This feature is absolutely fundamental in order to develop clean, portable code. Because of ths very issue alone my whole company has to use ModelSim for behavioural simulation, with considerable additional cost.

 

Vivado simulator is great and, for the rest, we are very happy with it, but please add this feature as soon as possible, it is making our life really hard.

0 Kudos
Highlighted
Scholar
Scholar
3,969 Views
Registered: ‎08-01-2012

Btw - to highlight how far behind Xilinx are:

VHDL 2018 is about to be, or has just been released - and Aldec are demoing some feature support in their beta releases. (Although they dont have all parts of 2008 supported yet)

 

Im sure Modelsim wont be too far behind.

Cadence will probably lag, but support will probably come.

Highlighted
Observer
Observer
3,304 Views
Registered: ‎09-20-2018

Adding in a vote for essentially any VHDL-2008 support in simulation. Even the most fundamental "quality of life" features aren't implemented for simulation.

For a

Reset_i : in std_logic;

That then gets used in VHDL-2008 style as

if rising_edge(Clk_i) then
      if Reset_i then

Returns the error in simulation elaboration

ERROR: [XSIM 43-4187] File "<file>.vhd" Line 52 : The "Vhdl 2008 Condition Operator" is not supported yet for simulation.

We had a plan for this project to "keep things simple" and try to use Vivado as a fully integrated design environment, however now we have to choose between the benefits of "new" language fetaures and workflow simplicity. From the years of scattered posts on this matter in the forums, this remains a peristent unsolved problem.

 

Edit: from the advice of my local FAE, there is limited VHDL-2008 support in the simulator per UG900, Appendix C. However, there are obviously some important exclusions (see my above post) and numeric packages require modifying the library declarations in the source files.

Highlighted
Mentor
Mentor
2,928 Views
Registered: ‎06-10-2008

I also would very much like to use unconstrained array types as subtypes in a simulation with Vivado 2019.x.

Xilinx, please add this.

0 Kudos
Highlighted
Scholar
Scholar
2,723 Views
Registered: ‎04-04-2014

I will add my vote to this. Absolutely riduculous that 10 years after VHDL2008 was intriduced the pack in dsimulator for Vivado still doesn't support it. Our company cannot afford ModelSim (2 FPGA developers, 30 employees) and having to make workarounds resulting in highly non-portable code is very annoying.

I understand synthesis is more important but surely the simulator cannot have ZERO importance, which appears to be the case at the moment based on how many improvements actually happen to it. Come on Xilinx, pull your finger out.

0 Kudos
Highlighted
Scholar
Scholar
2,716 Views
Registered: ‎08-07-2014

@all,

This is what Xilinx told mw when I had requested complete VHDL2008 support a few months ago...

https://forums.xilinx.com/t5/Simulation-and-Verification/Complete-VHDL2008-support-in-Vivado/m-p/970718

 

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

Highlighted
Scholar
Scholar
2,701 Views
Registered: ‎04-04-2014

Wonderful!

0 Kudos
Highlighted
Advisor
Advisor
2,223 Views
Registered: ‎10-10-2014

I'm trying to create something very simple : a (VHDL) lookup-table (array of strings) that returns a string based on an index  ... I always run into the error mentioned in the title of this forum post ... : 

The "Vhdl 2008 Unconstrained Array Type as Subtype in Array Type Definition" is not supported yet for simulation

 I posted the question here in this post ... is this really not possible? So tell me I'm writing bad VHDL code, I must be doing something wrong ...?

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Scholar
Scholar
2,207 Views
Registered: ‎04-04-2014


@ronnywebers wrote:

I'm trying to create something very simple : a (VHDL) lookup-table (array of strings) that returns a string based on an index  ... I always run into the error mentioned in the title of this forum post ... : 

The "Vhdl 2008 Unconstrained Array Type as Subtype in Array Type Definition" is not supported yet for simulation

 I posted the question here in this post ... is this really not possible? So tell me I'm writing bad VHDL code, I must be doing something wrong ...?


I would think the problem is that your string elements, within the table isn't constrained.

If you define  a string with no range it's an unconstrained array of characters.

So you can't have this, as it's effectively an array of an unconstrained array type.

type StrArray is array (integer range <>) of string;

But you can have this.

type StrArray is array (integer range <>) of string(1 to 99);

 

Highlighted
Scholar
Scholar
2,200 Views
Registered: ‎08-01-2012

@mistercoffee 

type StrArray is array (integer range <>) of string;

Is perfectly legal in VHDL 2008 as a type. But when you create an object, both dimensions must be constrained.

signal str_array_sig : StrArray(88 downto 44)(50 to 99);
Highlighted
Scholar
Scholar
2,195 Views
Registered: ‎04-04-2014

Yes that's true, but wasn't the poster suggesting it didn't work because it's not yet supported by Vivado in simulation? We were tlaking about subtypes, not signal declarations I thought.

Highlighted
Advisor
Advisor
2,135 Views
Registered: ‎10-10-2014

@mistercoffee @jmcclusk I continued the unconstrained string issue in the other thread, thanks both for the help and suggestions.

Back to the lack of support of VHDL / VHDL-2008 ... Though I've programmed only in VHDL so far, because I never liked Verilog with it's bad compile time checks, I'm thinking more and more to stop fighting, and move to Systemverilog, first only for testbenches, but probably later also for synthesis.

One of the big reasons would be (for me at least) the new AXI VIP and Zynq UltraScale+ MPSoC Verification IP. Both can only be controlled from Systemverilog, and I'm afraid VHDL support will never happen. We tried some workarounds using VHDL (see this post), but this was getting over-complicated ... Also Xilinx themselves seems to be writing more and more IP and XPM macros in Systemverilog.

However I'm afraid of dropping VHDL for synthesis, because the better compile time checking. On the other hand, mixing 2 languages is not the most optimal way of going.

But then rises the question : how well is Systemverilog supported in synthesis and simulation ... all this Vitis thing, C/C++, HLS, SystemC is all nice, but in the end, you still need the low-level HDL stuff to do the really hard parts, like (inline) assembly will never disappear in certain areas.

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Highlighted
Scholar
Scholar
2,120 Views
Registered: ‎08-07-2014

@ronnywebers,

We tried some workarounds using VHDL (see this post), but this was getting over-complicated

My suggestion there was a stop-gap arrangement, not a long term soln. So the problems you saw are very practical.

It is very unfortunate that Xilinx cares less about complete VHDL2008 support.

With you moving to SV we will  have 1 less VHDL campaigner in this forum. :-(

But then rises the question : how well is Systemverilog supported in synthesis and simulation ... all this Vitis thing, C/C++, HLS, SystemC is all nice, but in the end, you still need the low-level HDL stuff to do the really hard parts, like (inline) assembly will never disappear in certain areas.

Here is a post from a French company I found interesting: https://www.alse-fr.com/Do-I-need-SystemVerilog.html

 

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

Highlighted
Scholar
Scholar
2,110 Views
Registered: ‎08-01-2012

@ronnywebers @dpaul24 

I do agree with everything in that post. But I have always been concerned that when people talk about verification, SV is the only option people take seriously - SystemVerilog is NOT a verification solution in itself. Neither is UVM. Neither is VHDL. Verification is a set of skills and techniques that can apply to ALL languages, and like anything else, things like UVM and features of SV are designed to make these things easier and reusable - but badly written/designed SV+UVM is still badly written/designed.

So it is a shame that Xilinx are chosing to focus on SV - but it is understandable as that is what everyone is asking for. But it becomes a self fulfilling prophecy - people think SV/UVM is verification, and hence move to SV/UVM. And more people follow - not realising that it is very easy to make everything very very complicated very very quickly.

I have worked with both VHDL and SV/UVM over the years. I love a lot of the stuff you can do with SV - but usually an FPGA designer who can write good RTL can really be put off by a SV testbench. It can be difficult to follow what you need to modify to change the behaviour on an interface on a clock/clock basis, for example.This often means dedicated people/teams are needed to write and manage the testbenches, and while this means some very powerful testing, if cuts happen, then because these people arnt seen as "direct contributers" to a product, they can often be the first to be hit. Now you have a load of designers who are scared off by the SV and wont use it - bit rot happens and verification suffers.

I am a VHDL fan, and I know there is little that cannot be done in VHDL if you understand it. I have a set of re-usable code that can create constrained random packets and push them over an interface that is also a constrianed random BFM. It is broken down to be as re-useable and modular as possible to allow easy design of new interface BFMs. I try and make it plug and play as possible, meaning the end users need little to no knowledge of the inner workings, they just need to provide a config that defines the behaviour.  But the downside is I need VHDL 2008 to do this (and VHDL 2019 will help in some aspects).

Tags (2)
Highlighted
Advisor
Advisor
2,098 Views
Registered: ‎10-10-2014

@dpaul24 thanks for the interesting post of the french company! 

@richardhead I agree that with good VHDL-2008 support, life would be a lot easier for VHDL testbenches. Indeed large frameworks are in many cases not needed, and fine grained control up to the clock-cycle and nanosecond are definitely something we'll always need. 

On the other hand the VIPs are interesting for higher-level testing of complete AXI based IP's.... not easy decisions to make. I'm currently building up my own re-usable functions and libraries to easy simulation and create more advanced testbenches, but because I don't have the long historical code base as you do, I must consider the switch to SystemVerilog now, as it already has a lot of these libraries that I need to write, built right in. 

Something as basic as the 'to_string' function throws the error in the Vivado sim that this VHDL 2008 thing not yet supported, and it's 2020 ... soon we'll be watching Bladerunner 3, and still not have VHDL-2008 support :-)

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Guide
Guide
1,928 Views
Registered: ‎01-23-2009

I just want to comment on the post by @richardhead about UVM not being the only solution to verification.

First, I agree completely - UVM is a tool. When used correctly, you can create very powerful and extensible simulation environments. However, it is true that the resulting code looks quite different from Verilog/SystemVerilog used by RTL designers. As a result, the skill set required to write UVM testbenches is diverging from the skillset required to write implementable RTL code. I would go one step further and suggest that it is unreasonable to expect an RTL designer to inherit/modify/understand a complex UVM testbench.

I also agree that there are other ways of writing competent testbenches without using UVM - people have done it for decades! These testbenches can be every bit as complicated as a UVM-style testbench or significantly simpler.

I just want to point out that these non-UVM testbenches can be written in any HDL; VHDL, Verilog, or SystemVerilog. At it's heart SystemVerilog is an extension of Verilog. Some of the extensions improve how we write RTL code (there are lots of really nice synthesis friendly features in SystemVerilog that weren't available in Verilog) and others are there to significantly enhance the "toolbox" that can be used for Verification - many of which are required for UVM testbenches. If you are writing your own testbench, you can choose to use as many or as few of these enhancements as you want - this can result in what @richardhead was suggesting - a testbench that is more readable/supportable by someone who does not have the "specialized" UVM knowledge.

Avrum

Tags (2)
Highlighted
Advisor
Advisor
1,887 Views
Registered: ‎10-10-2014

@avrumw thanks for sharing your insights ... I do feel more to write non-UVM testbenches for the reason you mention : that it's diverging from the skillset requried to write implementable RTL code. I skipped it so far, because it seems rather complex, and I prefer to have a better feeling with my code ... 

I'm just hesitating to switch from VHDL to SystemVerilog (maybe for the wrong reason) because Verilog has less 'compile time checks' compared to VHDL, so I asume this is still true for SystemVerilog as it's a superset of Verilog? 

Second reason to hesitate is that I don't know how wel SystemVerilog is (already) supported by Vivado today ... but probably the answer is 'better than VHDL-2008' ... (?)

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos
Highlighted
Guide
Guide
1,873 Views
Registered: ‎01-23-2009

because Verilog has less 'compile time checks' compared to VHDL, so I asume this is still true for SystemVerilog as it's a superset of Verilog?

I will try and be neutral here (and not spark a Verilog vs. VHDL war...)

Verilog and VHDL take a different approach. Verilog is "loosely typed" (like, for example C), whereas VHDL is "strongly typed" (like, for example Pascal). These make the experience different - there are advantages and disadvantages to both.

First, niether is inherently more capable than the other (loosely vs. strongly) - I want to separate this from VHDL vs. Verilog - there have definitely been times where VHDL had some capabilities that Verilog did not, but that's not because of the typing rules, just the language.

So given that the two can be identical in terms of capability, what distinguishes the two. It has to do (primarily) with errors and debugging.

When a designer makes a mistake it can show up in one of two gross places - a syntax error or a functional error. The main difference in a strongly vs. weakly typed language is that it forces more mistakes into the syntax error category. This makes them easier to find, since the parser tells you exactly what's wrong. A functional error requires more analysis, and hence often requires more time to find. So this is a point in favor of strongly typed languages.

Conversely, strongly typed languages can be (significantly) more verbose. In hardware "a bit is a bit" - hardware doesn't really care of it is part of an integer, a string, an enumeration of discrete items, etc... This is more the approach of a loosely typed language - a vector of bits can be interpreted as pretty much anything in a natural manner - the exact opposite of strongly typed. As a result, you don't need any explicit conversions from type to type to do a particular type of operation, which ends up with less typing.

SystemVerilog is like Verilog mostly. The heart of the language remains loosely typed, but some of the enhancements are more strongly typed. This is unavoidable in some parts of the language - like structures and unions, where typing is more required and hence is somewhat more strongly enforced in SystemVerilog, and even more (oddly) strongly enforced in things like enumerated types. But at its heart, SystemVerilog is still pretty weakly typed.

There are ways to bridge the gap between the two - lint programs. A Verilog/SystemVerilog lint program (a linter) can impose a much more rigid set of coding rules on the language. Among other things, linters can be very strongly typed; there is adequate SystemVerilog syntax to allow for writing more strongly typed code (i.e. there is a rich set of casting syntax). So using SystemVerilog with a linter can result in the same strong typing as VHDL (including the additional verbosity for the typecasting). However, there is no linter in Vivado, and 3rd party lint tools are relatively expensive...

Second reason to hesitate is that I don't know how wel SystemVerilog is (already) supported by Vivado today ... but probably the answer is 'better than VHDL-2008' ... (?)

As for Vivado support of SystemVerilog - it is very good (at least for synthesis). I have been using full-on "SystemVerilog for Design" and have successfully synthesized all the SystemVerilog constructs I have chosen to use. That being said, for SystemVerilog projects, I don't use the Vivado simulator, so I don't know how well the Vivado simulator supports SystemVerilog; the documentation says that suppors at least a subset of the SystemVerilog language, but clearly not all of it - my understanding is that it does not support enough to use (for example) UVM.

Avrum

Highlighted
Scholar
Scholar
1,853 Views
Registered: ‎08-01-2012

@avrumwxilinx claim uvm support in 2019.2 (or 1?). So for that would need pretty good sv support. From the look of some posts it appears no one told the gui guys this (you get red lines on your code) but that should be fixed in 2020.1.

Also don't forget you can do verification with non rtl languages. Apart from having an external model provide reference data for a sim, there is the dpi interface to plug c calls from rtl, then there are things like myhdl that generate rtl from python or even matlab code generation.

Highlighted
Advisor
Advisor
1,770 Views
Registered: ‎10-10-2014

thanks @avrumw , that's giving me more confidence in SystemVerilog, if synthesis support is good. It looks like new code by Xilinx (i.e. XPM macros) use SystemVerilog too ... looks like a powerful language...

As more advanced sim I probably should consider Modelsim in the future (?) ... or hope that Xilinx puts more effort in a 'total' experience and get their sim up at the level of Modelsim.

by the way, in the 2019.2 release, they added 'some' Sigasi based linting, see my post here for an answer by Xilinx ... but you must activate it, it's not on by default - however it remains unclear what 'some' means

@richardhead I'm gonna take a look at myhdl, it's on my 'todo-list' since long :-)

** kudo if the answer was helpful. Accept as solution if your question is answered **
0 Kudos