In reply to dave_59:
In reply to abs:
There are a couple of problems with what you are trying to do.
You are correct about an assign statement being “one-way” when it comes to a force. The LHS cannot affect the RHS. The same is true for a port connection when one or both sides of the port is a variable. That creates an implicit assign statement. (The only exception is for a ref port, and then both sides of the port must be variables).
meaning that in my int_obs_ifm I should have a variable instead of a net and then have a procedural assignment rather than a continuous assignment, right?
It is illegal to have a non-constant select on the LHS of a force. You did not define someaddr, somebit, but I was assuming it is a variable. If your simulator is not flagging that as an error, the force is undefined if the select changes while the force is still active.
I haven’t defined the someaddress, but indeed it’s a constant (is actually set through a parameter), therefore there shouldn’t be any change in it while forcing it. That might not be the case should we want to inject the fault randomly and/or dynamically.
It is illegal to force a bit select of a packed array variable. This LRM restriction was left over from Verilog, but I think most simulators now support it in SystemVerilog.
We are using Incisive 14.2. Should I then file a bug report for not being compliant to the LRM restriction you are referring to?
A better approach for error injection in a memory is to force the output of the memory, especially when the memory is modeled in a separate block.
assign memory_output = memory_array[select1][select2]...;
force DUT.RAM.memory_output = (memory_array[select1][select2]...) ~^ error_mask;
Uhm, since we are not allowed to change the memory model (which is provided by the foundry), you are essentially suggesting to write a wrapper around it and have some sort of interface where I could inject my fault, is my understanding correct? At this point I would need to have some sort of tristate modeling since I cannot change the memory module I/O signature and I need the rest of the DUT to take into account the fault I’m injecting.
Isn’t the ‘UVM register model’ more appropriate for these kind of scenarios? On top of it the RAM module is sitting in a larger DUT, through several hierarchical layers, how do I connect my TB to the inner parts and yet have a reusable environment?