Frequently Asked Questions

Q: What descriptive paradigm is supported? State diagrams?
A: CSIM accommodates all conventional descriptive paradigms. State diagrams are one of the most basic ways that CSIM can be used to describe functionality and behavior.

Graphical paradigms such as Object Diagrams, structural decompositions, classic flow-charts, bubble diagrams, data-flow-graphs, Mealy and Moore descriptions, and process diagrams, as well concurrent text-based threads, are just some of the paradigms that can be used.

Unlike most modeling tools which force a specific paradigm, or limit you to a distinct choice between two or three, CSIM was designed to allow much flexibility and supports an arbitrary number of descriptive modes. It is just a matter of your model set. Your building-blocks for descriptions and the rules they follow determine the paradigm. Libraries for the conventional modes are available. If you have a new paradigm, you can easily implement and use it in CSIM.
Q: How to pronounce CSIM?
A: "See-Sim"
Q: How to get more information?
A: Contact: admin@csim.com.
Q: What about support?
A: CSIM provides a modeling service in a variety of tools and environments. It helps users quickly and painlessly configure initial models of their system for rapid start-up. Users further customize the models to investigate specific design issues. CSIM provides low-level support when needed to answer questions and to help maintain the models or tools. Often, little support is needed after initial introduction.
Q: What computer platforms can be supported?
A: Versions of CSIM are available for: Linux, Microsoft Windows, and freeBSD. Additionally, a platform independent version based on the free Oracle VirtualBox virtual machine is available for supporting Mac OSx, Sun Solaris, and other platforms.
Q: What are the requirements to run CSIM on a workstation and on a server?
Are there different versions for a workstation versus a server?
A: CSIM requires about 50-MB of disk space for the tools and model libraries. Documentation can be accessed via the web or on CD-Rom, but a snap-shot of the documentation can also be copied to your hard-drive requiring about 650-MB. A PC or workstation with 500-MB RAM or more is recommended. The basic CSIM distribution comes with executables supporting:
  - PC's running Linux (ex. Redhat Fedora/Enterprise, Ubuntu, etc.),
  - PC's running Microsoft Windows XP, 7 & 8,
  - PC's running FreeBSD,
  - Mac PC's running Mac OSx
Other versions can be made on request.

The CSIM install and setup scripts automatically detect your platform type, and use the right executables.

The same version of CSIM supports both Workstations and Servers. In a shared server environment, multiple users can access a common installation of the CSIM tools and model libraries. Each can work on their project files in separate directories.
Q: What about training?
A: A one-day or two-day tutorial course is recommended for productive usage of the tools.

The tutorial is presented periodically, or it can be arranged. See CSIM Introductory Course.
On-line training is also being prepared.
Q: When and why was CSIM developed?

A: The origins of CSIM are traced back to the early 80's when the core discrete event engine was developed for system-architecture simulation. The basic paradigm for hardware/software co-design and co-simulation was also implemented at that time. The paradigm is based on the processor-memory-switch and data-flow-graph concepts. Over the years, the CSIM tools have been continually enhanced, ported to newer platforms, re-written, and enhanced further as a myriad of various projects demanded.

In the interim, our community has used and evaluated several commercial performance simulation tools on several projects. However, the challenges presented by the type of systems that are characteristic of our work in large system design led to much frustration from limitations in the available products. We often found ourselves resorting to the CSIM tools merely as the quickest means to an end in solving our larger engineering tasks. It has often been a most efficient means.

The CSIM capabilities have been incrementally developed and maintained through use on many projects. Significant value has accrued in the models that have been developed and and in their calibration to actual hardware systems that were constructed or obtained. Recently the need for, and value of the CSIM tools, has become more recognized and the tools have undergone significantly more rapid improvement.
Q: What kind of systems can be described? Can you interface to other tools?

A: Anything that can be called or done from C or C++ can be done from a CSIM model. See Language discussion.. Additionally, CSIM supports the DMSO standard HLA interface, so you can interface to the growing number of simulations which also support the standard.
Q: How accurate are the simulations?
A: We routinely observe performance model results that match within a few percent to actual measurements on the physical systems in our lab.

The accuracy of simulation results has more to do with the quality of the models and their parameters than it does with the simulator. As with any computing utility, the old saying: garbage-in, garbage-out, still applies. Simulations are as accurate as the models are valid.

Therefore, model validation is one of the most important aspects to any simulation endeavor. It is helpful to use pre-validated library models where possible. Any new models should be validated prior to relying on their results.

The calibration/validation process should compare the model to actual hardware systems or other trusted simulations, if possible. We promote a model-calibration process, where the model and its parameters are modified as needed to reach a satisfactory degree of accuracy. The running of sanity tests is highly recommended throughout any simulation project. Such tests check for reasonableness of results and for exceeding any absolute conditions. For example, you would probably know that a model is inaccurate if it implies that more data transferred across a link in less time than its transfer rate could support. It is usually more convenient to conduct sanity tests with simulation models than it is with purely analytical methods, because simulations offer greater flexibility and observability. See also Time Range and Precision.
Q: What documentation exists? Is it available on-line?
A: The full documentation on CSIM is web-based. It is available on-line in HTML accessible from any standard browser. (Available as hardcopy from the web-pages as well.)

The documentation is extensive, (over 900 printed pages), logically organized and indexed. It includes a tutorial, examples, and user-manuals on each of the tools.

Being hyper-text documentation, it is very easy to use. It is also live, being constantly updated and improved, so users always have access to the most up-to-date versions. See: www.csim.com/.
Q: On what prior modeling heritage is CSIM based ?
A: CSIM builds upon a considerable heritage. It's direct origins trace back to the System Architecture Simulator (SARSIM) project of 1983. At that time, various Hardware Description Languages, or HDLs, were being used to design hardware. As the name implies, an HDL can describe the functionality of hardware as well as its implementation. SARSIM added the ability to design software, and became one of the first system design tools.

The first HDL was ISP, invented by C. Gordon Bell and Alan Newell at Carnegie Mellon University and described in their book Computer Structures in 1972. This language was also the first to use the term Register Transfer Level. This came from the use of ISP in describing the behavior of the PDP-8 computer as a set of registers and logical functions describing the transfer of data from source register to destination register.

Prior simulation languages and systems on which CSIM research was based, include the General Purpose Simulation System (GPSS), Simulation Language for Alternative Modeling (SLAM), Simula, as well as SIMSCRIPT, Modula-2, and MODSIM, by CACI. Subsequent HDLs included Vhsic-HDL (VHDL) which was begun in 1981, Mimic developed by RCA, AdLib Sable developed by Stanford University, Mimola by Univ. Dortmund, HiLo, the predecessor to Verilog, and ISP', which was a successor to ISP (implemented by the N.dot simulator at Case Western Reserve University).

SABLE (Structure And Behavior Linking Environment) was developed at Stanford to support structured, multi-level behavior specification and simulation of digital systems. SABLE accepted information about the nesting and inter-connectivity of components, and combined it with descriptions of their behavior, which were written in a language called ADLIB (A Design Language for Indicating Behavior). ADLIB allowed users to define the "data level" at which each component operates, and to specify mechanisms for translating information between these levels. SABLE attempted to provide more general and flexible facilities, to enable simulation of larger systems at several levels of abstraction simultaneously. However, unlike N.dot, ADLIB SABLE did not possess a notion of Time.

CSIM was influenced heavily by all of these, but particularly extended the concepts of ISP' (pronounced ISP-prime), N.mpc (package later became known commercially as N.dot), and VHDL, which were aimed at microprocessor design, - by elevating them to the level of full systems design.

A principal feature of system description languages is that they contain capabilities to describe the functionality of components independently from their implementations. The great advance with CSIM was the recognition that a single language can describe the functionality of designs, while also describing their implementation(s). This allows the entire design process to take place in a single environment with unified representations. 






  

  
. . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

(Questions, Comments, & Suggestions: admin@csim.com)