cocotb: VCS Timescale Mismatch?
I have a design that has a clock with a period of 10 (in default cocotb units), and a simulation that runs for 8508 cycles. What I see in the report for VCS is the following:
*********************************************************************
** TEST PASS/FAIL SIM TIME(NS) REAL TIME(S) RATIO(NS/S) **
*********************************************************************
** tb.test_app PASS 85081000000000.00 [redacted] **
*********************************************************************
Well, that’s not right, there are 9 extra 0s. 1ns is 1e-9s, so that’s a bit suspicious. What does Incisive say?
*********************************************************************
** TEST PASS/FAIL SIM TIME(NS) REAL TIME(S) RATIO(NS/S) **
*********************************************************************
** tb.test_app PASS 85081.00 [redacted] **
*********************************************************************
Ok, that looks correct.
What’s going on here? Did I misconfigure something or is there something wrong with how cocotb is setting up the VCS testbench?
In any case, it’s questionable that the same testbench is not consistent across simulators.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 25 (23 by maintainers)
Commits related to this issue
- Add timescale to Aldec `alog` Adds timescale argument to `alog` following comments in #1102. — committed to hofstee/cocotb by hofstee 4 years ago
- Add timescale to Aldec `alog` Adds timescale argument to `alog` following comments in #1102. — committed to cocotb/cocotb by hofstee 4 years ago
- Add timescale to Aldec `alog` Adds timescale argument to `alog` following comments in #1102. — committed to cmarqu/cocotb by hofstee 4 years ago
Actually, I think we need two environment variables
COCOTB_HDL_TIMESTEPandCOCOTB_HDL_TIMEPRECISIONso that we don’t rely on the format of the “step/precision” string.