chipsalliance / chipsalliance/chisel
SyncReadMem ruw (ReadUnderWrite) parameter has no effect
- Dominant language
- Scala
- Stars
- 4.8k
- Forks
- 658
- Avg merge
- 18h 59m
- Merged PRs (30d)
- 14
Description
**Type of issue**: Bug Report
**Please provide the steps to reproduce the problem:**
Generate verilog for the code below using different values for the last parameter (`ruw`) of the `SyncReadMem` call
```scala
class MemTest extends Module (){
val io = IO(new Bundle {
val wrEn = Input(Bool())
val wrAddr = Input(UInt(8.W))
val wrData = Input(UInt(8.W))
val rdEn = Input(Bool())
val rdAddr = Input(UInt(8.W))
val rdData = Output(UInt(8.W))
})
/* try using SyncReadMem.ReadFirst or SyncReadMem.WriteFirst here */
val m = SyncReadMem(256, UInt(8.W), SyncReadMem.Undefined)
when (io.wrEn) {
m.write(io.wrAddr, io.wrData)
}
io.rdData := m.read(io.rdAddr, io.rdEn)
}
```
**What is the current behavior?**
The generated verilog code always behaves as WriteFirst. If a memory entry is read and written in the same clock cycle, the read data gets the newly written value in the next cycle.
The important parts of the generated verilog code is:
```verilog
always @(posedge R0_clk) begin
_R0_en_d0 <= R0_en;
_R0_addr_d0 <= R0_addr;
end
always @(posedge W0_clk) begin
if (W0_en & 1'h1)
Memory[W0_addr] <= W0_data;
end
assign R0_data = _R0_en_d0 ? Memory[_R0_addr_d0] : 8'bx;
```
**What is the expected behavior?**
The generated verilog should behave as specified by the `ruw` parameter, or as described in the [Chisel Memories documentation](https://www.chisel-lang.org/docs/explanations/memories#read-write-memories) when `ruw` is not specified.
**Please tell us about your environment:**
- Chisel version: `6.5`
- SBT version `1.9.8`
**Other Information**
**What is the use case for changing the behavior?**
It should be possible to simulate SRAMs with different read/write conflict behaviour without replacing the memories with vendor models.
Contributor guide
Assessment
This issue has not been assessed yet.