Chiseltest performance for representation of memories

[Warren Savage]

I'm looking for anyone's experience in the comparative performance of Chiseltest+Verilator for simulating designs with a lot of memory.

I have a design that will never be fabricated but am playing with a number of highly parameterized architectures using wildly varying amounts of memory.  I want to evaluate these from simulation test cases.

I assumed that implementing it with Vec's of Reg would be pretty fast, but found when it gets to 3M flip-flops, it gets pretty slow and starts running out of memory.  I eventually want to evaluate up to 100-500M flip-flips, which will clearly break everything as written today.

I thought about trying the built-in Mem to see if that is faster.   Or just blackboxing a behavioral  Verilog model.  But before either, I thought I'd ask if anyone  had been here before.  

Any thoughts, recommendations?

Warren

[Kevin Laeufer]

Definitely use a built in amen whenever possible. That will simulate much faster than a Vec and also reduce the compile times and size of generated Verilog by a lot.

Essentially when something behaves like a memory, I.e. limited number of read and write ports for a single entry, you should use Mem. Vec mostly makes sense if you need parallel access of all elements.

Kevin

Sent from my iPhone

On May 9, 2022, at 12:44, Warren Savage <warren...@rocksavage.tech> wrote:

I'm looking for anyone's experience in the comparative performance of Chiseltest+Verilator for simulating designs with a lot of memory.

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/07b60c1c-70da-42d7-9785-2b4ab1b14193n%40googlegroups.com.

[Warren Savage]

Wow, you aren't kidding.  WAY faster!   Thanks Kevin.

---

From: chisel...@googlegroups.com <chisel...@googlegroups.com> on behalf of Kevin Laeufer <lae...@berkeley.edu>
Sent: Monday, May 9, 2022 12:48:27 PM
To: chisel...@googlegroups.com
Subject: Re: Chiseltest performance for representation of memories

 

You received this message because you are subscribed to a topic in the Google Groups "chisel-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chisel-users/PICBTpTp-o8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chisel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/52A4D4FD-E3C9-4CDA-9DB7-9D3EA86B4F39%40berkeley.edu.

[Øyvind Harboe]

What I did when I needed gigabytes of memory for a design, is that I implement the memory in C++ outside of Verilator. In my case it was easy to make the memory master interface available at the top level of the design.

If you have memories deep inside the design, then you *could* use BoringUtils to dependency inject the memory such that the memories are available at the top level of your design and that you can implement the memory in C++ outside of Verilator.

If your memory is implemented in C++, size doesn't matter w.r.t. performance beyond the time that it takes the CPU that runs Verilator to read and write to that memory.

Using BoringUtils on signals is straightforward. I've gotten it to work for interfaces and dependency inject like I describe above, but it is a bit finicky and outside the scope of what BoringUtils supports directly.