Support time and `timescales
Filing separate bug as mentioned in bug223. This is a pre-requisite to finally support timing events, loops and behavioral events.
#1 Updated by Wilson Snyder over 9 years ago
- Category set to Unsupported
- Status changed from New to Feature
This is probably a week or so. It's also not really that complicated, just a mess of places to edit and it needs hooks into in C standalone, SystemC and tracing.
0. Write some tests that use `timescale (different values in each module), $display %t, and loading and setting time. Check it on other simulators.
1. Add lexing and parsing of "`timescale" and "timeprecision/timeunits". These would create a new AstTimescale type, with Timescale in powers of ten (IE ns = -9).
2. Parse "#delay" and assignments of time variables to be something like AstCvtPackTime(delay).
3. In (maybe) V3LinkParse, move the AstTimescale information from that custom location to instead be attached to the AstNodeModule.
Compute the minimum timeunits across all modules, that's our simulation timescale.
4. Any AstDisplays need to add calls to AstCvtTimePack to convert the internal time back to the display format. (Presumably it's printed as a double, so bug233-real's is needed first.)
5. V3Const would convert AstCvtPackTime(delay) to use that module's timeunits to scale the delay. IE it would become AstMul(delay,timescale). Likewise AstCvtTimePack would do the reverse.
6. Probably minor changes needed to many of the other stages.
7. The simulation timescale needs to be put into the generated code. For backward compatibility I would probably assume the simulation timescale is what VL_TIME returns.
8. Fix the tracing code to know the correct timescale.
Ask as you hit issues. Also feel free to send patches as you go, especially the new tests.
Also available in: Atom