DesignPSL Frequently Asked Questions:

What is DesignPSL?

DesignPSL is a new RTL-level (NOT BEHAVIORAL) design language intended to replace Verilog/VHDL (while inter-operating with them). It is structured to minimize the learning curve and maximize the capture of the original design's intent without burdening the designer with writing both the design and assertions.

Does DesignPSL take long to learn?

No, DesignPSL is designed such that a designer experienced with Verilog or VHDL will be able to understand the basic concepts in an hour. The language is natural for designers and the higher level controls (such as module instantiation) greatly resemble Verilog.

Is DesignPSL an RTL?

Absolutely! It provides the same level of control as Verilog or VHDL.

Why do I need a new RTL?

A new RTL is needed that does not have the ambiguities of Verilog and VHDL. Verilog and VHDL are modelling languages while DesignPSL is a design language. Verilog and VHDL (and SystemC) were developed as modelling languages that were later retasked into design languages. Neither were developed with the express purpose of being a design language. DesignPSL was developed as a design language.

Design entry is not my problem, verification is my problem. Why change design languages?

The primary benefit of the use of DesignPSL is a drastic reduction in the time it takes to find and fix bugs - verification. This occurs with no added work on the designer's part. So while DesignPSL is a design tool for use by designers it actually solves the verification problem.

How does DesignPSL save so much time and manpower?

DesignPSL improves on virtually every aspect of design and verification:
- Assertion and coverage model creation and maintenance is automatic.
- Bugs are caught at the point of failure rather than by debugging a symptom
- Latent bugs are caught even when symptoms may not have appeared or been detected
- Hand generated assertions tell you when they have failed, but you still must relate their failure back to the RTL source
- DesignPSL assertions are coupled directly to the file, line and column number of the RTL source responsible for the failure
- Functional coverage instrumentation provides for closed loop constrained random testing based on dynamic coverage
- Design capture requires fewer lines of code
- Synthesizeable output is clean, efficient and consistent making back-end processing predictable and timing friendly.
- Verification does not have to attempt to instrument coverage, it is done automatically

Do the assertions slow down the simulation?

The assertions do require CPU time to test, however, unlike PSL, SVA, etc. the assertions are far more targetted to the exact hardware design. This means that the DesignPSL compiled assertions are far more effective while taking far less CPU time than is seen with hand developed assertions written in a assertion language. Any slowdown in the simulation will be greatly offset by the reduction in time needed to find and fix bugs in the RTL. Overall the time spent in simulation will be significantly reduced. Since the assertions are all produced automatically there is no manpower consumed in their development as is the case with PSL, SVA, etc.

What is the difference between a check assertion and a coverage assertion?

Check assertions are those that are detecting unexpected behavior. Coverage assertions are those that are detecting expected behavior. In the ideal case no check assertions should fire and all the coverage assertions should fire. The DesignPSL assertion generator takes relationships it detects within the RTL and produces check assertions to say that a behavior should never happen and coverage assertions to say that a behavior should happen. The detected relationship is fully described with the combination of check and coverage assertions.

Are all check assertions errors?

No, they may be errors, warnings or advises. An error indicates that behavior has occurred that should halt the simulation since future behavior of the simulation is actually undefined. Warnings indicate that an event has happened that has a high probability of actually being an error but there is a defined simulation result. Advises indicate that an event has occurred that with only a slight amount of variance would have caused an error.

Must I always simulate with Verilog?

At the moment a verilog simulator is required. In the near future Assertive Design will provide a native simulator that does not require the production of verilog code for simulation. This DesignPSL simulator will work with many available PLI/VPI based tools. The more complex tools that expect verilog and other built in functions will be supported at a later date.

May I mix DesignPSL and Verilog files?

Yes. This is a standard method. It may easily be done by passing the verilog modules through the DesignPSL compiler with the DesignPSL files. The resulting Verilog files from the DesignPSL files and the untouched source Verilog files will simulate together with the verilog simulator. The assertion reporting functions and the debugger will then understand the entire design hierarchy.