search

chipsalliance / chisel

Chisel: A Modern Hardware Design Language
https://www.chisel-lang.org/
Apache License 2.0
3.98k stars 596 forks source link

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

Closed jackkoenig closed 5 years ago

jackkoenig commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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.