VLSI flow simulation timing config error

[YiKangOY]

Background Work

• Yes, I searched the mailing list
• Yes, I searched prior issues
• Yes, I searched the documentation

Chipyard Version and Hash

Release: 1.9.0
Hash: 7475bfb

OS Setup

Ex: Output of uname -a + lsb_release -a + printenv + conda list
Linux localhost.localdomain 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 GNU/Linux

LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.9.2009 (Core)
Release: 7.9.2009
Codename: Core

Other Setup

Ex: Prior steps taken / Documentation Followed / etc...

Current Behavior

I am runnning VLSI flow with timing information after synthesis. The command is make sim-syn-timing-debug CONFIG=SmallBoomConfig BINARY=$RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv32ui-p-simple, but it raised the following error:

Traceback (most recent call last):
File "/path-to-chipyard/chipyard-1.9.0/vlsi/./example-vlsi", line 61, in
ExampleDriver().main()
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 1724, in main
sys.exit(self.run_main_parsed(vars(parser.parse_args(args))))
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 1628, in run_main_parsed
output_config = action_func(driver, errors.append) # type: Optional[dict]
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/cli_driver.py", line 686, in action
success, output = driver.run_sim(
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/driver.py", line 1460, in run_sim
run_succeeded = self.sim_tool.run(hooks_to_use)
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/hammer_tool.py", line 114, in run
if not self.run_steps(self.steps, hook_actions):
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/hammer_tool.py", line 623, in run_steps
func_out = step.func(self) # type: bool
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/hammer_tool.py", line 667, in wrapper
return func.func(x) # type: ignore # no type stub for builtin func
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/sim/vcs/init.py", line 192, in run_vcs
if self.get_setting("sim.inputs.timing_annotated"):
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/vlsi/hammer_tool.py", line 898, in get_setting
return self._database.get_setting(key, nullvalue)
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/config/config_src.py", line 763, in get_setting
self.check_setting(key)
File "/path-to-chipyard/chipyard-1.9.0/.conda-env/lib/python3.10/site-packages/hammer/config/config_src.py", line 873, in check_setting
raise TypeError(f"Expected primary type {exp_value_type.primary.value} for {key}, got type {value_type_primary}")
TypeError: Expected primary type bool for sim.inputs.timing_annotated, got type str
make: *** [/path-to-chipyard/chipyard-1.9.0/vlsi/build/chipyard.TestHarness.SmallBoomConfig-ChipTop/hammer.d:79: /path-to-chipyard/chipyard-1.9.0/vlsi/build/chipyard.TestHarness.SmallBoomConfig-ChipTop/sim-syn-rundir/sim-output-full.json] Error 1

The contents in /path-to-chipyard/chipyard-1.9.0/vlsi/build/chipyard.TestHarness.SmallBoomConfig-ChipTop/sim-timing-inputs.yml are as follows:
sim.inputs:
defines: ['NTC']
defines_meta: 'append'
timing_annotated: 'true'

According to the hammer error report, I guess the variable timing_annotated should be a boolean variable, so I changed the line 78 in sim.mk from echo " timing_annotated: 'true'" >> $@ to echo " timing_annotated: True" >> $@ and there is no error.

Can you check if this is an error? Otherwise I guess I am having other problems in my environment.

Expected Behavior

It sould execute simulation.

Other Information

No response

[harrisonliew]

timing_annotated: 'true' in YAML encodes the string "true". Instead, your fix correctly encodes the boolean True. Thanks for the catch - I will fix it in the next Hammer bump PR.