Inappropriate Verilog timescale Causes Pulse Timing Check Miss

Make it to the Right and Larger Audience


Inappropriate Verilog timescale Causes Pulse Timing Check Miss

See an interesting RTL simulation issue recently. We use an analog block which comes with a sophisticated Verilog model. One function of the model is to check one of the input signals should not contain a narrow pulse. The checker code is like below.

First, specify timescale used in the checker module


Second, specify the minimum pulse width as


Third, check and flag error if measured pulse width, in_pulsewidth, is less than above minpulsewidth.


However, when we run simulation, we notice in some simulation setup (call it A), above checker can spot and flag a narrow pulse on the input signal. But in another simulation setup (call it B), above checker does not flag the narrow pulse although waveform shows the narrow pulse is there!


Tracing signal shows minpulsewidth in env A is correctly taken as 0.01ns. But in env B minpulsewidth becomes 0 ns. In_pulsewidth is not less than 0 so env B fails to capture the narrow pulse while in_pulsewidth is <0.01ns so env A can flag it.


The issue is caused by above timescale specification. “1ns/100ps” means the unit of real numbers specified in this Verilog file is 1ns. So “minpulsewidth =0.01;” means 0.01ns. 100ps is simulation precision. However, a simulation can take in many Verilog files and the precision really used in simulation is the SMALLEST precision specified across all the files. In env B, the smallest precision happens to be 100ps which is specified in this file. But since 0.01ns is only 10ps, it needs to be rounded to 100ps so it becomes 0ns. In env A, there is another module included in simulation and that module specifies 10ps as precision. 10ps is taken as simulation precision and therefore 0.01ns in this file is correctly kept as 0.01ns instead of becoming 0ns.


So the issue with this checker is if there is a number as 0.01, make sure the timescale can handle it rather than have it rounded to 0. Don’t count on other modules to have a smaller precision.


But there are many files in a simulation setup and each of them can specify precision differently, how do we know the final precision used in simulation?




Author brief is empty


Contact Us

Thanks for helping us better serve the community. You can make a suggestion, report a bug, a misconduct, or any other issue. We'll get back to you using your private message ASAP.



Forgot your details?