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

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

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 '*'

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

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

Does hammer still support them?

Its not used in the code path anyways

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.

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

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)

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

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

Specify which clocks are asynchronous, etc to each other.

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.

As discussed with @colinschmidt

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

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)?

Can work around by specifying contents

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

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.

$subject

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.

PR forthcoming

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

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

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.

Thanks to @stevobailey

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

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

Perhaps it could be caught and give a better message?

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.

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.

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

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

@alonamid

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

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

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.

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

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

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.

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

Running ICC needs ICV (IC validator)

Solution: Update parent repo which should set ICV_VERSION

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

It seems to depend on when its interrupted

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.

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.

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

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

@colinschmidt

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