An Implementation of the Behavioral Verilog Simulator in Ptolemy Pai Chou April 14, 1994 Abstract Mo deling and simulation of digital hardware at the b ehavioral level enable designers to exp eriment with a system without sp ecifying implementation details. Verilog is a language that supp orts mo deling and simulation at di erent levels of abstraction. However, all comp onents in the same design must conform to a certain timing mo del, whichmay not b e natural for all comp onents. Ptolemy is a simulation environment for systems with heterogeneous timing mo dels. This rep ort describ es the incorp oration of the b ehavioral Verilog simulator into Ptolemyby a compiler, which expresses the simulation semantics of Verilog in C++. 1 Intro duction Behavioral mo deling and simulation enable hardware designers to prototyp e systems without sp ecifying implementation details. Several hardware description languages including Verilog and VHDL supp ort b ehavioral sp eci cations, with semantics tuned for simulation on a unipro cessor. Each simulator either assumes some timing paradigm or implicitly requires comp onents of a given design to conform to a single timing mo del. This restriction can imp ose an unnatural timing mo del on the designer for some subsystems. Ptolemy is a prototyping and simulation environment designed sp eci cally to address this problem by acting as a co ordinator for di erent timing mo dels. Originally designed at UC Berkeley [1] for mo deling digital signal pro cessing DSP applications, Ptolemy is gaining applications in general digital hardware simulation. Ptolemy di ers from most simu- lators b ecause it do es not imp ose any given timing mo del, but rather it co ordinates the interaction b etween di erent mo dels. Ptolemy is also well known for its sophisticated graphical user interface, including an integrated schematic editor, graphical library comp onents ranging from scop es and chart plotters to video display windows. Verilog is one of the ma jor hardware description languages in use to day[2]. Originally a proprietary An Implementation of the Behavioral Verilog Simulator in Ptolemy 2 language from Cadence Design Systems, and now op enly available, Verilog supp orts mixed b ehavioral and structural descriptions of hardware. It supp orts concurrent programming constructs and hardware data- typ es. Several commercial CAD to ols also use Verilog for veri cation, timing analysis, and synthesis. The ability to simulate Verilog in Ptolemy is useful for several purp oses: it gives the Verilog simulator a graphical user interface, but more imp ortantly, it enables designers to integrate comp onents describ ed in Verilog with those in di erent timing paradigms supp orted by Ptolemy, without having to describ e them in an otherwise unnatural language for their application. The pap er is organized as follows: Section 2 gives an overview of Ptolemy; Section 3 gives an overview of the b ehavioral Verilog language and its simulation semantics; Section 4 explains the mapping of Verilog to C++; Section 5 describ es the structure of this Verilog-to-C++ translator, which comprises the core of this pro ject; and nally, Section 6 concludes this pap er with an evaluation of this implementation and future work. 2 Overview of Ptolemy Ptolemy is an ob ject-oriented simulation environment that co ordinates the interaction b etween multiple computation mo dels. Each computation mo del is called a domain. Ptolemy uses astronomical metaphors to describ e the hierarchy of the computational units, called blocks.Astar is a leaf-level blo ck b elonging to a given domain. A collection of interconnected stars of the same domain forms a galaxy. A fully sp eci ed, executable galaxy is a universe.Awormhole is a blo ck which app ears as a star on the outside, but is actually a galaxy of a di erent domain on the inside. Wormholes are used to mix stars of di erent domains in the same system. Blo cks consume, compute, and pro duce data; a blo ck's communicationinterface is called a porthole. Two p ortholes are connected by a communication channel called a geodesic, which delivers particles, or data packets, from one p orthole to another. Each star is de ned as a C++ class containing a constructor, a start metho d, a go metho d, and a list of variables. The constructor instantiates the star and its p orts, the start metho d is called once at the b eginning of each simulation run to initialize lo cal variables and states, and the go metho d is called every time the star is scheduled to consume, compute, or pro duce particles. To run the simulation, Ptolemy compiles the C++ star descriptions and dynamically links them in with the the runtime library. The domains currently supp orted are SDF, DDF, DE, Thor, and Co deGen. The SDF Synchronous Data ow kernel schedules the blo ck execution statically, while the DDF Dynamic Data ow kernel schedules Figure 1: Building blo cks in Ptolemy dynamically. The SDF and DDF domains do not have the notion of time, but the order in which the stars in these domains consume and pro duce the particles is signi cant. DE Discrete Event and Thor CHDL [3] are timed domains. DE particles corresp ond to events; Thor particles represent\values on pins." The particles in these domains have time-stamps for delivery. These stars can also schedule themselves to b e invoked, or \ red," after a certain delay. The Verilog simulator describ ed here uses the Thor domain's timing mo del. Since sp ecifying stars directly in C++ can b e error-prone, and burdens the programmer with excessive detail, Ptolemy supp orts the use of prepro cessors. These are invoked automatically to convert a star in any source language to C++ in a format as exp ected by Ptolemy. SDF, DDF, and DE domains use the prepro cessor language \ptlang," while the Thor domain uses \p epp" Pthor Extended PrePro cessor to translate CHDL into C++. This pro ject adds a prepro cessor called \VCC" to the Thor domain to translate Verilog into C++. 3 Overview of Verilog Verilog describ es hardware as a set of hierarchical comp onents called modules. A mo dule interfaces with its environment via its ports. A mo dule can either describ e the behavior of a comp onent as a program, or describ e its structure as a set of nested mo dules, primitive comp onents, and wires. This pro ject uses Verilog to sp ecify b ehavior and Ptolemy to capture the interconnection top ology. Behavioral Verilog resembles an imp erative programming language, with supp ort for hardware data-typ es and concurrency. Data-typ es in b ehavioral Verilog include input and output p orts, registers, integer, and real. A scaler [sic] is a \single bit" quantity with four p ossible digital hardware states: 0, 1, X unknown, and Z oating. A vector is an array of scalers which representavalue as a group. For example, 4'b01xz denotes a 4-bit vector constant whose scalers havevalues 0, 1, X, and Z, resp ectively. The subrange and index op erators An Implementation of the Behavioral Verilog Simulator in Ptolemy 4 always b egin :R whilecond b egin :S b egin :S ... disable S; ... disable S ... whilecond b egin ... end end disable S always b egin :S end ... end /* like continue inC*/ /* thread R resets thread S */ /* like break in C. */ Figure 2: Example uses of disable select a slice or an individual scaler from a vector. An integer mo dels a 32-bit vector, and a real usually mo dels a double precision oating p oint quantity. The concurrent constructs include continuous assignments, the initial statement, and the always state- ment. Continuous assignments mo del combinational logic as an arithmetic/logical expression, with the input signals and p ossibly some registers as terms, where the result is assigned to an output p ort after some de- lay.Aninitial statement is executed once at the start of a simulation run and b ecomes inactive, while an always statement is executed rep eatedly in an in nite lo op. The initial and always statements are concurrent threads of control. During simulation, threads are scheduled round-robin until they blo ck. The programmer is resp onsible for explicit synchronization b etween threads, and should not make assumptions ab out the relative order of execution b etween the threads at any given instant. The statements in b ehavioral Verilog include those constructs commonly found in conventional C- like sequential programming languages, like if/then/else, while lo ops, for lo ops, rep eatn lo ops, and switch/case statements. In addition, the ones sp eci c to Verilog are wait, @'s that wait on a transition edge, @'s that wait on named events, delay, and disable. The waitcond construct blo cks until the b o olean expression cond evaluates to true. The @expr construct blo cks until expr changes its value. One can also sp ecify a rising or a falling edge transition by qualifying expr with the keywords p osedge and negedge, resp ectively. Named events are abstract eventtyp es. The keyword event de nes a name as the event. An event involves two threads, a sender and a receiver. The sender has the syntax ->name, and the receiver @name. One can think of a send as dep ositing an event instance into a bu er, and a receive as removing the instance. If the bu er has no event, the receiver blo cks. The sender do es not blo ck, b ecause the bu er holds at most one instance.