Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support time and `timescales #234

Closed
veripoolbot opened this issue Apr 7, 2010 · 2 comments
Closed

Support time and `timescales #234

veripoolbot opened this issue Apr 7, 2010 · 2 comments
Labels
area: data-types Issue involves data-types effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor


Author Name: Shankar Giri
Original Redmine Issue: 234 from https://www.veripool.org


Filing separate bug as mentioned in #�. This is a pre-requisite to finally support timing events, loops and behavioral events.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-04-07T13:20:55Z


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.

  1. Write some tests that use `timescale (different values in each module),
    $display %t, and loading and setting time. Check it on other simulators.

  2. 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).

  3. Parse "#delay" and assignments of time variables to be something like
    AstCvtPackTime(delay).

  4. 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.

  1. 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 #�-real's is needed first.)

  2. 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.

  3. Probably minor changes needed to many of the other stages.

  4. 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.

  5. 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.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-12-14T15:16:02Z


Stefan Wallentowitz indicated he might get to this.

Note I have an old unpublished branch with some very preliminary stuff related to this which can be a starting point.

@veripoolbot veripoolbot added area: data-types Issue involves data-types effort: days Expect this issue to require roughly days of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 labels Dec 22, 2019
wsnyder added a commit that referenced this issue Apr 12, 2020
Includes `timescale, $printtimescale, $timeformat.
VL_TIME_MULTIPLIER, VL_TIME_PRECISION, VL_TIME_UNIT have been removed
and the time precision must now match the SystemC time precision.
To get closer behavior to older versions, use e.g. --timescale-override
"1ps/1ps".
wsnyder added a commit that referenced this issue Apr 15, 2020
Includes `timescale, $printtimescale, $timeformat.
VL_TIME_MULTIPLIER, VL_TIME_PRECISION, VL_TIME_UNIT have been removed
and the time precision must now match the SystemC time precision.
To get closer behavior to older versions, use e.g. --timescale-override
"1ps/1ps".
@wsnyder wsnyder added the resolution: fixed Closed; fixed label Apr 15, 2020
@wsnyder wsnyder closed this as completed Apr 15, 2020
jameshanlon added a commit to jameshanlon/verilator that referenced this issue Apr 20, 2020
* master: (41 commits)
  Tests: Fix makeflag test, was failing older makes.
  Internal: clang-tidy fixes. No functional change.
  Support IEEE time units and time precisions, verilator#234. (verilator#2253)
  Commentary on --build
  Tests: Fix cmake -j unknown
  Add --build option to call make/cmake as subprocess (verilator#2249)
  clang-format 10.0 forward compatibility. No functional change.
  Fix run-time formatting of variable wider than 1023 bits (verilator#2261)
  clang-format remaining sources. No functional change.
  Internals: clang-format files needed for verilator#2249.
  Fix crash when formatting constant wider than 1023 bits (verilator#2260)
  clang-format many files. No functional change. Use nodist/clang_formatter to reformat files that are now clean.
  Improve tracing performance. (verilator#2257)
  Always define VL_SIG etc; conditional definitions were long removed SystemPerl.
  clang-format: Loops allowed on single line.
  Support class new.
  Internals: NodeModule for packages.
  Internals: clang-format and refactor taskref pin handling.
  Fix --skip-identical broke recent commit.
  Fix make install/uninstall for examples/xml_py, verilator#2252.
  ...
shenki added a commit to shenki/litex that referenced this issue Nov 15, 2022
Older versions of verilator fail to build due to this error.

verilator/verilator#234

Signed-off-by: Joel Stanley <joel@jms.id.au>
shenki added a commit to shenki/litex that referenced this issue Nov 15, 2022
Older versions of verilator fail to build some SoCs due to this error.

verilator/verilator#234

Signed-off-by: Joel Stanley <joel@jms.id.au>
shenki added a commit to shenki/litex that referenced this issue Nov 15, 2022
Older versions of verilator fail to build some SoCs due to this error.

verilator/verilator#234

Signed-off-by: Joel Stanley <joel@jms.id.au>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: data-types Issue involves data-types effort: days Expect this issue to require roughly days of invested effort to resolve resolution: fixed Closed; fixed type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Development

No branches or pull requests

2 participants