Re: [sv-ac] SVA: USING ASSERTIONS WITH VERILOG RTL

Hello All;

>The only suggestion on including SVA with legacy Verilog code that makes
>sense to me is to use binding.

I would agree with this statement, provided that people aren't maintaining
(making changes) to the legacy verilog code. One of the values is to inform
the reader of the assumptions, and expectations the code makes. Hiding the
assertions through a binding construct does not help the reader.

The question Ben raised is relevant, because we all work in an environment with
EDA tools that are not all updated at the same time to read and use or ignore
the exact same set of constructs.

Thus, we will have a set of tools that will accept certain constructs and a set
of tools that won't. So what should you do to allow all tools to read the code?

I would not recommend the binding construct for code in development, for the
reason that you are hiding relevant information for the reader and the developer.

One real reason that pragmas are ugly is because you typically will have more
than one set - each one for a different tool.

I am leaning toward ifdef's.
My book, "Assertion-Based Design" continues the recommendation from "Principles of
Verifiable RTL" of using "`ifdef ASSERT_ON" to allow one to make them visible or
hidden based on the tool being used at the time.

EDA VENDORS, please do not take this as a justification for not having to support these
new and valuable constructs because users will have a method to hide them. Indeed, these
workarounds are necessary to get the job done in a changing world.

The larger the SV feature set your tool supports, the easier it will be for users to
adopt these new constructs and use your tools.

So you see Ben, there is no one best choice - it depends on your perspective...

     Adam Krolnik
     Verification Mgr.
     LSI Logic Corp.
     Plano TX. 75074
     Co-author "Assertion-Based Design"
Received on Fri Aug 20 07:44:11 2004