Why Would Anyone Perform Non-Standard Language Checks?

The other day, I was having one of my regular chats with Cristian Amitroaie, CEO and co-founder of AMIQ EDA. One of our subjects was a topic that we discussed last year, the wide range of languages and formats that chip design and verification engineers use these days. AMIQ EDA has put a lot of effort into adding support for many of these in their integrated development environment, DVT Eclipse IDE. I know that the list includes SystemVerilog, Universal Verification Methodology (UVM), Verilog, Verilog-AMS, VHDL, e, Property Specification Language (PSL), C/C++/SystemC, Unified Power Format (UPF), Common Power Format (CPF), Portable Stimulus Standard (PSS), and probably a few more.

All these languages and formats are standards of one kind of another, most from IEEE and/or Accellera. As we talked about supporting design and verification language standards, and checking code for compliance, Cristian made the intriguing comment that they also have almost 150 non-standard checks. I was rather puzzled by that term, so I asked him to explain. Cristian said that these are checks for language constructs that deviate from the standards but are supported by specific EDA tools and vendors. Why would vendors do this? It turns out that there are two common reasons:

The vendors have older languages with constructs that their users like, so they add similar constructs on top of the standard to keep their users happy
The vendors have ideas for extensions to the standard that they may propose for the next version but, in the meantime, they want their users to benefit

That led me to wonder why users would use non-standard constructs. Cristian mentioned five possible reasons:

The users want to continue to use language constructs that they like from older languages but that are not in the new standard
The users see high value in the non-standard constructs and are willing to deviate from the standard in order to get the benefits
The vendors may not be entirely clear about what constructs in their examples and training are non-standard, so the users may not realize their deviations
The users have already used non-standard constructs in their legacy code, and are reluctant to perturb and re-verify working code
The users rely on a single EDA vendor for most of their tools, so they don’t worry too much about using non-standard constructs supported only by that vendor

I think that the last point is particularly important. One of the values of EDA standards is that users can code once and then work with any vendor, or any mix of vendors, without having to start from scratch. Relying on non-standard constructs can trap users with one vendor and make it expensive to switch to another. Unless they are making a deliberate choice to use these constructs, users want to know when they are deviating from the standard. In fact, it’s a good idea to warn them anyway.

Cristian said that’s exactly where AMIQ EDA comes in. DVT Eclipse IDE tells users when their code contains non-standard language constructs. These are warnings by default; users who want strict compliance to standards can choose to elevate these warnings to errors. These users will have a much easier time switching EDA vendors or adding new tools into their design and verification flow. On the other hand, users who have made a conscious decision to use certain non-standard constructs can disable or waive the related warnings.

Then I asked Cristian how they figure out when other vendors have non-standard support. Much of this information comes indirectly from their customers. Typically, a user runs DVT Eclipse IDE and sees an error for a language construct that is accepted by their simulator (or, occasionally, another tool). AMIQ EDA investigates and, if the construct is actually legal, updates their own tool. If the construct is non-standard as per the relevant Language Reference Manual, they add a check to issue a warning upon use of the construct.

Cristian noted that they have excellent partnerships with other EDA vendors, and have many tools in house so that they can easily cross-check how languages are handled. He stressed that they never reveal to users which tools support which non-standard constructs, since that would potentially be a violation of their partnership agreements. Users don’t require that information anyway; what they need to know is that they are using non-standard language constructs. Then they can decide whether they wish to continue this usage and accept the loss of vendor portability, or to conform strictly to the standard.

Most of the non-standard checks are for SystemVerilog, not surprising given the complexity of the language. These same checks are available in the AMIQ EDA Verissimo SystemVerilog Testbench Linter, useful for users who run lint in batch mode rather than from the IDE. VHDL is also noted for having vendor-specific extensions, and so DVT Eclipse IDE has checks for these deviations from the standard as well.

I found this whole conversation and topic to be quite interesting. The ability of AMIQ EDA’s tools to detect and report language compliance issues is clearly a benefit to users. It enables them to make fully informed decisions on whether to make use of non-standard language constructs specific to one or more vendors.

To learn more, visit https://www.dvteclipse.com. To see the list of AMIQ EDA’s non-standard checks, see https://dvteclipse.com/documentation/sv/Non_Standard_Checks.html.

Also Read

Does IDE Stand for Integrated Design Environment?

Don’t You Forget About “e”

The Polyglot World of Hardware Design and Verification

Share this post via: