MC-3020 allows the user to select a package of components to be used when generating the code for the model. Such a package is called a "system configuration".

A model may contain more components than are needed/required for a particular working configuration of a system. Often a model will include additional components used for testing. A user may want multiple versions of components.

To assemble a system configuration in BridgePoint, the user builds a component diagram in a package from component references and wires them together as desired. Multiple system configurations packages may exist. Each configuration can be different and use only a subset of the components defined in the model.

When a component package is marked as the system configuration, code will be generated for components contained in this package and referred to from this package. Components not contained in this package and not referred to from this package will be excluded from code generation.

To mark a package as containing the system configuration:

Where the input parameter(s) are:

.invoke MarkSystemConfigurationPackage( "system1" )
.invoke MarkSystemConfigurationPackage( "system2" )
        

MC-3020 provides for tasking/threading using the capabilities of the target operating system (OS) or real-time operating system (RTOS). An example of an RTOS is the Nucleus PLUS real-time operating system.

To cause MC-3020 to generate multi-tasking/threading code, invoke the following marking function. Pass it arguments that specify the type of multi-tasking environment and whether or not to serialize all action processing (across all tasks).

To enable tasking in the generated system:

Where the input parameters are:

.invoke EnableTasking( "Nucleus", "", 4 )
.invoke EnableTasking( "POSIX", "serialize", 2 )
.invoke EnableTasking( "Windows", "", 3 )
.invoke EnableTasking( "SystemC", "", 1 )
        

Some flavors of tasking/threading allow for differing execution priorities of tasks or threads. MC-3020 allows the priorities of tasks to be set through marking. In systems that support explicit prioritization of tasks, each task (of the number specified in EnableTasking) can have a priority assigned. Use the following marking function to set the priority for each task.

To specify the priorities of tasks/threads:

Where the input parameters are:

.invoke SetTaskPriority( 0, "100" )
.invoke SetTaskPriority( 3, "high" )
        

MC-3020 tries to use relatively safe methods of manipulating strings. The ``n'' library functions are used (strncpy, strncpy, strncat) rather than their more dangerous (as regards buffer overruns) counterparts.

To specify the maximum length of a string in the system:

Where the input parameters are:

.invoke TagMaximumStringLength( 16 )
        

Sets of instances are collected for various AL operations. Relationships with multiplicity MANY require set container mechanisms at the implementation level to manage the collection of related instances. The maximum number of instances allowed in such collections can be controlled with a mark.

To specify the maximum ``relationship extent'' size in the system:

Where the input parameters are:

.invoke TagMaximumRelationshipExtentSize( 8 )
        

Another operation requiring set manipulation is a selection (SELECT MANY) that may result in a collection of multiple instances.

To specify the maximum ``selections extent'' size in the system:

Where the input parameters are:

.invoke TagMaximumSelectionExtentSize( 12 )
        

Collections are maintained with a mechanism of one type or another. With this mark, the type desired for a particular translation can be specified. The default is singly linked list container nodes. Doubly linked list containers can be selected as flavor 20. Doubly linked lists allow for faster deletion of instances in exchange for an additional pointer size (for ``prev'') per container in the system.

To specify the flavor of the collection nodes:

Where the input parameters are:

.invoke TagCollectionsFlavor( 20 )
        

MC-3020 attempts to dynamically calculate reasonable and safe values for queue depths within the event generation and delivery mechanism. However, for optimization purposes the user may wish to override these values.

To override the compiler calculated maximum queue depth for the self directed event queue:

Where the input parameters are:

.invoke TagMaximumSelfDirectedEvents( 3 )
        

To override the compiler calculated maximum queue depth for the instance directed event queue:

Where the input parameters are:

.invoke TagMaximumNonSelfDirectedEvents( 5 )
        

A mark is provided so the system analyst can direct the model compiler to increase or decrease the timer queue used to manage multiple pending xtUML timers (delayed events). To override the compiler calculated queue depth for pending xtUML timers:

Where the input parameters are:

.invoke TagMaximumPendingOoaTimers( 6 )
        

Simulated Time in MC-3020 implements a form of discrete event simulation. In simulated time mode, no external clock is read. The application runs as fast as the architecture allows. The time base is derived from timers used to cause functional delays in the modeled application.

SystemC and BridgePoint Verifier both support modes where time is "simulated". In these environments, "wall clock" is not used. The timers in the system advance the system time in sequence of expiration. This is convenient for very fast (short-running) and for very slow (long-running) applications.

To switch from the default wall clock time base to simulated time:

.invoke MarkSimulatedTime()
        

Use this mark to expand or reduce the depth of the queue used to interleave ``asynchronous'' bridge operations between state actions. The default will be a system divined value that should be relatively safe in most cases.

To hard-code the depth of the interleaved bridges queue:

Where the input parameters are:

.invoke TagMaximumInterleavedBridges( 4 )
        

Use this mark to define how many bytes of argument data come in across an interleaved bridge operation. The default is 8.

To hard-code the width of the interleaved bridge argument path:

Where the input parameters are:

.invoke TagInterleavedBridgeDataSize( 2 )
        

This mark is used to specify the maximum number of instances and links that can be queued waiting to be flushed to non-volatile storage (NVS). As instances and links become "dirty" they get queued to NVS. When PERSIST::Commit is called these queues are flushed.

To change the default depth (128) to something different:

Where the argument:

.invoke MarkPersistenceCacheDepth( 16, 32 )

.invoke MarkPersistenceCacheDepth( 1000, 500 )

By default, MC-3020 statically allocates instance data and all mechanistic collection containers. This is great for many deeply embedded applications. However, some applications require the flexibility of dynamically allocated storage. In such an application, the number of instances of elements from the xtUML model file is not predictable. Here, the application needs to be able to allocate more memory when the statically allocated memory runs out.

To turn on and use dynamic memory allocation:

Where the argument:

.invoke TagDynamicMemoryAllocationOn( 2 );

When dynamic memory allocation is marked off, system user callout functions are called when a request is made to allocate resources beyond what is statically available.

State Save is a feature that captures information present in the running system that may be useful for analysis and debugging purposes. Upon a state save trigger, information is collected into a buffer of a size specified through marking (this mark).

From the application model, state saves are controlled through bridges on an external entity named 'state save' (with key letters 'SS'). A default version of this external entity is supplied with the model compiler. It is expected that users will modify the state save external entity realized code.

To enable state save capability and specify the size of the buffer:

Where the argument:

.invoke MarkStateSave( 1024 );