Frequently Asked Questions
||What descriptive paradigm is supported? State diagrams?
||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,
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.
How to pronounce CSIM?
||How to get more information?
||What about support?
||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.
||What computer platforms can be supported?
||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.
||What are the requirements to run CSIM on a workstation and on a server?
Are there different versions for a workstation versus a server?
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.
||What about training?
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.
||When and why was CSIM developed?
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
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.
||What kind of systems can be described? Can you interface to other tools?
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.
||How accurate are the simulations?
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.
||What documentation exists? Is it available on-line?
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.
On what prior modeling heritage is CSIM based ?
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: firstname.lastname@example.org)