cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
610 Views
Registered: ‎09-10-2019

SystemVerilog Libraries: Why aren't they supported by Vivado after 20years? [IEEE 1800-2012 33.3]

Jump to solution

When working across teams or using already established files, it's possible to face several modules with the same name.

Therefore, I would like to use the SystemVerilog libraries defined in IEEE Std 1800-2012 under 33. Configuring the contents of a design and 33.3 Libraries.

Do Vivado 2019.2 and 2020.1 support that SV feature?

It seems it wasn't the case in 2018 (https://forums.xilinx.com/t5/Synthesis/Synth-8-2490-overwriting-previous-definition-of-module/m-p/856161#M26093) and UG

Thanks!

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
406 Views
Registered: ‎09-16-2009

@alexis_jp wrote:

@markcurry  Thanks for admitting it.

>From my experience, they are a rarely-used feature of the language for verilog users, which may explain the poor support among EDA tools.

Taking it that way is a complete misunderstanding of the users and mixing the cause and the consequence.

"Because of the nonexistent support, this is an impossible-to-use feature." is more accurate.

I can definitely sympathize with this sentiment - coding to the least common denominator of all the tools, instead of using the more full features that the language supports.  This is part of the reason why there's a IEEE standard for the Synthesizable subset of Verilog-2001.  It gives something for all vendors to aim for, instead of the hodge-podge least common, poorly defined subset of all the tools that all us users must fumble about and find.  It's been a great disappointment to me that due to political infighting, this was NOT done for SystemVerilog.

What you say, may be true - if the tools better supported it, more users may use it.  So yes, Vivado should support it IMHO.

Drifting off on my tangent again (I'm really not trying to derail your desire to use this feature).  I really, really, really hate this feature in VHDL.  (Libraries and Configurations).  It's so poorly thought out, mixing up language specification for how things are organized by the tool and filesystem.  I've never had more trouble, as a verilog designer, to try and integrate VHDL IP, then when I'm trying to integrate IP where the user's taken advantage of the Library and Configurations parts of VHDL, and really made a mess of things.  Xilinx IP, when they primarily used VHDL was a great example of this.  Manual manipulation of library map files (which must take place outside the language with no standard) - it's always just painful.  

To me, it's so much more direct and simple than to require users to manage the namespace uniqueness themselves.  One Module Name -> One unique definition.  Something conflicts, rename one of them.  The idea of sharing names which mean different things, in different context, where a user must look is some esoteric place to disambiguate - well the benefit is just not worth the cost IMHO.

To me, seeing the same sort of thing in the Verilog standard - I think it's the only part of the verilog language standard that really even mentions filesystem structure (why should it?) - well with my experiences with VHDL similar features, I've avoided it like the plague...

Again, totally my two cents, not trying to derail your request for this feature...

Regards,

Mark

View solution in original post

0 Kudos
8 Replies
Highlighted
Xilinx Employee
Xilinx Employee
488 Views
Registered: ‎02-13-2020

Hi @alexis_jp 

UG900 lists the Syntehsizable Set of SystemVerilog 1800-2012 for Vivado in Table 41 in Appendix B. It looks like 1800-2012 33.3 is not currently supported in Vivado 2020.1

0 Kudos
Highlighted
Explorer
Explorer
456 Views
Registered: ‎09-10-2019

That's what I've read in UG901.

Any reason for that? That's a Verilog 2001 (20years that has been defined) feature.

0 Kudos
Highlighted
Scholar
Scholar
423 Views
Registered: ‎09-16-2009

@alexis_jp 

Your post triggered my curiosity.  I thought libraries and configurations were part of the SystemVerilog spec.  Checking - I was wrong - you're correct, they're actually part of the Verilog-2001 spec - so yes, an almost 20 year old feature.  And even better, those features you're asking about - Libraries and configurations are part of the "Synthesizable Veriog-2001" subset standard.  There's an IEEE standard (IEEE 1364.1-2002) that defines the synthesizable subset of the Verilog-2001 standard that all Synthesis tools should support.  And (surprising to me) your requested features Libraries, and Configurations are part of that Synthesis standard.

It's surprising to me, as I was on the working group for that Synthesizable standard, and I've no recollection discussing those features at all.  But there it is.  It's part of the defined (Verilog-2001) synthesizable subset, yet not supported by Vivado.

I have to admit, however, I find those features of the language, well, poorly thought out.  They really look exactly like their VHDL counterparts - and my two cents is they are added to the Verilog standard aiming at VHDL converts.  From my experience, they are a rarely-used feature of the language for verilog users, which may explain the poor support among EDA tools.

But is is part of the synthesis standard, and I'd definitely argue that the tool should follow the standard.

Regards,

Mark

Highlighted
Explorer
Explorer
417 Views
Registered: ‎09-10-2019

@markcurry  Thanks for admitting it.

>From my experience, they are a rarely-used feature of the language for verilog users, which may explain the poor support among EDA tools.

Taking it that way is a complete misunderstanding of the users and mixing the cause and the consequence.

"Because of the nonexistent support, this is an impossible-to-use feature." is more accurate.

It's widely used in VHDL, it will be widely used with Verilog/SV if available.

 

From my personal experience, several Engineers and I had to give up many SV's possibilities/habits because of the lack of support or bug or restriction inherent to Vivado only. Hardware/FPGA Engineers tend to follow the tool specs rather than the language specs. That's a pity.

Config/library is a useful feature and is the only way to solve multiple modules with the same name and to have complete separation between namespace/function. Package is great but isn't enough and doesn't include modules.

If there is a different way, let me know. All the solutions I've seen so far are: "Rename all the files and modules and instances." The reality is that the solution has actually existed for 20years but yet implemented.

Thank you again for the explanation.

0 Kudos
Highlighted
Scholar
Scholar
407 Views
Registered: ‎09-16-2009

@alexis_jp wrote:

@markcurry  Thanks for admitting it.

>From my experience, they are a rarely-used feature of the language for verilog users, which may explain the poor support among EDA tools.

Taking it that way is a complete misunderstanding of the users and mixing the cause and the consequence.

"Because of the nonexistent support, this is an impossible-to-use feature." is more accurate.

I can definitely sympathize with this sentiment - coding to the least common denominator of all the tools, instead of using the more full features that the language supports.  This is part of the reason why there's a IEEE standard for the Synthesizable subset of Verilog-2001.  It gives something for all vendors to aim for, instead of the hodge-podge least common, poorly defined subset of all the tools that all us users must fumble about and find.  It's been a great disappointment to me that due to political infighting, this was NOT done for SystemVerilog.

What you say, may be true - if the tools better supported it, more users may use it.  So yes, Vivado should support it IMHO.

Drifting off on my tangent again (I'm really not trying to derail your desire to use this feature).  I really, really, really hate this feature in VHDL.  (Libraries and Configurations).  It's so poorly thought out, mixing up language specification for how things are organized by the tool and filesystem.  I've never had more trouble, as a verilog designer, to try and integrate VHDL IP, then when I'm trying to integrate IP where the user's taken advantage of the Library and Configurations parts of VHDL, and really made a mess of things.  Xilinx IP, when they primarily used VHDL was a great example of this.  Manual manipulation of library map files (which must take place outside the language with no standard) - it's always just painful.  

To me, it's so much more direct and simple than to require users to manage the namespace uniqueness themselves.  One Module Name -> One unique definition.  Something conflicts, rename one of them.  The idea of sharing names which mean different things, in different context, where a user must look is some esoteric place to disambiguate - well the benefit is just not worth the cost IMHO.

To me, seeing the same sort of thing in the Verilog standard - I think it's the only part of the verilog language standard that really even mentions filesystem structure (why should it?) - well with my experiences with VHDL similar features, I've avoided it like the plague...

Again, totally my two cents, not trying to derail your request for this feature...

Regards,

Mark

View solution in original post

0 Kudos
Highlighted
Explorer
Explorer
399 Views
Registered: ‎09-10-2019

@markcurryI understand, as for config/library, I didn't dig into it since it isn't supported. I found it when I wanted a workaround to handle in a better way namespaces. I'm sure there are lots of drawbacks.

For us, using several files from different Engineers or sources creates conflicts. Needing to change a module name and the underlying instances in every files every project can be a huge pain, time consuming and error-prone.

In any case, the hardware world has a huge margin for improvement but I believe it's too late, unfortunately HLS will take over the lead giving even more power to the tool.

Thanks

0 Kudos
Highlighted
Scholar
Scholar
393 Views
Registered: ‎09-16-2009

@alexis_jp wrote:

In any case, the hardware world has a huge margin for improvement but I believe it's too late, unfortunately HLS will take over the lead giving even more power to the tool.


(Off on a separate tangent...)

The vendors have been promising us that next generation HLS would be taking over the RTL world for 20 years.  Hasn't happened yet.  Isn't going to for a very long time.  The comparisons to the evolution of schematic capture -> RTL => RTL -> HLS are deeply flawed.  Vendors would love it to be otherwise, and marketing types keeps trying to pound away the point.  HLS remains niche.  It has point uses, of course. But as a replacement for RTL, no way, not even close.

Regards,

Mark

Highlighted
Explorer
Explorer
383 Views
Registered: ‎09-10-2019
Hopefully
Thank you again Mark!
0 Kudos