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 for [Sparse] Mems larger than 2^31 - 1 [for Simulation Purposes] #856

Closed
jackkoenig opened this issue Jul 11, 2018 · 4 comments · Fixed by #1076
Closed

Support for [Sparse] Mems larger than 2^31 - 1 [for Simulation Purposes] #856

jackkoenig opened this issue Jul 11, 2018 · 4 comments · Fixed by #1076
Assignees
Milestone

Comments

@jackkoenig
Copy link
Contributor

jackkoenig commented Jul 11, 2018

Type of issue: feature request

Impact: API addition (no impact on existing code)

Development Phase: request

Other information

If the current behavior is a bug, please provide the steps to reproduce the problem:

What is the current behavior?

The size of Mems is currently an Int, limiting the size to 2^31 - 1.

What is the use case for changing the behavior?

While current technology doesn't allow physical memories anywhere close to 2GB, it can be useful to model say 64GB of DRAM using a sparse memory. Such a simulation would likely not (although it could) use all of the larger than 2GB memory but it's especially useful for modeling a virtual memory space where a program may be located at an address > 0x0000_0000_8000_0000.

This API would require FIRRTL support which also uses Int for the size of mems.

@colinschmidt
Copy link
Contributor

It would be cool if this could be linked to FIRRTL in a way that eliminated this hack:
https://github.com/freechipsproject/firrtl/blob/f24a733dc279e93a7d5d945042ec7472a6872aa1/src/main/scala/firrtl/Emitter.scala#L537

@jackkoenig
Copy link
Contributor Author

@colinschmidt yeah removing hacks is always desirable. How would you like the API to look? Do you think sparse should be a field of Chisel (and thus FIRRTL) mems or do you think that is too much simulation bleeding into the IR?

@colinschmidt
Copy link
Contributor

I was thinking it would be an annotation on the memory. Making a memory sparse is arguably a performance optimization. Since tools have limits on non-sparse memories it is sometimes required.
Adding it to the IR doesn't seem like the right move here but I don't feel strongly.

@jackkoenig
Copy link
Contributor Author

jackkoenig commented Jul 18, 2018

Yeah I agree that it shouldn't be in the IR. One issue is that neither Verilator nor VCS support arrays larger than 2 ^ 31 - 1 entries (and further requirements depending on the data type). Through SystemVerilog, VCS can support associative arrays, but Verilator does not currently support them (https://www.veripool.org/issues/544-Verilator-Support-associative-arrays).

I think an Annotation is probably the right way to go if we add support for emitting associative arrays, otherwise maybe we just emit the "too large" array and let the user's choice of simulator be the bad guy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants