FAQ - Starting-Out Questions
(Frequently Asked Starting-Out Questions)
I successfully built and ran demo_examples/demo0/test.sim.
Now I am attempting to build the Student Example 1: Pitcher/Catcher
model, but I am getting warnings/errors of the following kind:
Warning_47: Port 'io' not found in topology for Pitcher (of device type 'A1')
Warning_47: Port 'ioport' not found in topology for Catcher (of device type 'A1')
ERROR_46: Out-Port 'IO_port' not found in topology for device type 'A1'.
Executing: sim.exe -net_extract
sh: ./sim.exe: No such file or directory
Are the 'Link/Arc' names constrained by the 'PORT_LIST' exported by the device,
The demo_examples/demo0/test.sim is a complete simulation
model (ie. already drawn for you). All you have to do is build (compile)
it. In contrast, the "Student Example" is a partial model (behavior-block only)
which requires you to correctly draw the system model (define the system structure)
by following the steps of making
the diagram and connecting the ports. It looks from your messages that you
may have not connected the link to the ports correctly, or perhaps not set the
port names accordingly.
What the error message is saying is that csim notices the model uses a
port called "IO_port", (it does a SEND("IO_port",...), but in your diagram
(topology), such a port was not connected. This is a fundamental error.
The warning messages, indicate the link was connected
to Pitcher on a port called "ioport" and to the Catcher on a port called "io".
Remember that Pitcher and Catcher are both the same kind of device (A1).
CSIM's preprocessor looks for consistency. It noticed that one instance of
an A1 had a port called "ioport", but the other instance of A1 did not. So it
flagged this with a warning. It assumed you must have forgotten to connect port
"ioport" on the other instance. Same sort of thing for the "io" port.
In other words, a given kind of device will have a set of port-names, and
every instance should have those very same port-names connected to something (or nulled).
Otherwise, you will get these warnings.
The "PORT_LIST" does not actually constrain the port-names.
Rather, it assists the GUI in listing the available ports under the properties
dialog. The only thing constraining the port-names is what the models use
in their SEND and RECEIVE statements, as well as consistency in your diagrams.
How to represent memories?
The generic_pe is often used to represent memories by using
a subset of its features, namely for sourcing (launching)
data-transfers, and sinking (absorbing) data-transfers.
The generic_pe model is more than just a CPU in that it
contains a notion of a local memory. So in this case, we
use it mostly for its memory-model, and ignore the CPU.
One advantage in using the generic_pe for these operations
is that it has a simple model for tracking memory usage.
It keeps track of peak and mean allocated bytes, as well
as produces a plot of allocation-count versus time.
Sourcing data helps account for bus traffic and it
satisfies the transfer-delays for modeling the timing of
when a consumer can get and use the data.
You may ask, why bother "sinking" messages?
Truth is, you really would not have to sink them,
except you get two advantages:
- Sinking (or receiving) data increases the allocation count.
It helps track memory usage.
(ex. Someone sends 10-kB to a memory, so the amount
stored there should increase by 10-kB.
Caution: This model is simple. When someone
reads 10-kB (memory sends 10-kB) it subtracts
10-kB from allocation count, assuming the
space can now be reallocated after being read.
- Helps realize (enforce) true data dependencies.
For example, if you are not careful about accounting
for data received, then your model could accidentally
imply that data is read (sent) from a memory before
it was ever written. (This would be bad.)
However, because the generic_pe is driven by a sequential
(pseudo-code) program, it guarantees that the proper
amount of the correct data item is received before
it can be sent to (read-by) anyone else.
(I.E. Just for book-keeping.)
How are the data transfer delays corresponding to
the DFG arcs specified?
The data transfer rate and
link characteristics are properties of the "hardware" architecture
diagram; not the "software" DFG diagram. Both affect the
transfer delay of course, because the P:T:C properties of
the DFG arcs set the amount of data transferred.
TranferDelay = DataQuantity / Rate
Rate is defined by hardware architecture.
DataQuantity is defined by DFG arc.
Are the PE links half-duplex or full-plex?
I tried connecting several PE's to a memory and got errors.
The PE io-port can be either full or half duplex.
However, you will need to connect your PE's, memories, and NIC modules
through a bus or switch model, such as lbus.sim.
If you use the bus model, then it becomes half-duplex, consistent with most buses.
In CSIM, all links must be point-to-point. A PE has one port which
can be connected to only one other device.
If there were only a PE and a memory, you could connect
them together directly. But when more than two devices
need connecting, you must use some kind of intermediate
switch or bus.
See next question.
(Related to previous question)
How much of the bus activity should/can be modeled in the memory or PE model?
If I set memory tasks compute times to be non-zero and the P:T:C quantities
correctly, can I mimic the bus?
Is there a reason other than bus occupancy measures to use lbus.sim?
The bus aspects should be modeled by the bus model; not the memory device itself.
For those familiar with VHDL, the concept of using
the bus model is related to VHDL's "resolution" function.
The bus model resolves contention, controls transfer rates,
and records utilization information. It also handles the
routing of the data messages. In other words, it sends
each message to its correct recipient.
Trying to address bus aspects in the DFG goes against the paradigm
of separating the aspects of hardware/software specification.
I should mention that the hardware diagram and
the DFG (software) can be considered to be two related
but distinct views of your system. Some people have
even used the term "universes", in the mathematical
sense, as in two parallel-universes. Some information
can be translated from one universe to the other;
some cannot. There are a few areas where the "universes"
converge; namely the mapping of tasks to physical units.
When mapping DFG task nodes to specific processors, I am
getting the following error:
ERROR: Unknown PE 'PE1'
This is a common pitfall.
One thing to know is that the netinfo file is a very
useful thing to look at. File netinfo has three sections.
The first section is the list of device names.
(There are other interesting things to point out, but
they have nothing to do with your immediate problem,
such as: Netinfo's first section also assigns a logical-ID
number cross-reference for each device instance, which
is useful from time to time. For example, it controls
vertical position on time-line plots.
The second section is the net-list. The third section
shows class membership.
Everything downstream, such as the Scheduler and Router
consult netinfo, so you can do some things by modifying
netinfo, such as altering vertical plotting
positions. But don't worry about any of this now.
If you look at that first section of netinfo, you will
see that your device names are:
... Which brings up the point, similar to hierarchical file names,
all device-names begin with a leading "/" (slash), representing
the root (top-level or outermost) module.
So when you look at your error message:
ERROR: Unknown PE 'PE1'
And you look at netinfo, you see the closest name was
actually '/PE1'. Therefore, if you put slashes
in front of your mapping names, you will remove most of
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Hint 1: Another way is to run the Scheduler at verbosity
level 4 (or above).
sched test.dfg netinfo -v 4
You then see the following expanded error message:
ERROR: Unknown PE 'PE1'
The defined PE's were:
This shows you what it was trying to match to. And you can see the proper spelling.
Getting the names to match up is a fairly normal part
of the debugging process.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sometimes it gets tedious to use the formal device-names
in the mapping lists. (It is difficult to remember exact
spellings, especially with complex hierarchies, etc..)
So many users assign their own short nick-names for PE's.
You can do this under the GUI's Edit/Macro menu.
PE1 = /chassis1/module_A/PE_1
Then you can just use 'PE1' in the mapping assignments.
(This would be an alternate way the fix your errors, and
to avoid similar ones in the future.)
It would be nice to set attributes from the top level of the hardware
architecture - such as generic_pe_infinite_mem as well as other variables, attributes, and parameters.
You can set attributes at any level.
You can set attributes of the top-level graph, globally, under the Edit / Macro or
Edit / Variables menu of the GUI. See
Global Graph Attributes.
There are also special keywords for modelers to
support this further by advertising the available attributes of higher level modules
so that users of the GUI can see them.
When running the Scheduler, I get a diagnostic message
indicating that some extra data was left on some arcs.
What does this mean? I captured the messages to a log.
From the debug log, I see that several arcs were left with
some data on them, while not all their sibling arcs had
enough data to reach firing threshold (to consume the data).
Everything seems to make sense with what the messages say.
If you do not expect to have such left over data, then there
might be some sort of imbalance or deadlock in your graph.
I'll explain the output so you understand the reports.
Take the first one:
Some input arcs of node 'Displ/Player1/Score' have non-zero
amount of data at EXIT-time.
Node could not fire because all threshold(s) were not reached.
Input Arc Status:
1 bytes, threshold=1
(Arc from Displ/Player1/Counter to Displ/Player1/Score)
(Totals: produced=1, consumed=1)
1 bytes, threshold=2
(Arc from Displ/Player1/Trig to Displ/Player1/Score)
(Totals: produced=1, consumed=1)
This says that both input arcs have one (1) byte (or unit) of
data on them, but the second arc needs two (2) for the node to
fire. It also shows that one production occurred on each, and
that one consumption occurred.
There are a variety of ways to end up in this state.
For example, suppose the initial amounts were zero.
I'll use the shorthand notation below:
Arc1: P=2 T=1 C=1 I=0
Arc2: P=2 T=2 C=1 I=0
This says that 2 data units were produced on each arc, but
only one was consumed, leaving one on each. But the second
needs two to fire.
Another way, due to non-zero initial amounts:
Arc1: P=1 T=1 C=1 I=1
Arc2: P=2 T=2 C=2 I=1
In this case, the produced amounts were consumed, but the
non-zero initial amounts left an imbalance.
Is there a "Dummies guide" for someone who wants to hand modify the
The routing table format is:
altpath# sourcePE - destPE : port0 port1 ... ;
Where "altpath#" is the instance of the path between
devices "sourcePE" and "destinationPE". For example,
if there were two alternate paths between devices 85 and
92, then there would be two lines in the routing table
beginning like this:
0 85 - 92 : ... ;
1 85 - 92 : ... ;
The lines can occur anywhere, in any order.
The ports to go through are in order.
0 85 - 92 : 5 11 2 ;
Says, the first way to get from device-85 to device-92 is
to go out port "5", then go out port "11", then go out port "2",
then you should be at the destination (92).
Note that only ports ending in numerals are in the routing table.
Example: "port11" is 11, "p4" is 4, "in_9" is 9, etc..
While port "out" or "in" do not show up at all.
See also the Router document.
I understand the PTC effect on 'Node-Firings' and why the large
numbers extend the scheduling time, but how are the
Arc-transfers related that they can be so much more numerous?
The scheduler says it has:
Total Node-Firings: 10233
Total Arc-transfers: 30808822
and off it goes for a long time.
Good question. Turns out that due to the potential
to distribute data to the down-stream task, or to gather
data from a distributed upstream task, or a mixture
thereof, it is necessary for the Scheduler to track
the lowest-common-denominator (LCD) of PTC quantities.
You may not have encountered it, but it is possible
for a task, say TaskB, to execute on one CPU, then another,
and another, etc., on each subsequent firing.
(By naming a group or sequence of CPU's in the task's mapping list.)
The arc between TaskA and TaskB has:
TaskB is mapped to PE1, PE2, PE3.
When TaskA completes, it produces 120 "data-units",
which is enough to start three instances of TaskB,
because P/T = 120/40 = 3.
However, the Scheduler must be careful to divide the
120 units into three, by sending 40 to PE1, 40 to PE2,
So you see that the Scheduler must track more than just
"firing" events, but must also track the "LCD" of arc
messages. Simplistically, if there are n=firings and m=LCD,
then the number of messages generated is O( n*m ).
If you have very lopsided data quantities, this could
generate a lot of messages for each firing. (ex. P=90000, T=1)
One hint - you'll noticed I used the term "data-units"
above. Nothing says the arc quantities need be Bytes.
Sometimes it helps to use more granular units.
You should understand what granularity you need, and why.
However, remember to adjust bus rates accordingly
(ie. might not be bytes/sec anymore, units/sec, etc.).
What's all this I am hearing about a Unified Modeling Language (UML)?
Does this relate to the models in CSIM?
Good question. The word model means different
things to different communities. Although there is some overlap,
there are also important distinctions in meanings, emphasis, and usage.
Generally, our definition of model contains meanings beyond UML's concept.
A UML model is a descriptive diagram or document containing information usually about software objects.
Although CSIM models also describe design-objects, CSIM models can be executed,
which enables analysis, experimentation, and interaction with described design objects as if they exist.
CSIM tends to model objects which may be realized in hardware or software, or which are processes and tasks
that could be performed by humans, computers, or even mechanical machines - depending on the applications.
Although a model can be described in a document, we do not normally regard descriptive diagrams and documents
as being equivalent to executable behavioral models.
The use of the word model in UML arises from a community within the field of computer science
concerned with the description of data and structures in the design of computer programs.
The words Unified Model were chosen to describe a diagram format
agreed to by Booch, Rumbaugh, et. al.. to recognize consensus among their community.
Particularly unfortunate to researchers outside their community, the name now implies much more
For instance, if there truly was a single Unified
Modeling Language, then we should be able to replace the modeling languages of NASTRAN, SPICE, VHDL, and ACAD,
--all with this "UML" to do finite element materials modeling, circuit modeling, and mechanical modeling respectively.
The reality is far different. (See also: Modeling Complex Systems by Nino Boccara, Springer, ISBN: 0-387-40462-7.)
Unlike UML diagrams, CSIM models can contain rich functional, behavioral, and temporal (timing/performance)
information. Like UML, CSIM models can show relationships and attributes of objects, as
well as hierarchical breakdowns. CSIM encompasses, but also applies to more than just software design.
Like UML, CSIM supports both visual and automatic analysis.
Unlike UML diagrams, other systems and people can interact with, -and test-, CSIM models.
CSIM models are active and dynamic. UML diagrams are basically static. CSIM supports some similar
diagram types as UML, such as state diagrams, activity, and sequence diagrams.
CSIM supports other diagram views such as architecture, data-flow, derived time-lines, and process diagrams.
In summary, UML and CSIM are not orthogonal. CSIM focuses on some additional things beyond UML.
CSIM is absorbing and benefiting from innovations due to UML, is consistent with-,
and can accommodate UML practices and associated methodologies. To improve compatibility and leverage developments,
CSIM is developing automatic interfaces to UML tools.
Does CSIM provide a mechanism for sending broadcast messages (from a sender) and subscribing to broadcast messages (on receiver side)?
One method is to use the Named-Synchron approach. This allows your sender(s) and receiver(s) to
post or subscribe to "messages" by a channel-name. The receivers do not need to poll for the messages,
but are awoken whenever a new message is posted. For further information, see Object Activation Examples.
(Questions, Comments, & Suggestions: firstname.lastname@example.org)