Timescale and $timeformat issue

In reply to mayankmehta_83:

There are a couple of issues in play here.

The
`timescale
compiler directive has no affect on code written in $unit. The $unit time scale relies on tool defaults or the timeunit construct. There can only be one time scale in a particular $unit, module, or any other design unit.

The first timescale sets the time scale and precision of the test block it has no effect on class A. The time scale and precision of class A is set by tool defaults. You will get different results on different tools unless you use the timeunit directive or put everything in a package. The timeunit construct was designed to replace timescale (See 3.14.2.3 Precedence of timeunit, timeprecision, and timescale). The second timescale has no effect class B. It can only affect other design units that follow.

$realtime return 20000.0 because the time is 20ns and the current timescale is 1ps. That value gets converted to an 64-bit integer to be stored in t1. The fact that 20000 represents 20000ps is lost—it’s just a plain integer.

Without $timeformat, SystemVerilog scales the %t argument from what ever the current time scale is to the global precision (ps). For printA(), your tool has chosen a time scale of 1ns. So 20000 becomes 20000ns and gets scaled to 20000000 ps. With $timeforat, the %t argument gets scaled from the current time scale (ns) to the specified time scale -9 (ns). So 20000.00ns get printed.

In printB(), the times scale used to write t1 and read with $display are the same, the you get the expected output of 20000 ps or 20.0ns.