ucb-bar / hammer Goto Github PK

Hi Palmer. This project looks incredibly interesting - I was curious what the intended license is?

run-synthesis fails without predefined top modules. I think it should just warn it.

Specify which clocks are asynchronous, etc to each other.

Does hammer still support them?

Thanks to @stevobailey

After running MacroCompiler, it's possible we want to run a technology-specific memory compiler if the memories are not pre-compiled. We should add functionality to do this.

TECHNOLOGY needs to set TECHNOLOGY_CCS_LIBERTY_FILES or TECHNOLOGY_NLDM_LIBERTY_FILES.

Solution: rm -rf obj/technology/saed32/

This was caused by updating plsi without cleaning anything up

Given we are ok using par I think we can also shorten synthesis to syn

Its not always a simple flat keepout on all sides.

For example pins might live outside the PR boundary, the simple keepout might stop power straps, etc.

I think at first it can be a binary switch but sometimes you might need to name which cells you want.
Not confident in what the API would look like past the binary option.

Unclear if this is a hammer or outer build system problem (lsf) but it certainly is annoying, and running tools manually in lsf does not present this issue.

It seems to depend on when its interrupted

Currently there is a lot of redundancy when you define a component with MMMC.
Several of the files do not change when the corner changes, so we should try to represent that more concisely.

https://github.com/ucb-bar/plsi/blob/20f371c2c4e8607aaa4365a39f3119f41d7cd7e9/src/addons/synthesis/genus/tools/run-synthesis#L21

And shouldn't it be scenario on those json (currently scenerio)?

Moving this from an EAGLE issue to hammer. It would be nice if there were hooks/modules that produced outputs consumable by PCB tools, like a schematic symbol, PCB footprint, bump map, etc.

There is probably some cool API here but I'm not sure what it is yet

Should be a simple glob command in most tools that support placement constraints.

Is it possible to get rid of the X-to-Y steps? They felt very cumbersome to me when I was using hammer and I mostly ended up not using them.

This needs some discussion but wanted to put the idea here as I think it would lead to a smoother experience.

In order to support IP better hammer should be able to merge GDS files.
This means the tech library should also have them.
This can often be done in either the PNR tool or the signoff tool.

API to express some set of modules to retime, perhaps informed from a chisel annotation

I think we should have an API to specify the kind of reports you would like. A simple list of enum values seems like a good first attempt

EDIT: When I ran make syn-verilog with my own core-generator definition based on rules.mk, vars.mk in counter with empty simulation testbench and macro verilog files, it ran nothing.

Make version: 3.81.

Can work around by specifying contents

Its not used in the code path anyways

Right now it just says "Target step xyz does not exist" which can be confusing to users who may think they specified a wrong step for only_step/etc.

Rather than assuming we should overwrite, assume we don't want to overwrite

Currently, a purely combinational design (no clocks) throws an error in PAR (specifically Innovus) because it can't find any clocks. This isn't a showstopper or common use case but would be nice to support in general.

**ERROR: (TCLCMD-917): Cannot find 'clocks' that match '*'

I think the unit tests don't need anything special so could be run on each PR to master

The terminal is left in a weird state and I have to clear or reset it to normalize.

It seems like the only command line arg that doesn't, -p and -e both do.

e.g. hammer-vlsi-latest.log should be a symlink to the latest log file. Apparently riscv-poky does this.

@alonamid

PR forthcoming

If I add a hook I would like to be able to then add more hooks relative to the previously added one?

Create a script that updates your path to include all the tools and such

I'm not sure how difficult it will be to make this tech/tool agnostic

I think there is already a max_threads json hook it just isn't being supplied to the cadence tools

Perhaps it could be caught and give a better message?

Not a huge deal because the first steps are short and don't affect QoR but still would be nice.

For each module you place you should be able to specify where the pins go.

Simple API would just be which side(s) but you some tools give you much more detail than that.

It would be nice to give clocks names other than their port. SDC supports this, but hammer does not.

As discussed with @colinschmidt

Some of the ground work seems there with tech jsons having operating modes but the vlsi abstraction isn't there yet

Should be able to note which modules in verilog/firrtl should be done hierarchically, including nested modules.

Useful for hierarchical to specify custom configs for each layer in the hierarchy

@colinschmidt

Sure all tools have slightly different name for the effort levels but why not standarize that.

One idea is just use numbers and have each tool translate to their given levels.

Running ICC needs ICV (IC validator)

Solution: Update parent repo which should set ICV_VERSION

e.g. a project may want to add analog macros, dynamically/locally-generated SRAMs, etc. Basically a proper API to add new libraries to .tech.json w/o forking/manually editing the tech plugin.

Related to https://bwrcrepo.eecs.berkeley.edu/eagle/eagle-chip/issues/13 (Berkeley-only)

With this all other SDC issues can be lower priority as we can gradually shift from custom chunks to fully supported API

$subject

Solution given was need to make config in src/configs. Could the config not live in src/addons/core-generator or w/e?