You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chisel seems to not like using else and else if in Verilog code, and this has caused a problem with my RAM block not being inferred by the Vivado synthesizer because it thinks there are more write ports than there actually are. As a minimal example, this Chisel code
The memory registers should be implemented as a RAM with one read port and one write port. However, when synthesizing this code the Vivado synthesizer gives this warning saying that this is not possible:
WARNING: [Synth 8-4767] Trying to implement RAM 'memory_reg' in registers. Block RAM or DRAM implementation is not possible; see log for reasons.
Reason is one or more of the following :
1: RAM has multiple writes via different ports in same process. If RAM inferencing intended, write to one port per process.
2: Unable to determine number of words or word size in RAM.
3: No valid read/write found for RAM.
RAM "memory_reg" dissolved into registers
In this case the reason is number 1. Because the writes to the RAM are in independent if statements, the synthesizer thinks that both writes might happen at the same time, so it cannot be a single port RAM.
Now, obviously the if statements are never both going to be true, and if I were hand-writing the Verilog I would write this (just like the Chisel)
if (io_mode)
memory[io_rw_addr] <= io_writeData;
else
memory[io_w_addr] <= io_writeData;
which is inferred correctly as a RAM block.
The Verilog output seems counterintuitive and in this case problematic, so I think this is an issue.
The text was updated successfully, but these errors were encountered:
For your example, is the intent to have a RW port and a W port on the same RAM, with the RW port having write precedence over the W port? If so, could you mux the address and data such that they share the same write port?
More generally, it appears the issue is with the current Chisel2, you cannot express precedence for these ports. For Chisel3, there is effort being applied to fix RW ports (chipsalliance/firrtl#147) and multi-write ports (chipsalliance/firrtl#125).
Well, in my actual usage the intent is to have one read port and one write port. In Xilinx terminology I think what I want is just a Simple Dual-Port RAM. The example is a bit contrived, and I probably should have put a dedicated read address input, but specific to the problem I am having the read port is irrelevant.
The problem is that Vivado thinks there are "multiple writes via different ports in same process", which, in the Chisel code, there are explicitly not. In this simple case yes I could just use a mux on the write address and that works just fine. My actual use case is more complex and a mux would make awkward code. Regardless, either way should work.
My guess is that Chisel seems to think when (mode) { A } .otherwise { B } is equivalent to if (mode) A and if (mode ^ 1) B in Verilog. The Vivado synthesizer seems to disagree, at least in the case of implying RAMs.
Chisel seems to not like using
else
andelse if
in Verilog code, and this has caused a problem with my RAM block not being inferred by the Vivado synthesizer because it thinks there are more write ports than there actually are. As a minimal example, this Chisel coderesults in this Verilog
The
memory
registers should be implemented as a RAM with one read port and one write port. However, when synthesizing this code the Vivado synthesizer gives this warning saying that this is not possible:In this case the reason is number 1. Because the writes to the RAM are in independent
if
statements, the synthesizer thinks that both writes might happen at the same time, so it cannot be a single port RAM.Now, obviously the
if
statements are never both going to be true, and if I were hand-writing the Verilog I would write this (just like the Chisel)which is inferred correctly as a RAM block.
The Verilog output seems counterintuitive and in this case problematic, so I think this is an issue.
The text was updated successfully, but these errors were encountered: