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

Make simulations work for times longer than given by an int32 time. #445

Open
tomcl opened this issue Mar 28, 2024 · 0 comments
Open

Make simulations work for times longer than given by an int32 time. #445

tomcl opened this issue Mar 28, 2024 · 0 comments

Comments

@tomcl
Copy link
Owner

tomcl commented Mar 28, 2024

Is your feature request related to a problem? Please describe.

Currently simulations cannot continue for more than approx 2,000,000,000 clock cycles (2^31 - 1) because time is represented by an int32. This limit can be reached within a few minutes on a small circuit.

Describe the solution you'd like

Make this limit arbitrary by using bigint not int to represent times. Note that although time is now bigint indexes into the (limited size) circular array are still int.

Describe alternatives you've considered

  • It would be possible to use uint32 for an easy doubling of range - that is not really enough
  • It would be possible to use int64 - but the JS translation of int64 is bigint anyway!

Additional context

  • This is relatively easy refactoring but will require understanding of the simulator code in some detail
  • The code that calls the simulator is currently very messy - with layers of functions calling the underlying top-level simulation function FastRun.runFastSimulation
  • As part of the refactoring these functions should be traced and fully documented to make future changes this code easier.

Refactoring Notes

  • The simulation time is held inside the fast simulation record as a mutable fs.ClockTick. That means changing the type of ClockTick will probably via the compiler lead to the necessary refactoring of simulation times.
  • Most problematic will be the display functions for time which will need to be changed. Displaying int64 would however be enough since practically we cannot get beyond max int64 clock ticks.
  • The simulator is called from a number of other top-level functions in FastRun. Those must all be checked for possible necessary refactoring of the simulation time type.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant