Run and Stop a Job
An emulator job is submitted in the same manner as a typical Altair Accelerator job,
with a few additional features to deal with the complexity of scheduling jobs on an
emulator. The two main differences are the emulation specific resources that must be
specified and the presence of a hero_adapter
wrapper.
Submit an Emulation Job
nc run -r HERO:<group>_<target> -- hero_adapter <user command>
The resource HERO:<group>_<target>
needs some elaboration.
Each type of emulator defines certain targets (for example, SPAN3 corresponds to a 3
board Palladium job). The resource HERO:<group>_<target>
conjoins all of the emulator targets in a group that define a given target into a
single resource string.
nc run -r HERO:PZ1_SPAN2 -- hero_adapter sleep 20
nc run -r HERO:Z4_SPAN2 -- hero_adapter sleep 20
nc run -r HERO:HAPS100_SPAN1 -- hero_adapter sleep 20
nc cmd vovselect id, status, statusnc, lasttaskername, prop.HERO_EMUL_NAME, prop.HERO_PPLACEMENT from jobs -where resources~HERO
Stop an Emulation Job
Stopping an emulation job requires more care than other jobs so that the user command
has an appropriate chance to respond to the signals. It is important to send the
relevant signals to the appropriate process. In particular, the vw
and hero_adapter
wrapper commands need to be excluded.
nc stop -skiptop 1 -exclude vovsh <jobid...>
The -skiptop 1
and -exclude vovsh
options ensure
the stopping signals are passed through to the user command. For more advanced
options for the stop
subcommand please refer to the Accelerator
documentation. It is likely that the signal sequence will need to be specified along
with delays so that the emulator jobs can be stopped gracefully.
Some EDA tools start child processes that are not terminated when the main tool
process ends which can result in unnecessary process load. The
tasker.childProcessCleanup
configuration parameter (see
Clean up Processes Left Behind by Completed Jobs) can be used to
address this issue.