shunshou
commented
7 years ago So I also started working on this. The original file with a bunch of work has been buried, but can be revived. The issue I had with integrating this stuff into Firrtl directly is that there are a lot of weird edge cases, and I think there will always be some knob for funky designs that people won't have access to.
Say, for example, the default vlsi_mem_gen would be very unhappy with the fact that I used odd-depth-ed memory for my FFTs. If you want to split large memories up and originally had odd depth memories, it's even more annoying to deal with. I've since spent some time thinking about the problem, and I think I could code something up at least as a starting point whenever I have more cycles... Rocket-chip might be a good base case to try this with, but definitely supporting only power of 2 isn't good enough.
I'm sure there are other funky issues that people might run into. If that's the case, I think maybe the specific methodology for splitting memories, etc. shouldn't be built into FIRRTL directly. There might be some default one that people can overwrite in their own project.
For all of these suggestions, I highly recommend using some templating thing like Handlebars and just creating repos/directories containing configuration templates for all technologies that people are interested in using.
aswaterman
chick
This is a summary of the discussion at the Hurricane-2 debrief meeting.
The consensus: rather than relying on external user-generated tools to fill in the blackboxes emitted by the --replSeqMem pass, Firrtl should support the emission of "complete" verilog, including SRAM models. Supported use cases would include:
The mapping of requested memories to SRAMs available in a particular technology is non-trivial and can be potentially made quite sophisticated (e.g., tiling multiple SRAMs to match a single memory blackbox, selecting optimal memories according to area/delay/aspect ratio constraints).