chipsalliance / chipsalliance/rocket-chip
Difference b/w D$ and DTIM
- Dominant language
- Scala
- Stars
- 3.9k
- Forks
- 1.3k
- Avg merge
- 5d 13m
- Merged PRs (30d)
- 1
Description
I have disabled the d$ and created a scratchpad memory or so called a DTIM by providing the following parameters:
```
dcache = Some(DCacheParams(
rowBits = site(SystemBusKey).beatBits,
nSets = 256, // 16Kb scratchpad
nWays = 1,
nTLBSets = 1,
nTLBWays = 4,
nMSHRs = 0,
blockBytes = site(CacheBlockBytes),
scratch = Some(0x80000000L))),
```
However, after emitting the verilog, I can still see the `DCache` module and all it's logic. Though I did not compare its internal logic with the configuration whose d$ cache is enabled. Does having a DTIM simply means: "a small on-chip sram close to the cpu without any caching mechanism"? If yes, then does the emitted verilog do not contain caching mechanism? By the look of D$ module in verilog it seems that there is some caching mechanism being done.
Contributor guide
Research direction
Start by tracing the supplied DCacheParams configuration into the emitted Verilog, comparing it with a configuration where the data cache is enabled. Clarify whether the resulting DCache module implements caching or only DTIM scratchpad behavior, and explain the difference between D$ and DTIM.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- embedded-iot
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100