You copied the Doc URL to your clipboard.

Design Sign-off Model (DSM) does not function correctly in simulation.

Article ID: 103489816

Published date: 31 Jan 2018

Last updated: -

Applies to: Cortex-A, Cortex-R, Cortex-M, Classic, SecurCore

Problem/Question

Design Sign-off Model (DSM) does not function correctly in simulation.

Scenario

The DSM for the ARM processor is used in zero-delay simulation of the chip-level design.

The DSM parameters have been set up correctly to match the desired configuration of the processor RTL used in the chip design.

The DSM exhibits incorrect functional behavior which differs from the behavior seen when simulating the chip level with the RTL model of the processor instantiated. The incorrect behavior of the processor is characterized by input data appearing to be sampled in the wrong clock cycle or output data being driven in the wrong cycle.

Answer

The methodology for DSMs changes from time to time as design tools and flows evolve. This issue applies particularly to older DSM flows, but may also apply to newer DSMs.

Historically, Verilog does not specify any particular ordering of events which occur at the same time instant. Unfortunately for a zero-delay simulation environment, this implies that there is no causal relationship between causes and effects. It is valid, in Verilog, for the effect of an output change with zero delay to be evaluated before the effect of the input which caused the change.

Logic simulators generally get around this issue by implementing so-called delta times at each time instant, so that cause and effect are evaluated in the correct order even if they are evaluated in zero delays.

The DSM is evaluated in a separate simulator instance, connected to your main chip-level RTL simulation through a PLI interface. The DSM is re-evaluated at each time instant where its inputs change, but unfortunately the delta delays within that time instant may be lost at the interface. This results in the possibility of the DSM seeing data changes before the clock edge which caused the data to change. This is the common cause of the symptoms described in this article.

If your simulator is NC-Verilog, please make sure you are applying the "nbasync" switch. This is usually sufficient to resolve the problem, by enforcing a causal event ordering.

If you are not using NC-Verilog, or this switch still does not resolve the issue, please insert a unit delay wrapper around your DSM instance which applies a minimal real delay to all non-clock inputs of the DSM. This will guarantee that clock edges are evaluated before evaluation of any data input changes resulting from that clock edge.

The DSM content is the actual processor RTL itself, presented as an object file, so the functional behaviour (barring zero delay simulation artefacts) is identical between the two model views.

Workaround

N/A

Example

N/A

Related Information

N/A

Was this page helpful? Yes No