How to generate ASAP7 MegaBoom Hammer files with synflops?

[Øyvind Harboe]

I'm trying to generate ASAP7 MegaBoom Hammer files with synflops.

make CONFIG=MegaBoomConfig tech_name=asap7 INPUT_CONFS=example-asap7.yml TOP_MACROCOMPILER_MODE='--mode synflops' syn

In particular, I am interested in studying the generated .sdc files.

However, I'm getting this error.

Any hints?

Non-sequitor: filed two small pull requests...

https://github.com/ucb-bar/chipyard/pull/1745

https://github.com/ucb-bar/chipyard/pull/1744

mkdir -p vlsi/build/chipyard.harness.TestHarness.MegaBoomConfig-ChipTop/

echo "vlsi.inputs.sram_parameters: 'vlsi/generated-src/chipyard.harness.TestHarness.MegaBoomConfig/chipyard.harness.TestHarness.MegaBoomConfig.mems.hammer.json'" >> vlsi/build/chipyard.harness.TestHarness.MegaBoomConfig-ChipTop/sram_generator-input.yml

echo "vlsi.inputs.sram_parameters_meta: [\"transclude\", \"json2list\"]">> vlsi/build/chipyard.harness.TestHarness.MegaBoomConfig-ChipTop/sram_generator-input.yml

cd vlsi && ./example-vlsi -e vlsi/env.yml -p example-asap7.yml -p vlsi/build/chipyard.harness.TestHarness.MegaBoomConfig-ChipTop/sram_generator-input.yml --obj_dir vlsi/generated-src/chipyard.harness.TestHarness.MegaBoomConfig sram_generator

[96m[<global>] Loading hammer-vlsi libraries and reading settings [0m

Traceback (most recent call last):

File "vlsi/./example-vlsi", line 61, in <module>

ExampleDriver().main()

File ".conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 1725, in main

sys.exit(self.run_main_parsed(vars(parser.parse_args(args))))

File ".conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 1617, in run_main_parsed

driver, errors = self.args_to_driver(args)

File ".conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 1376, in args_to_driver

driver = HammerDriver(options, config)

File ".conda-env/lib/python3.10/site-packages/hammer/vlsi/driver.py", line 104, in __init__

self.load_technology()

File ".conda-env/lib/python3.10/site-packages/hammer/vlsi/driver.py", line 148, in load_technology

tech_module: str = self.database.get_setting("vlsi.core.technology")

File ".conda-env/lib/python3.10/site-packages/hammer/config/config_src.py", line 846, in get_setting

if key not in self.get_config():

File ".conda-env/lib/python3.10/site-packages/hammer/config/config_src.py", line 802, in get_config

self.__config_cache = combine_configs(

File ".conda-env/lib/python3.10/site-packages/hammer/config/config_src.py", line 1125, in combine_configs

expanded_config_reduce = reduce(update_and_expand_meta, configs, {}) # type: dict

File ".conda-env/lib/python3.10/site-packages/hammer/config/config_src.py", line 738, in update_and_expand_meta

meta_func(newdict, setting, meta_dict[setting])

File ".conda-env/lib/python3.10/site-packages/hammer/config/config_src.py", line 435, in transclude_action

with open(value, "r") as f:

FileNotFoundError: [Errno 2] No such file or directory: 'vlsi/generated-src/chipyard.harness.TestHarness.MegaBoomConfig/chipyard.harness.TestHarness.MegaBoomConfig.mems.hammer.json'

make: *** No rule to make target 'syn'. Stop.

[Harrison Liew]

Generating with synflops means that you are trying to map the entire memory array into flip-flops. For the size of MegaBoom (many MBs), this is completely impossible to implement as flip-flops, i.e., no synthesis/place & route tool will converge to a solution at any clock frequency. We have found that even the TinyRocket can barely be implemented as synflops in commercial tools, and impossible in OpenROAD.

Regarding your error, if you are using Hammer, it expects a .mems.hammer.json file generated by MacroCompiler targeting actual SRAMs. Since you changed it to --synflops option, it doesn't generate this file anymore, hence the error. Please map to the SRAM22 libraries as outlined here: 2.4. Sky130 Technology Library — Hammer 1.0.0 documentation (hammer-vlsi.readthedocs.io). Note, however, that we are in the process of post-tapeout measurements of these SRAMs (yes, we know SRAMs have been a problem in Sky130).

[Øyvind Harboe]

ons. 31. jan. 2024, 20:24 skrev 'Harrison Liew' via Chipyard <chip...@googlegroups.com>:

Generating with synflops means that you are trying to map the entire memory array into flip-flops. For the size of MegaBoom (many MBs), this is completely impossible to implement as flip-flops, i.e., no synthesis/place & route tool will converge to a solution at any clock frequency. We have found that even the TinyRocket can barely be implemented as synflops in commercial tools, and impossible in OpenROAD.

The reason why I want synflops, is that I want to handle the SRAMs myself via mocking in OpenROAD instead of using Hammer.

For more details on the motivation for doing this: https://github.com/The-OpenROAD-Project/megaboom

Short version: this makes it easier to "betatest" OpenROAD on this design.

Regarding your error, if you are using Hammer, it expects a .mems.hammer.json file generated by MacroCompiler targeting actual SRAMs. Since you changed it to --synflops option, it doesn't generate this file anymore, hence the error. Please map to the SRAM22 libraries as outlined here: 2.4. Sky130 Technology Library — Hammer 1.0.0 documentation (hammer-vlsi.readthedocs.io). Note, however, that we are in the process of post-tapeout measurements of these SRAMs (yes, we know SRAMs have been a problem in Sky130).

I am studying ASAP7 with OpenROAD, not sky130.

--
You received this message because you are subscribed to a topic in the Google Groups "Chipyard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chipyard/ePB_hb3dtfk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chipyard+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/c99e7c3b-5e9a-44e5-b76b-680ecf3c40adn%40googlegroups.com.

[Harrison Liew]

I see. My mistake for thinking you were using ASAP7 instead of Sky130.

Regardless of the technology, mapping such a huge design to flip-flops is fundamentally impossible for the tools to handle. Unfortunately, ASAP7 is not even supported by OpenRAM or DFFRAM, and we have no plans to support it with Sram22. I suggest that you move your exploration to Sky130, as it has a more complete PDK and more support from the community and OpenROAD going forward.

[Øyvind Harboe]

My goal is to do architectural exploration, not to create a gds file. So I dont need real SRAM(the ASAP7 PDK is an exploratory PDK, it is not for tape out).

I have a solution for SRAMs, I mock them. This means that I tweak the synflops Verilog to have fewer rows, but I use all the input/output pins. This gives me a valid .lib file and I can then create a .lef file that is scaled to some area. The actual timing can also be scaled this way. This is not super accurate, but a lot can be learned even so.

Mocking is a method that extends to other types of hard macros: multipliers, barrel shifters, etc. It is quite general, at the cost of sacricing accuracy.

https://github.com/The-OpenROAD-Project/megaboom/blob/c1547aa4913163fd63b51f2c4a6b7123a70764ea/BUILD.bazel#L717

The only missing piece is to generate a synflops version from Chipyard.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/47b5a0a4-670c-4e64-8089-767612eac433n%40googlegroups.com.

[Harrison Liew]

Understood. Mocking can work, if you are able to prevent synthesis from optimizing out ports/logic due to your missing internal bits/logic. I assume your .lib file encodes the "SRAM"'s behavior properly to avoid this.

If you are creating custom lib/lef/etc. then you should bypass the srams Make target of the Chipyard VLSI flow altogether, which takes the output of MacroCompiler and compiles the lib/lef/etc files needed for the PD flow. Instead, you should create your own yml/json file for the libraries containing your mock SRAMs. This file provides a good example of the format.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CACELUGd2pqWMm8y%3DZcmAphDG%3DObjt68iPdcet29YmR3x6vCsTg%40mail.gmail.com.

[Øyvind Harboe]

Yes: I am able to avoid mocking optimizng away everything with a bit of care to use e.g. all address pins even if I have fewer rows.

The reason why I want synflops is that I depart from the Chipyard/Hammer flow to use mocking and Bazel on top of OpenROAD-flow-scripts.

Hence, I should not need to describe the SRAMs in yaml/json files as I have already departed from Chipyard/Hammer at that point.

Later, after architectural exploration, I intend to use the full Chipyard/Hammer flow, but then with with a real PDK and SRAM macros.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CAEp5d3x9tYc0XxAboyqdoYPbtPZQCTm49qoWEKC7RosdzQNoCA%40mail.gmail.com.

[Harrison Liew]

I see. So I don't see what the problem is anymore, if you're not using Hammer... you can just take the Chipyard-generated Verilog and go straight to your mocking and Bazel flow.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CACELUGfvNM0zhz_-ie_Vb-ohV6ghUGU48_M5n29065LgYRahQw%40mail.gmail.com.

[Øyvind Harboe]

Ref. the original post, I'm still interested in having .sdc files generated by Hammer.

Is my assumption that Hammers generate .sdc files correct or are they hand-written?

[Øyvind Harboe]

Yes, slide 45. There are .sdc files generated by Hammer, which I'm interested in generating and examining.

https://fires.im/micro22-slides-pdf/05_hammer_generate_gds.pdf

[Harrison Liew]

The keys in this section get translated into SDC constraints: https://github.com/ucb-bar/hammer/blob/b8a15a8f41efe72f7d238c00f1117fc0b922bec4/hammer/config/defaults.yml#L176-L214

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/35d9521a-77f2-4529-83e7-fce0afefc9f3n%40googlegroups.com.

[Øyvind Harboe]

I see. I'm curious to see how Hammer can go from this information to detailed constraints, such as a constraints for asynchronous FIFOs.

Example of such a .sdc file: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/designs/asap7/mock-cpu/constraint.sdc

For instance: how does Hammer/Chipyard find the names of the flip-flops involved? The asynchronous FIFOs do not have top-level or even macro pins.

This is pretty complicated stuff and it is not at all obvious to me that this can be automated.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CAEp5d3wmpdY9SPL8ueM9oUAVt3-Y8i440yoL8EsQYU1F6cQ2Pg%40mail.gmail.com.

--

Øyvind Harboe
+4791786146

[Harrison Liew]

We can automate a large majority of SDC commands. This is the implementation code, if you're curious: https://github.com/ucb-bar/hammer/blob/b8a15a8f41efe72f7d238c00f1117fc0b922bec4/hammer/vlsi/hammer_vlsi_impl.py#L2168

You just need to provide the SDC command that finds pins/ports (e.g. [get_pins ...]) in the path field of the clock constraint, for example. It's all just string substitution when writing an SDC file.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CACELUGd%3DZehcQjfUcxAf8ua4pG1i1EYorEQo9NNRkvojyv5Hyw%40mail.gmail.com.

[Øyvind Harboe]

Silly question: I can generate the Verilog files from Chipyard with the "make verilog" target, can I similarly generate the .sdc files without running Hammer stages(synthesis, place, route, etc.)?

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CAEp5d3xQ7vawZA1kkruCJEiseQSvys2q6Npu_2%3DSYa4YNJWPSg%40mail.gmail.com.

--

Øyvind Harboe
+4791786146

[Harrison Liew]

If you set the synthesis.genus.generate_only key and run just the syn action, it will generate all the files required for synthesis but won't invoke Genus. You can then take the two SDC files out for whatever you need to do.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/CACELUGcnkeKPDocbFTJxUjQOta57g%3DOrJOoKFx2rfAV-XoXpXg%40mail.gmail.com.

[Øyvind Harboe]

Trying... It seems like it is trying to start synthesis, but it does generate the .sdc files.

However the .sdc script doesn't contain all the clocks and there is no mention of anything constraints w.r.t. the asynchronous FIFOs.

Maybe the generation failed before it could complete the .sdc file? Is an .sdc file written out by the synthesis stage where additional constraints are added to the .sdc file? The syn.tcl seems to be setting up some constraints, like set_dont_use.

create_clock clock_uncore_clock -name clock_uncore_clock -period 1000.0

set_clock_uncertainty 100.0 [get_clocks clock_uncore_clock]

set_clock_groups -asynchronous -group { clock_uncore_clock }

$ git diff example-*
diff --git a/vlsi/example-asap7.yml b/vlsi/example-asap7.yml
index e46aea03..672424cd 100644
--- a/vlsi/example-asap7.yml
+++ b/vlsi/example-asap7.yml
@@ -88,3 +88,5 @@ vlsi.inputs.pin.assignments: [
 
 # SRAM Compiler compiler options
 vlsi.core.sram_generator_tool: "hammer.technology.asap7.sram_compiler"
+
+synthesis.genus.generate_only: true
diff --git a/vlsi/example-tools.yml b/vlsi/example-tools.yml
index 57cfd124..ac1ba92e 100644
--- a/vlsi/example-tools.yml
+++ b/vlsi/example-tools.yml
@@ -21,3 +21,4 @@ vlsi.core.power_tool: "hammer.power.voltus"
 power.joules.version: "211"
 power.voltus.version: "211_ISR3"
 # NOTE (about VCS+Voltus versions): if using FSDB, the VCS version should be approx 2 years older than the Voltus version for compatibility
+synthesis.genus.generate_only: true
$ make CONFIG=ChipLikeRocketConfig VLSI_TOP=ChipTop tech_name=asap7 INPUT_CONFS="example-tools.yml example-asap7.yml" syn

[deleted]
[synthesis] Generate-only mode: command-line is /DDI/DDI211/GENUS211/bin/genus -f /home/oyvind/chipyard/vlsi/build/chipyard.harness.TestHarness.ChipLikeRocketConfig-ChipTop/syn-rundir/syn.tcl -no_gui

Traceback (most recent call last):

  File "/home/oyvind/chipyard/vlsi/./example-vlsi", line 61, in <module>
    ExampleDriver().main()
  File "/home/oyvind/chipyard/.conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 1725, in main
    sys.exit(self.run_main_parsed(vars(parser.parse_args(args))))
  File "/home/oyvind/chipyard/.conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 1630, in run_main_parsed
    output_config = action_func(driver, errors.append)  # type: Optional[dict]
  File "/home/oyvind/chipyard/.conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 592, in action
    success, output = driver.run_synthesis(
  File "/home/oyvind/chipyard/.conda-env/lib/python3.10/site-packages/hammer/vlsi/driver.py", line 930, in run_synthesis
    run_succeeded = self.syn_tool.run(hooks_to_use)
  File "/home/oyvind/chipyard/.conda-env/lib/python3.10/site-packages/hammer/vlsi/hammer_tool.py", line 118, in run
    return self.fill_outputs()
  File "/home/oyvind/chipyard/.conda-env/lib/python3.10/site-packages/hammer/synthesis/genus/__init__.py", line 34, in fill_outputs
    raise ValueError("Output find_regs_cells.json %s not found" % (self.all_cells_path))
ValueError: Output find_regs_cells.json /home/oyvind/chipyard/vlsi/build/chipyard.harness.TestHarness.ChipLikeRocketConfig-ChipTop/syn-rundir/find_regs_cells.json not found
make: *** [/home/oyvind/chipyard/vlsi/build/chipyard.harness.TestHarness.ChipLikeRocketConfig-ChipTop/hammer.d:73: /home/oyvind/chipyard/vlsi/build/chipyard.harness.TestHarness.ChipLikeRocketConfig-ChipTop/syn-rundir/syn-output-full.json] Error 1
$ find . | grep sdc
./build/chipyard.harness.TestHarness.ChipLikeRocketConfig-ChipTop/syn-rundir/pin_constraints_fragment.sdc
./build/chipyard.harness.TestHarness.ChipLikeRocketConfig-ChipTop/syn-rundir/clock_constraints_fragment.sdc

[Øyvind Harboe]

Reading  https://github.com/ucb-bar/hammer/blob/b8a15a8f41efe72f7d238c00f1117fc0b922bec4/hammer/vlsi/hammer_vlsi_impl.py#L2168 it doesn't look like more sophisticated (constraints for FIFOs) are generated by Hammer.

So how are constraints for asynchronous FIFOs handled?

[Harrison Liew]

For async FIFOs, you need an enqueue and a dequeue clock. As long as you don't specify a common group, then a set_clock_groups -asynchronous -group {enqueue_clock} -group {dequeue_clock} will be written out to clock_constraints_fragment.sdc.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/1164f14a-3aa0-4b80-b2ee-e16acd22f10an%40googlegroups.com.

[Øyvind Harboe]

What about other finer points w.r.t. clocks and asynchronous FIFOs, such as here https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/0adaebe958681ae37a4c431081eba33f27a87411/flow/designs/asap7/mock-cpu/constraint.sdc#L44 ?

Are those things that the user should add manually with tcl snippets or can/will Hammer generate those also?

I read these two articles on FIFOs and constraint files and more than defining two clocks as asynchronous is recommended:

http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO1.pdf

https://gist.github.com/brabect1/7695ead3d79be47576890bbcd61fe426

[Harrison Liew]

The catch-all key for any more complex SDC commands is this one. That is where you can add your false paths, max delays, etc. They appear at the end of pin_constraints_fragment.sdc.

To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/4d469274-6532-47ff-a384-ced35ddc13ean%40googlegroups.com.