Hero Emulation Types

Hero emulation is based on the notion of a job type.

For example, a job type could be 2bZ1 to designate a two board job to be placed on a Palladium Z1. Every Hero emulation job has a type which describes the requirements of the job, and affects how the job is scheduled and placed on the emulator. Example of types are: SA8d, SA1b, ICE1b, 2bZ1.

The following table lists the default types available. The types can be added or customized to handle job types that are better suited to a particular customer situation.

Job Type Emulator Description
SA8d XP2 SA job on any half board, that is, Domains b.0-b.7 or b.8-b.15, where b is any board.
SA8d-b12 XP2 A half board SA job that runs on Domains 1.0-1.7, 1.8-1.15, 2.0-2.7 or 2.8-2.15.
SA1b XP2 One board SA job.
SA1b-b12 XP2 One board SA job that runs on either Board 1 or Board 2.
SA3b XP2 Three board SA job.
ICE8d XP2 ICE job that runs on Domains 0.0-0.7.
ICE1b XP2 ICE job that runs on Board 0.
ICE3b XP2 ICE job that runs on Boards 0-2.
1bZ1 Z1 One board job.
2bZ1 Z1 Any two consecutive boards within a cluster.
1b XP2 Any board on any emulator

Emulation Job Types Customization

Note that the customization mechanism is preliminary and is likely to change significantly in the near future.

New emulation types can be added or existing types modified by creating/editing two customization files and redefining four Tcl procedures. There are four parts to the interface:
  • A generic API that describes available types, and information such as resources associated with each type. This part of the API is emulator agnostic. The relevant Tcl routine is HeroPalladium::getJobTypeInfoMap.
  • An emulator specific API that performs some sanity checks on a design (such as ensuring the design can fit into the resources described by the emulation type). The relevant Tcl routine is HeroPalladium::validateJobType.
  • An emulator specific API that computes the available resources on a specific emulator at a given time. An example resource might be "PAL:BOARD_AVAILABLE#2" indicating that two boards are available. Another example would be "PAL:HARDWARE_PXP2" indicating that the emulator should be a Palladium PXP2. The relevant Tcl routine is HeroPalladium::computeResources.
  • An emulator specific API that determines a specific list of domains on which a design can be placed. The relevant Tcl routine is HeroPalladium::getPlacementList.

The four parts must be consistent. To illustrate, the type "2bZ1" has the associated resource string "PAL:CLUSTER_MAX_SPAN#2 AND PAL:HARDWARE_Z1" indicating that it should run on a Z1 emulator and that a cluster with at least two adjacent boards (the first and last boards in a cluster are considered adjacent) is available. If the vovtasker associated with a Z1 emulator advertises these resources, then there must be (at least) two adjacent boards available in a cluster where the design can be placed. In addition, the placement procedure must select a placement consistent with the requested resources.

The most straightforward means of customization is to modify the default implementation to deal with the added/modified types. Care must be taken when customizing the implementation as it affects the behavior of hero_palladium_submit.

API Summary

To customize the generic API, edit a file called $env(VOVDIR)/local/hero/palladium/general.tcl and redefine the Tcl routine HeroPalladium::getJobTypeInfoMap.

The routine HeroPalladium::getJobTypeInfoMap returns a Tcl dictionary whose keys are the emulation types and whose values are another dictionary describing the resources needed by the emulation type. The default implementation is HeroPalladium::getDefaultJobTypeInfoMap.
HeroPalladium::getJobTypeInfoMap

An example of this file can be found in $VOVDIR/scripts/hero/palladium/customization/general.tcl.

To customize the emulator specific API, you can edit a file called $env(VOVDIR)/local/hero/palladium/emulator_EMULATOR_NAME.tcl and redefine the Tcl routines HeroPalladium::validateJobType, HeroPalladium::computeResources and HeroPalladium::getPlacementList.

The routine HeroPalladium::validateJobType returns the integer zero if there is an inconsistency between the job type, the design and the actual placement on the emulator. Otherwise, the integer one is returned. The default implementation is HeroPalladium::defaultValidateJobType. 
HeroPalladium::validateJobType paramDict

paramDict is a dictionary with the following keys
     jobType
     jobTypeInfo
     design
     placement
     boardCount
     domainsPerBoard
jobTypeInfo on paramDict is the result of calling HeroPalladium::getJobTypeInfo,
placement is the list of domains to which the design will be downloaded.
The routine HeroPalladium::computeResources returns a string describing the resources offered by the emulator, for example the string may contain the substrings "PAL:BOARD_AVAILABLE#2" and "PAL:HARDWARE_PXP2". The default implementation is HeroPalladium::defaultComputeResources.
HeroPalladium::computeResources paramDict

The return value is a string describing the resources offered by the emulator.
paramDict is a Tcl dict with the following keys
     emulName
     json
     unavailableDomains
json is a Tcl dictionary representation of the output of "test_server -json".
unavailableDomains is the list of domains that are not available.
Note that the list of unavailable domains may be larger than the test_server
output indicates. This is because of the manner in which Hero implements
reservations.

The routine HeroPalladium::getPlacementList returns a list of domains to which the design will be downloaded. The default implementation is HeroPalladium::defaultGetPlacementList. The HeroPalladium::getPlacementList routine must check that there are sufficient resources available for a valid placement, otherwise it must return an empty list.

An example of this file can be found in $VOVDIR/scripts/hero/palladium/customization/emulator_EMULNAME.tcl.template.

Preemption

If you have activated hero_palladium_preemptd then you can preempt low priority jobs with high priority jobs (i.e. priority 8 or more).

Soft Reservations

The daemon hero_palladium_preemptd also supports soft reservation. Currently soft reservations of a whole emulator for a specified project (variable VOV_JOBPROJ at submission time) are supported.

If an emulator has an active reservation for a certain project, for example, "chipX" and there are no jobs for that project in the queue, then any job can land on that emulator.

If Palladium jobs for project "chipX" are in the queue, and if those jobs are in fact waiting for hardware resources, then the soft reservation will activate, which means:
  • The named emulator in the soft reservation will be actually reserved for "chipX" for a few minutes. This means that any new job on that emulator can only belong to the "chipX" project.
  • In addition, if there are preemptable jobs currently running on that emulator, and those jobs are not in project "chipX", then such jobs will be preempted, specifically those jobs will be killed and resubmitted.