Generalizing VLSI Flows docs #718
Conversation
The gemmini config file's name is been updated from `configs.scala` to `Configs.scala`
added gettext dependency for qemu build
Updating Gemmini.rst
|
|
||
| ./scripts/init-vlsi.sh <tech-plugin-name> | ||
|
|
||
| This will pull the Hammer & CAD tool plugin submodules, assuming the technology plugins are available on github. |
There was a problem hiding this comment.
The tech plugin doesn't have to be in github. If it's not one of the default plugins in Hammer (asap7, nangate45), then it needs to be added as a submodule in the vlsi/ folder first before you run the init-vlsi.sh script. Changes the commands below slightly.
There was a problem hiding this comment.
Also I'm a bit confused about where this fits into the existing docs.
There was a problem hiding this comment.
I'm not sure I understand this comment. I know that the tech plugin doesn't have to be in github. That's the reason the following lines explain how to clone a private tech plug-in.
Why does the submodule need to be added before init-vlsi.sh. The script only initializes the submodules (rescursively). If you're cloning the submodule independently it will already be initialized, wouldn't it? And AFAIK, tech-plugins don't include submodules within them
There was a problem hiding this comment.
I think you can move the "assuming" part into the private technology sentence.
The above script will fail if your tech plugin isn't on github. If you have additional private...
There was a problem hiding this comment.
Don't you need to register the submodule by doing a git submodule add first?
| # SRAM Compiler compiler options | ||
| vlsi.core.sram_generator_tool: "sram_compiler" | ||
| # You should specify a location for the SRAM generator in the tech plugin | ||
| vlsi.core.sram_generator_tool_path: [] |
There was a problem hiding this comment.
If this is used in the asap7 demo, a more explicit (but technically redundant, since hammer knows about it already) path would be:
vlsi.core.sram_generator_tool_path: ["hammer/src/hammer-vlsi/technology/asap7"]
I don't know if you want to give this option for users who don't desire to use barstools' macrocompiler:
# Uncomment these if you are not using macrocompiler
# vlsi.inputs.sram_parameters: "hammer/src/hammer-vlsi/technology/asap7/sram-cache.json"
# vlsi.inputs.sram_parameters_meta: ["transclude", "json2list"]
There was a problem hiding this comment.
As previously noted, it is meant to be used as a template for a general case, rather than solving a single-case problem.
Given that assumption, I think any path that includes the Berkeley instructional machines eecs151 installation directory would be confusing.
There was a problem hiding this comment.
Oh sorry, I forgot to take out /home/ff/eecs151/! Edited above.
There was a problem hiding this comment.
Why would I want to specify the explicit path if Hammer is already aware if it through the tech plugin?
There was a problem hiding this comment.
Because it needs to be specified for tech plugins that are separate from main Hammer. Since this is example-tools.yml you could just add these fields with filler text instead of ASAP7.
|
|
||
| ./scripts/init-vlsi.sh <tech-plugin-name> | ||
|
|
||
| This will pull the Hammer & CAD tool plugin submodules, assuming the technology plugins are available on github. |
There was a problem hiding this comment.
I think you can move the "assuming" part into the private technology sentence.
The above script will fail if your tech plugin isn't on github. If you have additional private...
Co-authored-by: Colin Schmidt <colins@eecs.berkeley.edu>
alonamid
changed the title
| The bottom-up approach traverses a tree representing the hierarchy starting from the leaves and towards the direction of the root (the "top level"), and runs the physical design flow on each node of the hierarchy tree using the previously layed-out children nodes. | ||
| As nodes get closer to the root (or "top level") of the hierarchy, largers sections of the design get layed-out. | ||
|
|
||
| The Hammer hierarchical flow relies on a manually-specified descrition of the desired heirarchy tree. The specification of the heirarchy tree is defined based on the instance names in the generated Verilog, which sometime make this specification challenging due to inconsisent instance names. Additionally, the specification of the heirarchy tree is intertwined with the manual specification of a floorplan for the design. |
Related issue:
Type of change: other enhancement
Impact: other
Release Notes
The goal of this PR is to generalize the VLSI flow docs to be applicable to flows other than just ASAP7 (in contrast to the tutorial), including various nuances that may seem trivial to frequent users, but less trivial to occasional user.
Also includes the occasional makefile bug fix.
It's still a WIP, but open to comments