Projects

VHDL-based methodology for modelling computer communication systems

You are not Member of this Project.
Project Owner : leelamohan
Created Date : Sat, 16/04/2011 - 19:03
Project Description :

Abstract- Currently the design and development
process employs different modelling and design
techniques at each level of system abstraction. This
makes the process inefficient and costly. VHDI,,
however, has the potential to unify this process. VIADL's
widespread use in the design, development and synithesis
of ASICs is an indication of its success. It has :ilre:ady
lead to revolutionary changes in the way traditionall
systems design is performed. Today new ASIC design
starts with a VHDL description of the circuit and then
the ASIC is synthesized from this description, 'The next
step in VHDL's evolutionary use is in the modelling of
systems at higher levels of abstraction. The specification
and design of an entire large scale system is possible.
This paper presents a VHDLbased methodology for
modelling computer communication systems, called VCCS,
to demonstrate VHBL's ability to design :and model
systems at a high level of abstraction. The methodology,
design strategy and primary characteristics of the WHDL
implementation are explained.
A. High-Level VHDL Modelling
Tne VHSIC H,ardwarl: Description Language, VHDL, an
IEEE standard adopted i,n 1987 and revised in I993 [3], was
created as a standardized means of documenting electronic
design work, communicating design ideas and providing a
format for d~esignimg from initial conception to final product.
VHDL is an abstract modelling language that could describe
the temporal behaviour and structure of a system from the
overall block diagam level down to the gate level.
However, thus far VHDI, has been used primarily for
describing the behaviour and structure of integrated circuits,
VHDL has rarefy been used for more abstract high-level
system desigp. This parer demonstrates the use of VHDL
as a high-level modelling and simulation language. A
VHDL-based methodology for modelling computer
communication systems is presented. The methodology's
implementation ini VHDL illustrates the potential for VHDL
to unify the design and development process.
11. THE, METHODOLOGY
I. INTRODUCTION
To understand today's complex systems, the sy:stem needs
to be broken down into smaller more understandable
portions through abstraction. Different levels of abstraction
can be used to model a system. The upper and mixt
abstract layer is typically a block or a state diagram. .At
lower levels of absvaction are modelling and simulation
tools, like Simscript, General Purpose Simulation Systiem
(GPSS). and VHDL. Developing a system will generally
involve various levels of abstraction and therefore various
modelling tools. The process is inefficient. Trandations
between modelling and simulation tools are time consilmin_g,
and more importantly these translations can produce ei~ors
[ 11. These errors are created as specifications at different
levels are misunderstood by the modeller. In some cases
interfacing details are lost due to abstraction or other
modelling restrictions and inefficiencies are introduced due
to differences in the design philosophies of each
methodology. In summary, the lack of high-level systems
modelling is due in part to the lack of a single modelling
language has been accepted as having the capability of highlevel
systems modelling and yet having the ability to do
lower level modelling and design. Ideally, designers need a
modelling and simulation tool that can be used at all s,tages
of design and development [ 2 ] .
The methodology is based on the concept of a hierarchy
of modules. In data network terminology the word module
is used to refer either to a device or to a process within a
computer system [4]. The synonym to module in modelling
terminology is an e1ztit)r. The entity performs a given
fkction in support of the overall function of the system. In
data network; temunology such a function is often called a
service provided by the entity. The designers of an entity
will know and understand the intimate workings of that
entity. However, the entity can also be viewed as a "black
box" by someone who only uses that entity as a component
in a larger system. This user will only be concerned with
the inputs, outputs, and \:he functional relation of the outputs
to inputs (ie the service provided), but will be unconcerned
with the internal operation of the box.
Conceptually a black box is an entity viewed in terms of
its input-out:pus description. It can be used with other black
boxes to coristruct a more complex entity, which again can
be viewed ail higher levels as a bigger black box. Thus, an
entity appears as a black. box at one layer of the hierarchy,
but appears as a system of lower-layer black boxes at the
layer lower in the: hierar'chy [4]. This concept is illustrated
in Figure 1.
hierarchy), one sees a small collection of top-layer entities,
each viewed as black boxes providing some distinct service.

At the next layer down, each top-layer entity is viewed as
a subsystem of lower-layer black boxes, and so forth down
to the lowest layer of hierarchy. In general, each layer
might contain not only black boxes made up of lower-layer
entities, but also simple entities that do not require division
into yet simpler entities [4].
This approach allows the computer communications
designer to model at various levels of abstraction. In most
cases, however, the user will not need to move to lower
levels. Knowing the response of outputs to inputs will be
suficient. Funhermore, the entities can be specified in
terms of tolerances, rather than specific and precise timings.
This allows for the designer to standardize entities making
the model design simple, and more understandable, while
also making its component entities interchangeable. In
addition, standardized entities can easily be replaced or
updated as technology improves.
A. Modelling Entities
The objective of the modelling process is to determine the
simulated performance of a computer communication system
(CCS). This performance measurement is accomplished by
measuring parameters such as throughput, utilization and
latency, To measure these parameters the made1 of the
system must monitor the flow and manipulation of data.
Thus, the entities that are modelled are the ones that
significantly influence the flow and manipulation of data;
significant factors would be channel delay, channel
bandwidth, routing of data etc. Data manipulation would be
in the form of software tasks that take some finite, but
significant length of time to process. For instance, a
software task might be doing a FFT (Fast Fourier
Transform) on some digitized sonar data.'
Figure 2 shows the basic features of a simple LAN. The
primary hardware structures of the LAN are the nodes and
the cable. To model the LAN the cable could be represented
by a channel entity and each node as a processor entity. The
software structures consist of individual programs and tasks
that run on each node as well as common network processes
that control the access to the channel. The behaviour of the
software structures could be modelled with generic
instructions for processor specific tasks. Protocol related
processes, because they do not generally change once
implemented in a network, could be modelled directly into
t
Fig. 2: Basic Ethernet Local Area Network (LAN)
One can state that the basic entities that influence the
manipulation and flow of data can be categorized in two
classes: 1, hardware structure entities; arid 2, software
structure entities. This approach of describing computer
networks in terms of hdamental entities has been
previously incorporated in a Simscript based modelling tool
called Network 11.5 by CACI [5].
1 System Hardware Struewe Entities
One can see that the basic hardware structures of the
LAN illustrated in Figure 2 can be simply modelled with
two entities: Processor entities [Pes) that are connected by a
channel entity (a)T*he processors could also share
resources such as memory and printers or other peripheral
devices. The peripheral devices could be modelled as simple
processors or in the case of memory as a distinctly dit€erent
entity.
significant effect on the overall system performance. The
time to read and write data, the storage capacity, the
coherency of the data can all have an effect on the flow of
the data in the system. Other devices such as printer
servers, or display processors are not significantly &Rerent
from processors to warrant a distinctly different model
entity. They can be modelled with a simplified processor
entity instead. The attributes of memory are dissimilar
enough to warrant a specific modelling construct called a
memory entity (ME).
All processors use memory. Memory devices have a
a. Multi-La-ver Models: The Need jor a CCS-Bridge Entip
A system might be modelled with varying degrees of
detail or abstraction. A multiprocessor may be considered a
sub-system or sub-model. A sub-model is also constructed
from the fimdamental processor entities, memory entities,
channel entities. The overall system can be regarded as a
multi-layer model. In most cases the models (layers) will
use different channels. In a real system, communication
between networks using different channels and protocols is
accomplished by some form of channel translator, i/o
processor or network bridge. This bridge allows messages

to bc transmitted to or from two distinct network?.
Likcwisc, a compulcr communication system bridge entity,
CCS-Bridge, is required to aliow data lo be passed to and
from different mtxlels. The CCS-Bridge entity acts ai a
channel entity translator.
b. Graphical Svmhology
A means of representing the hardware entities graphically
will make the definition of the system and the dcsiign
process simpler and easier to comprehend. V-Chms [23
were used as a guide for the symbology. The followinig
hardware structures have been identified along with their
abbreviation and graphical symbol:
a. processor entity (PE) ~ boxes:
b. channei entity (CE) ~ solid lines; and,
c. memory entity (ME) - circles.
d. CCS-Bridge entity (Bridge) - 6 sided polygorn
a. Device Lqver iDrocessrs 629
Device layer processes are software tasks or operations
performed by sysltem proccssors. These software operations
involve significant manipulation of data. Naturally, there is
a requirement for another modelling entity called a sufiwure
enfit-v (SE). A software entity represents the execution of a
program. The execution of software entities will initiate and
drive the system by executing instructions on a processor
entity (PE). A software task will consist of instructions to
be executed in sequential order on one or more processors.
For example, the following instructions could be executed by
processor entity PE1 : iiritiaIize-PEI, process-datu,
wri&-result, send-tnessrzge. The specifics of each
instruction iire processor dependent. Tnere are three
fundamental instiuctiona:
i. file instructions - used to access memory;
ii, messam instructions ~ messages passed among Pes;
iii. process instructions - specialized instructions.
Figure 3 illustrates the use of these graphical :;yrnlaols to
represent the modelled hardware structures. The system -- -
consists of two processors, labelled Processor-S I and
Processor-S2 one memory entity, labelled Memory31 I and
a channel entity, labelled Channel-SI. Processor-SZ is a
processor entity. Processor-S I, a multiprocessor, is a lower
level model connected to the upper mode1 channel,
Channel-S1, via the multiprocessor's i/o port ancl a
CCS-bridge entity. Processor3 1 is modelled with processor
entities PE-SI-A and PE-SI-B, a memory entity M:E-SI-A
and a channel entity CE-S1-A. ,
2. Svstenr Sojiware Structure Entities
To measure the performance of the system one must also
identify the sotiware structure entities that have a significant
effect on the flow and manipulation of data. Obviously,
these entities will be used to model software prccessa.
There are two levels of processes that are represented: 1, the
device layer processes; and 2, network layer processes.
The execution, of Ses can be deterministic or random
The random execution of a SE can be achieved through
selection of' attributes. These attributes allow for a set of
preconditions to be meet before an SE can execute and allow
an SE to trigger the exelcution of another SE. Ses can
execute continuously, periodically or just once.
b. Network Layer Proctrsses
The designer of a car"nunication network must address
at least three basic issues: connection strategy, contention
and topology. The three basic network issues are handled by
the methodology through a set of protocol atnibures. These
attributes will delfine thlc protocol used by each of the
hardware sl.ructures in the model (processors, memories,
channels).
To model the connection strategy the protocol attributes
provide a nneans to model the two most common techniques,
message switching and packet switching. To model
contention the pirotocol attributes provide the capability to
model the methcd of passing data through channels and
between deviccs (processors, memories). Thus, popular
protocols are inciuded such as collision, token bus, token
ring, priority tok:en ring:, slotted token ring, first come first
served, priority IFCFS; Protocoi attributes will be associated
with each hardware stnicture entity (CE, PE, ME).
The topology of a system describes how devices are
geographicially or physically connected. A connection list
attribute in the protocol, attribute set will define how the
devices on the network are physically connected as well
their physical interconnection in the implemented model.
c. Graphical Svmhulogv
GraphicaI symbols a.re also required to represent software
structures as they were to represent hardware structures. VCharts
[2] symbology c:annot illustrate the logical flow and
dependence of software entities, without significant

therefore required. The list &low summarizes the software
structures identified, followed by the graphical symbol used
to represent each one.
a. software entities - represented by circles. Precedence is
indicated by a solid arrow. ORed precedencies are
symbolized with a logic OR gate to distinguish them from
typical ANB precedencies;
i. read/write instructions - file folder symbol;
ii. mesa.@ instructions - dashed arrors;
iii. process instructions - no symbols; and,
b, protocol attributes - no representation, although a
label beside the channel entity will indicate the type of
protocol used.
Figure 5 illustrates the use of the software structure
symbols. The figure shows some possible software entities
(SE) that may be executed by the system depicted in Figure
3. To briefly explain,.processor entities P E S 1-A, PEWS 1-B
and PE-% are initialized by individual initialization SEs
(Initialize PEJl-A, Initialize PE-SI-B, and Initialize
PE-%?) at the start. of a simulation run. The initialization
SEs, Initialke PE-SI-A, Inirialize PE-SI-B, send messages
Message-To-PE which cause SEs Program-A and
Frogram-B to execute. Program-A and ProgramB execute
Fig. 4: Software Strucmre Symbols.
their instructions which include a message instruction called
Message-To-PE again. Since both programs depend on the
reception of the message Message-To-PE to execute, both
SEs will execute continuously. The frst execution of SE
ProgramJ also allows SE Process-Daia to execute
provided it receives its precedence message
Sensor-Data-Ready from SE Send-SensorJata. The SE
Process-Data also writes a file, Track-History. to memory
entity ME-S 1-A.
3. Entity Attributes
Most attributes are embedded in each entity as operating
parameters that might have to be specified by the modeller.
For example, a processor entity (PE) is designed to model
the essential behaviour of processor type devices. Each PE
has cycle time, input/output (i/o) timings, a rudimentary
instruction set (read, write, message and execute instructions)
and the ability to specify whether it can receive messages
while processing. The instruction set is based on four
essential types of instructions, read, write, message, and
process. The rudimentary set simplifies the specification of
instructions. These PE features are represented by a set of.
user specified anributes. The attributes may also be
mechanisms required to provide a function or service
transparent to the modeller. A description and list of the
attributes may be found in the V-CCS User’s Manual [6].
4. State Variables: Event Geirerarion and Recordiq Entities
In discrete event simulated systems (VHDL) an event is
used to model the start and completion of activities. Events
may occur only when an activity begins or when it ends.
These are the only times when the state of a discrete event
system may change. Any of the many events that. occur in a
discrete event simulated system may be used to measure
some aspect of the system’s performance. The events of
primary interest in a computer communications system
involve the manipulation and flow of data.
as either random or deterministic without having to
specifically create or generate these events. If an event has
a stochastic definition then the modeller is given the
flexibility of choosing the baaatistical distribution that defines
the random event generation. For instance, the execution
time of a PE’s process insactions may be exponential, the
backoff time for network collision may be uniform and
message generation may be exponential.
To conduct an analysis of the simulation a means of
logging significant and specific events is incorporated as
well as a means to calculate and record event statistics [7].
The modeller is provided with a means of defining events
B. Methodologv Design Steps
Based on the approach and structure described above
there are eight fundamental steps to the modelling
methodology:
1. System Description;
2. Assess Performance Evaluation Parameters;
3. Determine Hardware Structures;
3. Determine Software Structures;
5. Spcifi Hardware Structure Attributes;
6. Specify Software Structure Attributes;
7. Connect Entities to Form System Model; and,
8. Simulate Model and Analyze Data.
111. IMPLEMENTATION OF METHODOLOGY
The methodology for modelling computer communication
systems and its implementation has been assigned the
acronym V-CCS. A detailed description of the
implementation and the code is contained in the V-CCSA, Implemenlation S1rzrteg.v
Implcmenting thc mcthodology in VHDL involved
determining the most suitable VHDL constructs to build the
modelling entities, to generate and log events and to
instrument the models. The strategy takes advantage of six
, of VHDL's important features:
1. VHDL's ability to allow a topdown and library-bawd
approach to design using the LIBRARY and PACKAGE
constructs;
2. VHBL's ability to allow designers to declare a virtually
unlimited number of data types;
3. VHBL's ability to model hardware devices through the
use of the ENTITY/ARCHITECTURE pair constructs;
4. VHDL's ability to allow easy use and replication of
previously constructed devices through the use of tkie
COMPONENT and instantiation declaration;
5. VHDL's flexible, inherent ability to allow the ciesigper to
model either structure or behaviour of an ENTITY; and,
6. The use of interface lists and association lists to camect
devices (COMPONENTS).
Each of the above features and constructs of VHDL are
used to implement the various aspects of the"methodology-
For instance, the entities identified by the methodology as
well as some additional support entities are implernented
using the E"Y/ARCHITECTUR constructs of VI-IDL.
Also, all the methodology qecifie data types, functions,
procedures, and components we contained in the rnain VCCS
PACKAGE. This PACKAGE is used to build all
models.
B. Model Control
Discrete-system models created in VHDL are even1
driven. Events on SIGNALS drive the model. To
implement the methodology three categories of SIGNALS
are used. One SIGNAL category drives the model
behaviour, the second provides data passing suppcrt type
functions. while the third provides model control type
support. The majority of these SIGNALS are comnectcd to
the PORTS of each ENTITY/COMPONENT.
instruments to implement various operations and again are
not meant to reflect a real system operation. As em example,
several global queues were created to allow the globall
visibility of such things as the status of hardware structures,
the contents of a memory entity, and SE requests for PE.
To notify the model's COMPONENTS that the contents of
these global queues have changed specific SIGNP,Ls
perform a flagging operation.
Model control type support SIGNALS are used as
each COMPONENT. This iinalysis results in a simulation 631
report which includes the: total number of events, and
statistics such as the event mean, mean time between evcnts,
and variance, time: standard deviation. Simulation results
were product:d for a five node model, nine node model and
11 node model which included two multiprocessor submodels.
All three models were simulated using CSMA/CD,
Aloha, and Token Bus pirotc~ols. Thcse simulations proved
the utility of the methodology and V-CCS software [SI.
IV. CONCLUSIONS
The methodobgy invdves moderately simple steps
without the need Ifor an in depth understanding of VHDL.
The methodology is valid and general enough to cover a
reasonable number of classes of computer system. Both
large and srrlall systems can be modelled with only a linear
increase in nncdel code !en_@ and there is enough flexibility
to model at 'levels; of abstraction slightly above and below
the intended abstraction level. Furthermore, since it is
written in VHDL it is very ponabl?.
Finally, i!: is clear that it is possible to use VHDL at.
higher levels of abstraction than it was originally intended.
In patticular, it can be used to model and design at the
system level. Thus, VHDL has the potential to unifj. the
design and development process.
[l] Rosenberg A.E., Harris, T., "VHDL and Its Application
for the DoD Contrai:ts*, Proceedings of the VHDL
International User's Forum: Spring 1993, pp. 67-74.
[2] Mercer, D.E.W., "Plxformance Measurement of VHDL
Models", Masters Thesis, Elec&Cmptr Engr Dept, Royal
Military College of Canada, 1993.
[3] IEEE Std 1076-1993, New York, NY, IEEE, 1994.
[4] Bertsekas, D., Gallager, R, Data Networks Second
Edition Engliewoodo Cliffs,NJ, USA, Prentice-Hall Inc,
1992.
[5] CACI (199111 Network LI.5.User's Manual, Release-z,
CACI, 200440 Laurier Ave. W., Ottawa,Canada.
[6] Morris, S.C., Smith, D.R., 'A VHDL-Based
Methodology for Modelling Computer Communication
Systems: V-(33 User's Manual", Elec&Cmptr Engp
Dept Tech R.eport 95-1, RMC of Canada, 1995.
Measurement System for VHDL Models", Elec&Crnptr
Engr Dept Tech Report 93-2, RMC of Canada, 1993.
Methodology for Modelling Computer Communication
Systems: Sinnulatinlg Using V-CCS", EIec&Cmptr Engr
Dept Tech Report 95-21, RMC of Canada, 1995.
[7] Mercer., D.E,,W., Smith1 D.R,"A Performance
681 Morris, S.C.., Smith, D.R. "A VHDL-Based
C. Events Recorded and SimuIation Results
Currently, 52 different types of events are reco,rded. VCCS
provides statistical analysis of the recorded events for

You are not authorized to access this content.
You are not authorized to access this content.
You are not authorized to access this content.
You are not authorized to access this content.
You are not authorized to access this content.