Q:	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, i.e. "IO_port"?
A:	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.
Q:	How to represent memories?
A:	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 subtracks 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 accidently 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.)
Q:	How are the data transfer delays corresponding to the DFG arcs specified?
A:	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.
Q:	Are the PE links half-duplex or full-plex? I tried connecting several PE's to a memory and got errors.
A:	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.
Q:	(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 quanities correctly, can I mimic the bus? Is there a reason other than bus occupancy measures to use lbus.sim?
A:	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.
Q:	When mapping DFG task nodes to specific processors, I am getting the following error:         ERROR: Unknown PE 'PE1'
A:	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: 1 '/PE1' 2 '/PE2' ... ... 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 these errors. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Hint 1: Another way is to run the Scheduler at verbosity level 4 (or above). For Example:           sched test.dfg netinfo -v 4 You then see the following expanded error message: ERROR: Unknown PE 'PE1' The defined PE's were: 1 '/PE1' 2 '/PE2' 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. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Hint 2: 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. For example:           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.)
Q:	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.
A:	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 advertizing the available attibributes of higher level modules so that users of the GUI can see them. See DEFAULT_ATTRIBUTES().
Q:	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.
A:	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 intial amounts left an imbalance.
Q:	Is there a "Dummies guide" for someone who wants to hand modify the routing table?
A:	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. For example: 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 numerials 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.
Q:	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.
A:	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.) Example: The arc between TaskA and TaskB has: P=120 T= 40 C= 40 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, etc.. 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.).
Q:	What's all this I am hearing about a Unified Modeling Language (UML)? Does this relate to the models in CSIM?
A:	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 more than 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. Although a model can be described in a document, we do not normally regard descriptive documents 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 structures in the design of computer programs. The words Unified Model were choosen to describe a diagram format agreed to by Booch, Rumbaugh, et. al.. to recognize consensus among their community. Particulary unfortunate to researchers outside their community, the name now implies much more than intended. For instance, if it really was the true Unified Modeling Language, then we should be able to replace the languages of NASTRAN, SPICE, VHDL, and ACAD, --all with UML to do finite element modeling, circuit modeling, and mechanical modeling respectively. The reality is far different. (See also: Modeling Complex Systems by Nino Boccara, Springer, 2004, 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 static. CSIM supports many similar diagram types as UML, such as state charts, and activity and sequence diagrams. CSIM supports other diagram views such as architecture, data-flow, derrived time-lines, and process diagrams. In summary, UML and CSIM are not orthogonal. CSIM handles some additional things beyond UML. CSIM is absorbing and benefitting from innovations due to UML, is consistent with-, and can accomodate UML practices and associated methodologies. To improve compatiblity and leverage developments, CSIM is developing automatic interfaces to UML tools.

(Questions, Comments, & Suggestions: chein@atl.lmco.com)