Dave solicited feedback, and directed readers to this forum. Here’s my feedback.
Here’s my number one request for the working group. The standardization of a Synthesizable subset of the SystemVerilog language. This work was done for Verilog-2001. (IEEE 1364.1-2002). It should be done again for SystemVerilog.
For reasons unknown to me, the proposal to do this activity was resoundingly squashed in the SystemVerilog standardization process early on (By my recollection in the early 2003 timeframe). In my opinion, this has greatly restricted the uptake of SystemVerilog in the Synthesis domain.
While much work for SystemVerilog emphasized the verification elements, the synthesizable sections of the language offered very significant improvements. More so, than the evolution from Verilog-1995 → Verilog-2001. So the need for a common standard for EDA vendors to aim for, along with users to code to would greatly help. As it is, users are left to fumble about finding the least common denominator between all tools they use. This is inefficient, and error prone.
I’ve a feeling this isn’t the Standardization work most folks would have in mind. Some would argue it’s too little/too late. But I think this would greatly help the language.
Thanks for the feedback. Having a standard synthesis subset would be a great benefit to the user base at large. However there’s just one problem: not enough users demand full compliance to any EDA language standard. IEEE 1364.1-2002 was never adopted by any vendor, and the standard was withdrawn.
A standard for compliance has little value if there’s not a majority out there demanding compliance (And I mean majority by revenue ROI) So you wind up with 2 standards without uniform compliance.
However there’s just one problem: not enough users demand full compliance to any EDA language standard. IEEE 1364.1-2002 was never adopted by any vendor, and the standard was withdrawn.
Hm, that’s news to me. Quite disappointing actually, as the work was done, and it was voted on and accepted as an IEEE standard. I have a copy of the standard. My name’s on the working group. What’s the point in withdrawing the standard after it’s already been accepted? Anyway, I won’t pretend to understand how standards bodies work.
.
There’s quite a bit more gray areas regarding synthesizable subset with SystemVerilog than within Verilog-2001. I could start a list myself. The language evolved quite a bit.
As I mentioned, I know this standardization task was brought up by one of the EDA trainers/instructors during the language development in the Accellera SV-EC/SV-BC working groups. I also know this caused quite a ruckus, even though there was substantial support (at least among the non-EDA tool vendor) members. As I read things, it looks like the task was harshly buried.
In the justification of not doing this work, you mention winding “up with 2 standards without uniform compliance”. As it is now we have N standards - each vendor defining their own (unpublished) subset. For every user to blindly fumble about to try and find.
What’s the point of standards bodies, if they don’t want to do the necessary work that helps all the end-users and industry as a whole?
This status page shows the standard was withdrawn in 2010. The IEEE requires standards to be re-affirmed or revised on a periodic bases. The current timeline, which came into effect after this standard was withdrawn, is every 10 years.
Standards development is always a delicate balance between competing suppliers, competing consumers, and the committee participants. EDA standards certainly have value to IP developers trying to market their products to outside parties. But for the majority of users out there, the language is not the main part of their job, and they don’t have the clout, the confidence or the time to push vendors into compliance. It may not be an issue for them until they have to switch vendors because of business reasons, or they need to work with another customer that works with another vendor.
Hopefully discussions like the one we are having raise awareness to these issues and drive the right kind of participation in the standards group.