Metastability and simulation

[navi_s]

noiopath

Hello,

I have one question. How you simulate at example two asynchronous process, and how you avoid "X" propagation when metastability problem occurs?

Thank you for your answers.

BR

 

[chandooo]

nospecify

Question is not clear!!!

 

[navi_s]

nctfile

So what is my idea. When simulation is run, and you have asynchronous process, veri often is happen that some setup or hold violation occurs. When it is happened, normally the Flip-Flop's goes to "X" state. And if "X" is propagated sometimes cause undesired circuit behavior.
So the question is how you avoid this "X" propagation.

BR

 

[mssajwan]

+optconfigfile in vcs

there can be some solution......
1. dont let such condition occurs, use synchronizers in place.(in fact this is the best practice)
2. check your library of flops, mainly hardened flops are used from avoiding such condition.(whose timing window is very narrow)
3. go to netlist fix the problem(very painful)

so avoid being in such condition by using proper synchronizers whenever asyn transfer is there .

-Manmohan

 

[navi_s]

+nctfile+

thank you for your replay

BR

 

[jarodz]

synchronizer post simulation

Hi, navi_s

If you dont want the X be porpagation, you can disable the X creation by disabling the timing check on the FF. The first FF of synchronizer always has the chance to encounter the setup/hold timing voilation in the post-layout simulation. That is just the job of the FF. For example, you can run ncverilog with +nctfile+"filename". The nctfile is the list of FFs you want to disalbe the timing check. I think there is similar way for other simulator to avoid this situation.

Sincerely,
Jarod

 

[hhlin]

disabling timing checks selectively

Refer to the Synopsys Solvnet article
https://solvnet.synopsys.com/retrieve/022278.html


Control Timings in VCS


VCS/VCSMX can disable module path delays as well as timing checks at various levels of granularity viz. on the entire design, on a specific module or on a specific timing arc in a specific instance.

1. Disabling delays and timing checks on the entire design. Use the following compile-time options

+nospecify
This suppresses the module path delays and timing checks in specify blocks.

+notimingcheck
This suppresses the timing checks in specify blocks.


2. Disabling delays and timing checks per module or instance basis

You can disable timing annotation selectively by using the configuration file
that is passed to vcs command line via +optconfigfile

Syntax :
+optconfigfile+<configFileName>


Syntax for the configuration file
----------------------------------------------------

module {list_of_module_identifiers} {list_of_attributes};

or

instance {list_of_hierarchical_names} {list_of_attributes};


where:

The module is the keyword that specifies that the attributes in this statement
apply to all the instances of the modules in the list, specified by the module
identifier.

list_of_module_identifiers is a comma-separated list of module identifiers
enclosed in curly braces: { }

list_of_attributes is a comma-separated list of timing related attributes
enclosed in curly braces: { }

The instance is a keyword that specifies that the attributes in this statement
apply to the particular instance specified by the hierarchical name.

list_hierarchical_names is a comma-separated list of hierarchical names of
module instances and signals enclosed in curly braces: { }

The list of valid attributes for timing is as follows:

noIopath : Attribute keyword that specifies disabling the module path delays
in the specified module instances.
noSpecify : Attribute keyword that specifies disabling the specify blocks in
the specified module instances.
noTiming : Attribute keyword that specifies disabling the timing checks in
the specified module instances.

3. Disable timing checks at runtime at ucli prompt

To get to the ucli prompt at runtime you need to compile the design with
-debug or -debug_pp at compile-time. At ucli prompt, specify the following
command:

tcheck <instance|port> <tcheck_type> <-msg|-xgen> [-enable|-disable] [-r]

where

<instance|port> is a hierarchical full path name of an instance or an
instance_port

<tcheck_type> is one of
[all|HOLD|SETUP|SETUPHOLD|WIDTH|RECOVERY|REMOVAL|RECREM|PERIOD|SKEW]

<-msg | -xgen> Optionally controls simulation behavior when a timing check
violation is detected as follows:

-msg disables or enables a timing violation warning on the specified instance
or port -xgen disables or enables a notifier toggling on the specified instance or
port

[-r] Optionally changes all timing checks for the specified instance and
all sub-instances recursively