True Dual-Port memory verification

[laugensalm]

Does anyone know about an opensource verification library for true dual port block RAM primitives that works with separate clocks? Preferred language is Verilog, I'm targetting at the icarus verilog simulator, so that the entire verification chain can be dropped into the cloud without license issues.
One coming close to what I'm looking for is this one (https://github.com/kowsyap/Physical-Design-and-Verification-of-DPRAM-using-SV-UVM-and-Semi-Custom-Design), but it uses one clock for both ports, obviously.
The kind of checks I'm thinking of:

• Concurrency and priority checks, like read-before-write and write-through scenarios
• bit width, mirroring checks, etc.
• Initialization (dual port ROM option) and reset behaviour

[SiliconWizard]

I do not really, and your quest is interesting.

The checks you mention are all doable, but I wonder what you mean by "concurrency" in general though.

Most HDL (VHDL, Verilog...) simulators out there can't simulate clock domain crossing issues properly, in particular potential *metastability* issues, which can be a bitch.
So any problem related to clock domain crossing is going to be hard to detect.

But if anyone knows how to do this properly, or which tools are appropriate, I'll be interested too.

[BrianHG]

Write your own simulated dual port ram.

When a write on clock A occurs, immediately set the data to 'hxxxx (IE: unknown), delay for the worst case amount of time it takes the FPGA to set the memory matrix, then, make the memory array = to the written data.

This way, when simulating, reads done too quick to a memory location which has just been written to will return 'hxxxx easily showing that you have done a read too quick just after a write, regardless of the 2 different source clocks.

This guarantees to show you problems where as in the real world, they may not appear if you write data which is equal to the existing contents which would appear to function, yet you should not be coding like that.

[laugensalm]

Just to make sure: I'm looking for the test bench reference, not the primitive model. Also, I would want to avoid modifying anything existing on the test bench side, the point is to use a 'neutral' reference that's proven by someone else.

Concerning 'concurrency': When both ports are writing to the same address within the same time interval, or both addresses match and `write_enable` is asserted.
Metastability and timing issues would indeed be handled 'manually' by a transition state, I've used weak standard logic for that in VHDL, not sure how that would check out with iverilog. But that behaviour in particular would not have to be taken care of in detail, as concurrent writing should never occur in a design anyhow. Plus some models don't include any timing and are purely functional. So it would suffice to just show "Collision detection : [yes, no]" for each primitive model (each of totally different architecture) in some status report matrix, ideally. Same goes for simultaneous read/write to/from same address in a WRITE_THROUGH architecture.
In a first step, a simple functional verification of a post-map design model would already do. It could also be a pure black-box analysis that sets a flag like: This is a WRITE_THROUGH architecture.

[BrianHG]

You cannot get that detail in a functional verification.  Each time you do a full compile on the FPGA, all such precise timing changes based on how the fitter routed the FPGA making your sim useless if your recompile with 1 gate changed, or even set a different compiler routing effort time.  You must use timing based on the worst possible delays achievable or simulate from the FPGA fabric limiting your to each vendor's in-house tools.  Even the temperature of the FPGA die has an effect here.  If you are using dualport blockrams so close to the edge with so much memory available, maybe re-think part of your design or use logic gates.  I always wait an additional spare 2-3 clocks before expecting the memory to be available and never worry about metastability.

I have not seen any publicly verified pre-built cores as I use Quartus which supplies their own support libraries with all this already taken into account.  When supplying code for other vendors, I just pre-built my own dual port sim.

Yes, verilog supports unknown & weak logic states with their sims as well as the ability to program/assign natural asynchronous timing delays until a logic state is ready or changed, including the addition of multiple transition events.  This is BS in my park as I consider the data in error until it is truly valid.

[laugensalm]

@BrianHG: Again, I am *not* looking for a TDP BRAM model, nor a post-*PnR* timing accurate  simulation.

In other words: I've collected a bunch of models, some more, some less accurate or verbose WRT collision/timing issues, some of them from vendor simulation libraries, and I'd like to classify them in an automated way, eventually.
The point about simulation post-map (no fitting or routing yet)  is just to skip the burden of wrapping each primitive manually and let the tools do the inference instead, such that the top level interface is always the same (I'm well aware that mapping might introduce issues, create extra gate logic, etc.).
Some projects like PoC cover such a test bench for the VHDL side up to a certain point (aside from verification libs like UVVM), I'm using a Co-Simulation setup, what's missing, is a third party,  (System)-Verilog base (aside from the mentioned project in the first post) that runs 'open source' to allow others to reproduce results with any other Verilog based RAM model, tool or mapping rule.