# SimBridge Settings Template. This file contains the controls
# for a .sim file to allow complete SimBridge access. Note that
# the inclusion of *.sts is for Simulator custom templates for
# vendor specific settings.

[TEMPLATE=@CONTEXT]
# Board_chip_name refers to the BOARD or CHIP group this is derived
# from (if any), using its name. If the BOARD/CHIP group has more 
# than one name separated by '/' (such as ID/name), any of them may 
# be used. The Board/Chip is used to specify location of memory and
# peripherals/devices. But, note that devices will only be loaded
# into SimBridge iff the device name given in the peripheral section
# of the Board/Chip Advanced_Info matches a Device entry found in
# the simulator executable or device dll.
boardChip_name=LK($GROUP=BOARD/CHIP)\\ Device/Memory for board or chip
# The processor defines a processor model simulation. One must be
# specified for each processor, even if multiple processors in one
# simulator file. If more than one processor in one simulator file,
# the simpos field must be set to indicate the position in the linked
# list. This allows SimBridge to correctly handle stitching. The
# name of this instance is the name the user will see for the
# processor. It is possible to override this name for Device binding
# and inter-processor references using the sim_name field.
{Processor                      \\ Processor simulation by name
  # The Sim_exe field contains the name of the executable containing
  # the simulator for the processor. If more than one Processor entry
  # contains the same sim_exe name with different sim_pos values,
  # the file will be loaded only once and each specified entry will
  # be started. If the same sim_exe name is used with the same sim_pos
  # value, a new simulator processor will be started.
  sim_exe=F(*.exe,*rex)         \\ name of file containing simulator
  # The sim_pos indicates the position in the sim_exe file's SIM_ABS
  # list (if any). If it is not 0, then the simulator at that position
  # in the list will be used. If it is 0, but the sim_type is named, 
  # then a matching SIM_ABS will be looked for if not at 0.
  sim_pos=V0                    \\ Position in SIM_ABS list if more than one per file
  # The sim_type field serves two purposes: it validates that the
  # entry matches the simulator's definition of the processor, and
  # it can be used to locate the specified processor in a SIM_ABS
  # list.
  sim_type=S                    \\ optional 3 character name to verify match of \
                                   processor type (such as ARM, OAK, etc)
  # The simulator name is used for internal matching of the processor.
  # If not specified, the instance name will be used. The instance name's
  # primary purpose is a name tag in the Connection Manager of RVDEBUG. The
  # sim_name is used for matching names for glue between devices and
  # simulators.
  sim_name=S                    \\ Overrides instance name for internal references
  # The description is used to show a description in the Connection Manager
  # of RVDEBUG.
  description=S                 \\ Description of Simulator (overrides sim_exe name extract).
  # The Simulator_info block allows specifying or overriding normal
  # settings. The common controls are to mimic hardware wiring of
  # chips in a multi-processor environment (such as IDs, clock speed,
  # strap pins, etc).
  {.Simulator_info              \\ Special data for the simulator
    # An ID is used by some processors to know its ID in a set of
    # processors. This is often used for link ports, time-division-multiplexed
    # serial ports, DMA channels, etc. The meaning is up to the
    # simulator and it may ignore this field.
    id=V                        \\ Allows assigning an "ID" to the simulator
    # The clock speed allows defining a specific and separate clock
    # speed for each simulator. SimBridge uses this to compare the
    # speeds of different processors to match cycle counts for
    # synchronization and other uses. The clock speed is expressed
    # in KHz so 2.1MHz is 2100.
    clock=V                     \\ Allows assigning the clock speed in KHz
    # The Msg field allows communicating a message to the simulator
    # which may have a specific meaning. This meaning is completely
    # up to the simulator.
    msg=S                       \\ Allows providing a message to the simulator
    # Pin_assigns allow pre-setting pins value (strap pins). This can
    # be used to set modes, internal vs. external vectors, etc. The
    # format is name=value and the meaning and use is up to the
    # simulator.
    pin_assign=LS               \\ Allows pre-assigning pins (strap or reset states)
    # Start_state determines if the simulator should be started in a
    # normal ready-to-run state, idled, or held in reset. This can only
    # be used fully if supported by the simulator. If idle/reset not 
    # supported by the simulator, it will be faked by the SimBridge 
    # by not allowing the simulator to execute.
    start_state=K(normal,idle,reset)
  }
=DEVICE
  # The dev_dll field(s) indicate a DLL containing one or more devices.
  dev_dll=LF(*.dll)             \\ Name of device DLLs containing device models.
  # Dev_init is used to control what devices are initialized by 
  # SimBridge. All indicates that all devices found in sim_exe and
  # dev_dll files are to be initialized. BoardChip will only 
  # initialize those that match peripheral's named in the BoardChip
  # Advanced_Info. Specified will only initalize those named in 
  # Device fields in this group.
  dev_init=K(All,BoardChip,Specified) \\ Which devices to Load \
                                \K Load all devices in sim_exe and dev_dll files, \
                                   Load all devices specified and in board/chip, \
                                   Load only those devices specified using Device fields
  # Image load allows for pre-loading files into the simulator on
  # initialize. Note that this only works if the file can be loaded
  # into the specific simulator. Also note that some simulators
  # are hard-built for a specific file so loading is not allowed at
  # all.
  image_load=LF                 \\ Application files to load on start
  # The Device instance is used to name a specific device either to
  # force it to be loaded (based on setting of dev_init) and/or to
  # specify an address for it to be loaded to. For models that allow
  # multiple instances of themselves, this mechanism is needed to
  # force each one to exist. The device instance name must match the
  # DEV_ABS model name unless dev_name is used. When more than one
  # instance of the same device is used, it should have a unique name
  # (for error reporting) and so the dev_name field must be used.
  {Device                       \\ Device to use in simulation.
    # The Device_info block allows specifying or overriding normal
    # settings. The common controls are to mimic hardware wiring of
    # chips (such as IDs, strap pins, etc).
    {.Device_info               \\ Special data for the device model
      # An ID is used by some devices to know its ID in a set of
      # processors/devices. This is often used for link ports, 
      # time-division-multiplexed serial ports, DMA channels, etc. 
      # The meaning is up to the device and it may ignore this field.
      id=V                      \\ Allows assigning an "ID" to the device
      # The Msg field allows communicating a message to the device
      # which may have a specific meaning. This meaning is completely
      # up to the device model.
      msg=S                     \\ Allows providing a message to the device
      # Pin_assigns allow pre-setting pins value (strap pins). This can
      # be used to set modes, level vs. edge firing, etc. The
      # format is name=value and the meaning and use is up to the
      # device mode.
      pin_assign=LS             \\ Allows pre-assigning pins (strap or reset states)
    }
    # The dev_name is the name used in the DEV_ABS name field. This
    # must be used to locate the correct device, or the Device
    # instance name will be used.
    dev_name=S                  \\ Device Name selector (must match DEV_ABS)
    # The base_addr allows the device to be located in the memory of
    # the simulator (assuming the device allows this and needs it).
    # Note that this information can come from the BoardChip Peripherals
    # address as well. If both exist, they will be compared.
    base_addr=V                 \\ Optional device base address
    base_page=V                 \\ Optional device base page for address
    # The device may use a file containing data to supply it. It will
    # have a default file, but this allows naming the exact file. It
    # is only usable if the device supports it. The format of the file
    # is up to the device.
    in_file=F                   \\ Optional input file
    # The device may write output to a file. It will have a default 
    # file, but this allows naming the exact file. It is only usable 
    # if the device supports it. The format of the file is up to the 
    # device. The same file should not be used for multiple devices
    # as they will not be shared properly.
    out_file=F                  \\ Optional output file
    # The glue_to_dev instances are used to glue (attach) a device
    # to other devices in the system. This device will be glued to
    # the local simulator, but this allows naming other devices to 
    # interact with. Note that the device must support this and 
    # must support the number of glues you instantiate. An example 
    # of glue for a device would be a memory interface being glued 
    # to multiple memories and peripherals. Another example would be
    # link port or serial port naming another port on another
    # simulator. The sim_name and context allow forcing the search
    # to a specific simulator and/or context. The default is to look
    # in the local simulator first and then in other simulators in
    # the local context only.
    {Glue_to_dev                \\ Device to attach to
      id=V                      \\ Allows assigning an ID to the remote device connection
      msg=LS                    \\ Messages to device (private meaning)
      sim_name=S                \\ Simulator of other device
      context=S                 \\ Context of other device
    }
    # The glue_to_sim instances are used to glue (attach) a device
    # to other simulators in the system. This device will be glued to
    # the local simulator, but this allows naming other simulators to 
    # interact with. Note that the device must support this and 
    # must support the number of glues you instantiate. Simulator
    # glue differs from device glue in that simulator_glue allows
    # the device to watch addresses and pins directly. Device glue
    # allows interactions with devices attached to this or other
    # simulators. So, you must know the model this device used.
    # An example of glue for a device would be a mailbox system
    # shared between multiple processors. The context field allows
    # forcing the search to a speicific context. The default is to 
    # look in the local context only.
    {Glue_to_sim                \\ Simulator to attach to
      id=V                      \\ Allows assigning an ID to the remote device connection
      msg=LS                    \\ Messages to device (private meaning)
      # The base_addr allows the device to be located in the memory of
      # the remote simulator (assuming the device allows this and needs it).
      base_addr=V               \\ Optional remote device base address
      base_page=V               \\ Optional remote device base page for address
      context=S                 \\ Context of other simulator
    }
  }
!DEVICE
}
[TEMPLATE=@SIMBRIDGE]           \\ Master for SimBridge control
debug_init=K(off,on,no_connect) \\ Debug trace control for init \
                                \K No debug tracing, \
                                   Debug tracing but full setup, \
                                   Debug tracing but do not connect
fail=K(stop,prompt,ignore)      \\ How to handle failures \
                                \K Stop the load and quit, \
                                   Ask for each failure whether to continue, \
                                   Ignore and continue
sim_state=K(stop,run)           \\ Controls initialized state \
                                \K Start all in stopped (debug) state, \
                                   Start with simulators running
?DEVICE