Foundry supplied SRAM macros; gaps in understanding

[mysa...@gmail.com]

Hi all,

I'm working on stitching together the verilog of a modified Rocketchip and technology-specific TSMC SRAM macros (available as is, or can be generated via an accompanying SRAM compiler).

I read section 4.6 of Chipyard document, and what I understand is that in common.mk file, we can update the MACROCOMPILER_MODE variable appropriately to use particular SRAM verilog models.

Reading tools/barstools/{macros, mdf} seems to suggest I should have a "SRAMMacro" object for both the available libraries (from the foundry) and the required configuration (generated by chisel) in order to invoke the barstools supplied compiler. 

Does it mean I have to wrap the TSMC macro into the "SRAMMacro" object myself? If so, how do I establish the linking between the actual verilog (also from TSMC) and the macro object that I create?

Also, if anyone is aware of any document or an example that does it, it'd be great.

Regards,

Anoop

[mysa...@gmail.com]

Clarification:

I have to wrap the metadata (that includes width, depth, ports, port names, etc) of the set of macros obtained from the foundry into a JSON file, whose format must match that provided in tools/barstools/mdf/macro_format.json, and the chipyard's make routine (via the MacroCompiler) generates a verilog wrapper with appropriate port names, module names, etc. as declared in the JSON file, and instantiations of the library SRAM verilog module; the actual verilog just has to then be added as an additional file either as dependency in the make routine, or manually. Is this understanding correct?

Also, if I may be so bold, could I ask if anybody has tried wrapping TSMC SRAM macros into that JSON format mentioned above, if it's possible to share the wrapper code for any set of the macros used?

If there is a better way to do this, please let me know. Any help is much appreciated.

[Colin Schmidt]

Hello Anoop,

These are reasonable questions and its a little difficult to understand how this system works without examples. Fortunately the open source technologies supported by hammer provide a few.

If you are looking to use a fixed set of SRAMs (not generating new ones) then you will want to use the MACROCOMPILER_MODE as a cache.

If you are following the standard Hammer directory structure for a tech plugin (which I would recommend) then simply setting tech_name to the name of your technology will cause the makefile to expand and automatically set tech_dir, which will cause SMEMS_CACHE(see the top of vlsi/Makefile) to point to the MDF description of your SRAMs.

This JSON file is a serialized representation of the SRAMMacro objects that correspond to your set of available SRAMs. You can see some examples for asap7 and nangate45.

These objects enable barstools to match the available ports on your SRAMs with the requested functionality of your Chisel memories.

Barstools will then generate any extra logic needed to map to your available SRAMs.

You will also want to include the SRAM collateral in your Hammer configuration, which can be automatically generated using the sram_compiler abstraction (asap7 example), which can work even with what Barstools "cache" configurations. This process could be annoying or difficult if your collateral is not regularly named or located in widely varied locations, or has other irregularities. In this case you can write the Hammer configuration of the collateral by hand. At the end of this process you will have the same file either way, but it is a lot more effort to maintain the hand crafter version.

Hopefully this helps expand on the process of including foundry memories in Chipyard designs with Hammer. Let me know if you have further questions.

Thanks,

Colin

--
You received this message because you are subscribed to the Google Groups "Chipyard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chipyard+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/92fd27c6-3811-4839-9b26-53d703af265an%40googlegroups.com.

[mysa...@gmail.com]

Thanks for the detailed explanations, Colin. Got the hang of it now!

[YiKang OuYang]

Hi, may I ask have you successfully written the "wrapper code" for chipyard and TSMC SRAM, and have you run simulation successfully. I just encoutered trouble in this stage.