# 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
