| blob | 0e73877ac6ced4e1a634f92df5f5151ffe636029 |
5 <head>
12 <link rel="search" type="application/opensearchdescription+xml" href="http://geda.seul.org/wiki/lib/exe/opensearch.php" title="geda Wiki" />
14 <link rel="contents" href="http://geda.seul.org/wiki/geda:icarus_vvp_simulation?do=index" title="Index" />
15 <link rel="alternate" type="application/rss+xml" title="Recent Changes" href="http://geda.seul.org/wiki/feed.php" />
16 <link rel="alternate" type="application/rss+xml" title="Current Namespace" href="http://geda.seul.org/wiki/feed.php?mode=list&ns=geda" />
17 <link rel="alternate" type="text/html" title="Plain HTML" href="http://geda.seul.org/wiki/_export/xhtml/geda:icarus_vvp_simulation" />
18 <link rel="alternate" type="text/plain" title="Wiki Markup" href="http://geda.seul.org/wiki/_export/raw/geda:icarus_vvp_simulation" />
22 </head>
23 <body>
31 * Copyright (c) 2001 Stephen Williams (steve@icarus.com)
32 *
33 * $Id$
34 */
36 VVP SIMULATION ENGINE
38 The VVP simulator takes as input source code not unlike assembly
39 language for a conventional processor. It is intended to be machine
40 generated code emitted by other tools, including the Icarus Verilog
41 compiler, so the syntax, though readable, is not necessarily
42 convenient for humans.
45 GENERAL FORMAT
47 The source file is a collection of statements. Each statement may have
48 a label, an opcode, and operands that depend on the opcode. For some
49 opcodes, the label is optional (or meaningless) and for others it is
50 required.
52 Every statement is terminated by a semicolon. The semicolon is also
53 the start of a comment line, so you can put comment text after the
54 semicolon that terminates a statement. Like so:
56 Label .functor and, 0x5a, x, y ; This is a comment.
58 The semicolon is required, whether the comment is there or not.
60 Statements may span multiple lines, as long as there is no text (other
61 then the first character of a label) in the first column of the
62 continuation line.
64 HEADER SYNTAX
66 Before any other non-commentary code starts, the source may contain
67 some header statements. These are used for passing parameters or
68 global details from the compiler to the vvp run-time. In all cases,
69 the header statement starts with a left-justified keyword.
73 This header statement names a vpi module that vvp should load before
74 the rest of the program is compiled. The compiler looks in the
76 dynamic load them.
80 This header statement specifies the time precision of a single tick of
81 the simulation clock. This is mostly used for display (and VPI)
82 purposes, because the engine itself does not care about units. The
83 compiler scales time values ahead of time.
85 The value is the size of a simulation tick in seconds, and is
87 nanosecond. If the record is left out, then the precision is taken to
88 be +0.
90 LABELS AND SYMBOLS
92 Labels and symbols consist of the characters:
94 a-z
95 A-Z
97 .$_<>
100 are easily distinguished from keywords and numbers. A Label is a
101 symbol that starts a statement. If a label is present in a statement,
102 it must start in the first text column. This is how the lexical
103 analyzer distinguishes a label from a symbol. If a symbol is present
104 in a statement, it is in the operand. Opcodes of statements must be a
105 keyword.
107 Symbols are references to labels. It is not necessary for a label to
108 be declared before its use in a symbol, but it must be declared
109 eventually. When symbols refer to functors, the symbol represents the
110 vvp_ipoint_t pointer to the output. (Inputs cannot, and need not, be
111 references symbolically.)
113 If the functor is part of a vector, then the symbol is the
114 vvp_ipoint_t for the first functor. The [] operator can then be used
115 to reference a functor other then the first in the vector.
117 There are some special symbols that in certain contexts have special
118 meanings. As inputs to functors, the symbols "C<0>", "C<1>", "C<x>"
122 SCOPE STATEMENTS:
125 PARAMETER STATEMENTS:
127 Parameters are named constants within a scope. These parameters have a
128 type and value, and also a label so that they can be referenced as VPI
129 objects.
131 The syntax of a parameter is:
137 following:
139 real -- The parameter has a real value
140 string -- The parameter has a string value
142 -- The parameter is a vector, with specified
144 unsigned.
146 The value, then, is appropriate for the data type. For example:
151 FUNCTOR STATEMENTS:
153 A functor statement is a statement that uses the ``.functor''
154 opcode. Functors are the basic structural units of a simulation, and
155 include a type (in the form of a truth table) and up to four inputs. A
156 label is required for functors.
158 The general syntax of a functor is:
162 The symbol list is 4 names of labels of other functors. These connect
163 inputs of the functor of the statement to the output of other
165 type selects the truth lookup table to use for the functor
166 implementation. Most of the core gate types have built in tables.
168 The initial values of all the inputs and the output is x. Any other
170 symbols, then the inputs are initialized to the specified bit value,
171 and if this causes the output to be something other then x, a
172 propagation event is created to be executed at the start of run time.
174 The strengths of inputs are ignored by functors, and the output has
175 fixed drive0 and drive1 strengths. So strength information is
176 typically lost as it passes through functors.
178 Almost all of the structural aspects of a simulation can be
179 represented by functors, which perform the very basic task of
180 combining up to four inputs down to one output.
182 - MUXZ
184 Q | A B S n/a
185 --+-------------
186 A | * * 0
187 B | * * 1
190 DFF STATEMENTS:
192 The Verilog language itself does not have a DFF primitive, but post
193 synthesis readily creates DFF devices that are best simulated with a
194 common device. Thus, there is the DFF statement to create DFF devices:
201 type of datum at all. The device will transfer the input to the output
203 asynchronous input that is immediately stored and transferred to the
204 output when data arrives here. This is useful for implementing
205 asynchronous set/clear functions.
207 UDP STATEMENTS:
209 A UDP statement either defines a User Defined Primitive, or
210 instantiates a previously defined UDP by creating a UDP functor. A
211 UDP functor has as many inputs as the UDP definition requires.
213 UDPs come in sequential and combinatorial flavors. Sequential UDPs
214 carry an output state and can respond to edges at the inputs. The
215 output of combinatorial UDPs is a function of its current inputs
216 only.
218 The function of a UDP is defined via a table. The rows of the table
219 are strings which describe input states or edges, and the new output
220 state. Combinatorial UDPs require one character for each input, and
221 one character at the end for the output state. Sequential UDPs need
222 an additional char for the current state, which is the first char of
223 the row.
225 Any input transition or the new state must match at most one row (or
226 all matches must provide the same output state). If no row matches,
232 An input or current output state can be
242 For Sequential UDPs, at most one input state specification may be
243 replaced by an edge specification. Valid edges are:
253 A combinatorial UDP is defined like this:
255 <type> .udp/comb "<name>", <number>, "<row0>", "<row1>", ... ;
259 need an additional initialization value:
261 <type> .udp/sequ "<name>", <number>, <init>, "<row0>", "<row1>", ... ;
267 A UDP functor instance is created so:
273 input of the UDP.
276 VARIABLE STATEMENTS:
278 A variable is a bit vector that can be written by behavioral code (so
279 has no structural input) and propagates its output to a functor. The
280 general syntax of a variable is:
287 sake of VPI code that might access it. The variable is placed in the
288 current scope. The variable also has a width, defined by the indices
289 for the most significant and lest significant bits. If the indices are
290 equal (normally 0) the vector has width of one. If the width is greater
291 then one, a contiguous array of functors is created and the value of
292 the label is the address of the least significant bit.
294 A variable does not take inputs, since its value is set behaviorally
295 by assignment events. It does have output, though, and its output is
296 propagated into the net of functors in the usual way.
298 A variable gets its value by assignments from procedural code: %set
299 and %assign. These instructions write values to the port-0 input. From
300 there, the value is held.
302 Behavioral code can also invoke %cassign/v statements that work like
303 %set/v, but instead write to port-1 of the variable node. Writes to
304 port-1 of a variable activate continuous assign mode, where the values
305 written to port-0 are ignored. The continuous assign mode remains
308 Behavioral code may also invoke %force/v statements that write to port-2
309 to invoke force mode. This overrides continuous assign mode until a
312 NET STATEMENTS:
314 A net is similar to a variable, except that a thread cannot write to
315 it (unless it uses a force) and it is given a different VPI type
316 code. The syntax of a .net statement is also similar to but not
317 exactly the same as the .var statement:
327 Like a .var statement, the .net statement creates a VPI object with
328 the basename and dimensions given as parameters. The symbol is a
329 functor that feeds into the vector of the net, and the vpiHandle
330 holds references to that functor.
332 The input of a .net is replicated to its output. In this sense, it
333 acts like a diode. The purpose of this node is to hold various VPI
334 and event trappings. The .net and .net8 nodes are vector types. They
335 both may represent wires, but the .net8 nodes preserve strength values
336 that arrive through them, while .net nodes reduce strength values to
337 4-value logic. The .net8 nodes should only be used when strength
338 information really is possible.
341 represents. This label does not map to a functor, so only references
342 that know they want to access .nets are able to locate the symbol. In
343 particular, this includes behavioral %load and %wait instructions. The
344 references to net and reg objects are done through the .net label
345 instead of a general functor symbol. The instruction stores the
346 functor pointer, though.
348 The .alias statements do not create new nodes, but instead create net
349 names that are aliases of an existing node. This handles special cases
350 where a net has different names, possibly in different scopes.
352 MEMORY STATEMENTS:
354 Memories are arrays of words, each word a vvp_vector4_t vector of the
355 same width. The memory is canonically addressed as a 1-dimensional
356 array of words, although indices are stored with the memory for
357 calculating a canonical address from a multi-dimensional address.
360 connecting a read port to an existing memory, and (3) initializing the
361 memory's contents.
367 allowed for multidimensional indexing. This statement creates the
368 memory array and makes it available to procedural code.
370 Procedural access to the memory references the memory as single array
371 of words, with the base address==0, and the last address the size (in
372 words) of the memory -1. It is up to the compiler to convert Verilog
373 index sets to a canonical address. The multi-dimensional index set is
374 available for VPI use.
376 Structural read access is implemented in terms of address and data
377 ports. The addresses applied to the address port are expected to be
378 in canonical form.
380 A read port is a functor that takes a single input, the read address,
381 and outputs the word value at the given (canonical) address.
388 Any address input change, or any change in the addressed memory
389 contents, is immediately propagated to the port output.
391 A write port is a superset of a read port. It is a 4-input functor
392 that accepts the word address, an event input, a write enable input,
393 and the data input.
395 <label> .mem/port <memid>, <address>, <event>, <we>, <data> ;
399 port. For asynchronous transparent write operation, connect
403 There is no Verilog construct that calls for a structural write port
404 to a memory, but synthesis may ask for lpm_ram_d[pq] objects.
406 To initialize a memory, use:
411 address (canonical) of the first word to be initialized. The start
412 address allows multiple statements be used to initialize words of a
413 memory.
415 The values are one per word.
417 Procedural access to the memory employs an index register to address a
418 bit location in the memory, via the commands:
424 The memory bit is addressed by index register 3. The value of
426 word occupies a multiple of four bits.
429 EVENT STATEMENTS
431 Threads need to interact with the functors of a netlist synchronously,
432 as well as asynchronously. There are cases where the web of functors
433 needs to wake up a waiting thread. The web of functors signals threads
434 through .event objects, that are declared like so:
440 This event statement declares an object that a %wait instruction
441 can take as an operand. When a thread executes a %wait, it puts
442 itself in the notification list of the event and suspends. The
447 string, then this is a named event which receives events by the %set
448 instruction instead of from the output of a functor.
450 If the event has inputs (a requirement unless it is a named event)
451 then it has up to 4 symbols that address functors. The event then
452 detects the appropriate edge on any of the inputs and signals when the
453 event is true. Normally (in Verilog) a posedge or negedge event only
454 watches a single bit, so the generated code would only include a
455 single symbol for the addressed bit. However, if there are several
456 events of the same edge in an event OR expression, the compiler may
457 combine up to 4 into a single event.
459 If many more events need to be combined together (for example due to
460 an event or expression in the Verilog) then this form can be used:
464 In this case, the symbols list all the events that are to be combined
465 to trigger this event. Only one of the input events needs to trigger
466 to make this one go.
469 RESOLVER STATEMENTS:
471 Resolver statements are strength-aware functors with 4 inputs, but
472 their job typically is to calculate a resolved output using strength
473 resolution. The type of the functor is used to select a specific
474 resolution function.
480 The output from the resolver is vvp_vector8_t value. That is, the
481 result is a vector with strength included.
484 PART SELECT STATEMENTS:
486 Part select statements are functors with three inputs. They take in at
487 port-0 a vector, and output a selected (likely smaller) part of that
488 vector. The other inputs specify what those parts are, as a canonical
489 bit number, and a width. Normally, those bits are constant values.
495 The input is typically a .reg or .net, but can be any vector node in
496 the netlist.
498 The .part/pv variation is the inverse of the .part version, in that
499 the output is actually written to a *part* of the output. The node
500 uses special part-select-write functions to propagate a part of a
502 that part is written to. Destination nodes use this value to check
503 further output widths.
505 The .part/v variation takes a vector (or long) input on port-1 as the
506 base of the part select. Thus, the part select can move around.
508 PART CONCATENATION STATEMENTS:
510 The opposite of the part select statement is the part concatenation
511 statement. The .concat statement is a functor node that takes at input
512 vector values and produces a single vector output that is the
513 concatenation of all the inputs.
518 expected widths of all the inputs. These widths are needed to figure
519 the positions of the input vectors in the generated output, and are
520 listed in order LSB to MSB. The inputs themselves are also listed LSB
521 to MSB, with the LSB vector input coming through port-0 of the real
522 functor.
524 The initial output value is (W+X+Y+Z) bits of 'bx. As input values are
525 propagated, the bits are placed in the correct place in the output
526 vector value, and a new output value is propagated.
529 REPEAT VECTOR STATEMENTS:
531 The repeat vector statement is similar to the concatenation statement,
532 expect that the input is repeated a constant number of times. The
533 format of the repeat vector statement is:
539 vector value is repeated to make the output width. The input width is
542 REDUCTION LOGIC
544 The reduction logic statements take in a single vector, and propagate
545 a single bit.
554 the device has a single input, which is a vector of any width. The
555 device performs the logic on all the bits of the vector (a la Verilog)
556 and produces and propagates a single bit width vector.
558 EXPANSION LOGIC
560 Sign extension nodes are the opposite of reduction logic, in that they
561 take a narrow vector, or single bit, and pad it out to a wider
562 vector.
566 The .expand/s node takes an input symbol and sign-extends it to the
567 given width.
569 FORCE STATEMENTS (old method - remove me):
571 A force statement creates functors that represent a Verilog force
572 statement.
579 There will be as many force functors as there are symbols in the
582 To activate and deactivate a force on a single bit, use:
589 being forced.
591 FORCE STATEMENTS (new method - implement me):
593 A %force instruction, as described in the .var section, forces a
594 constant value onto a .var or .net, and the matching %release releases
595 that value. However, there are times when the value of a functor
596 (i.e. another .net) needs to be forced onto a .var or .net. For this
597 task, the %force/link instruction exists:
604 will automatically drive values to the force port of the destination
605 node. The matching %release/link instruction removes the link (a
606 %release is still needed) to the destination. The %release/link
607 releases the last %force/link, no matter where the link is from. A new
608 %force/link will remove a previous link.
610 The instructions:
615 are the same concept, but for the continuous assign port.
617 STRUCTURAL ARITHMETIC STATEMENTS:
619 The various Verilog arithmetic operators (+-*/%) are available to
620 structural contexts as two-input functors that take in vectors. All of
621 these operators take two inputs and generate a fixed width output. The
622 input vectors will be padded if needed to get the desired output width.
630 In all cases, there are no width limits, so long as the width is
631 fixed.
633 NOTE: The .arith/mult inputs are not necessarily the width of the
634 output. I have not decided how to handle this.
636 These devices support .s and .r suffixes. The .s means the node is a
637 signed vector device, the .r a real valued device.
639 STRUCTURAL COMPARE STATEMENTS:
641 The arithmetic statements handle various arithmetic operators that
642 have wide outputs, but the comparators have single bit output, so they
643 are implemented a bit differently. The syntax, however, is very
644 similar:
655 Whereas the arithmetic statements generate an output the width of
658 comparisons. (Equality doesn't need to care about sign.)
661 STRUCTURAL SHIFTER STATEMENTS:
663 Variable shifts in structural context are implemented with .shift
664 statements:
669 The shifter has a width that defines the vector width of the output, a
671 that is the amount to shift. The vectors that come from port 0 are the
672 data to be shifted and must have exactly the width of the output. The
673 input to port 1 is the amount to shift.
676 STRUCTURAL FUNCTION CALLS:
678 The .ufunc statement defines a call to a user defined function.
680 <label> .ufunc <flabel>, <wid>, <isymbols> ( <psymbols> ) <rsymbol> ;
683 function implementation. This is code that the simulator will branch
684 to.
689 function. These are points in the net, and the ufunc device watches
690 these nets for input changes.
694 the function. The ufunc performs an assignment to these variables
695 before calling the function.
698 result will be found when the function code ends. This value is picked
699 up and propagated to the output of the functor.
701 THREAD STATEMENTS:
703 Thread statements create the initial threads for a simulation. These
704 represent the initial and always blocks, and possibly other causes to
705 create threads at startup.
709 This statement creates a thread with a starting address at the
712 addressed instruction.
715 thread. Supported flags are:
717 $push -- Cause the thread to be pushed in the scheduler. This
718 only effects startup (time 0) by arranging for pushed
719 threads to be started before non-pushed threads. This
720 is useful for resolving time-0 races.
722 * Threads in general
724 Thread statements create the initial threads of a design. These
726 Verilog, and possibly some other synthetic threads for various
727 purposes. It is also possible to create transient threads from
728 behavioral code. These are needed to support such constructs as
729 fork/join, named blocks and task activation.
731 A transient thread is created with a %fork instruction. When a
732 transient thread is created this way, the operand to the %fork gives
733 the starting address, and the new thread is said to be a child of the
734 forking thread. The children of a thread are pushed onto a stack of
735 children. A thread can have only one direct child.
737 A transient thread is reaped with a %join instruction. %join waits for
738 the top thread in the stack of children to complete, then
739 continues. It is an error to %join when there are no children.
741 As you can see, the transient thread in VVP is a cross between a
742 conventional thread and a function call. In fact, there is no %call
743 instruction in vvp, the job is accomplished with %fork/%join in the
744 caller and %end in the callee. The %fork, then is simply a
745 generalization of a function call, where the caller does not
746 necessarily wait for the callee.
748 For all the behavior of threads and thread parentage to work
749 correctly, all %fork statements must have a corresponding %join in the
750 parent, and %end in the child. Without this proper matching, the
751 hierarchical relationships can get confused. The behavior of erroneous
752 code is undefined.
754 * Thread Context
756 The context of a thread is all the local data that only that thread
757 can address. The local data is broken into two addresses spaces: bit
758 memory and word memory.
761 addressed in strips of arbitrary length. For example, an 8-bit value
765 manufacture complex values elsewhere.
767 The word memory is a region of tagged words. The value in each word
768 may be native long or real. These words have a distinct address space
769 from the bits.
771 * Threads and scopes
773 The Verilog ``disable'' statement deserves some special mention
774 because of how it interacts with threads. In particular, threads
775 throughout the design can affect (end) other threads in the design
776 using the disable statement.
778 In Verilog, the operand to the disable statement is the name of a
779 scope. The behavior of the disable is to cause all threads executing
780 in the scope to end. Termination of a thread includes all the children
781 of the thread. In vvp, all threads are in a scope, so this is how the
782 disable gains access to the desired thread.
784 It is obvious how initial/always thread join a scope. They become part
785 of the scope simply by being declared after a .scope declaration. (See
786 vvp.txt for .scope declarations.) The .thread statement placed in the
787 assembly source after a .scope statement causes the thread to join the
788 named scope.
790 Transient threads join a scope that is the operand to the %fork
791 instruction. The scope is referenced by name, and the thread created
792 by the fork atomically joins that scope. Once the transient thread
793 joins the scope, it stays there until it ends. Threads never change
794 scopes, not even transient threads.
796 TRUTH TABLES
798 The logic that a functor represents is expressed as a truth table. The
799 functor has four inputs and one output. Each input and output has one
801 represent them. So the input of the functor is 8 bits, and the output
804 small enough that the table should take less space then the code to
805 implement the logic.
807 To implement the truth table, we need to assign 2-bit encodings for
808 the 4-value signals. I choose, pseudo-randomly, the following
809 encoding:
818 so:
819 332211
822 pairs in the 8-bit byte are the output:
826 A complete truth table, then is described as 64 8-bit bytes.
828 The vvp engine includes truth tables for the primitive gate types, so
829 none needs to be given by the programmer. It is sufficient to name the
830 type to get that truth table.
833 EXECUTABLE INSTRUCTIONS
835 Threads run executable code, much like a processor executes machine
836 code. VVP has a variety of opcodes for executable instructions. All of
838 space. Labels attached to executable instructions get assigned the
839 address of the instruction, and can be the target of %jmp instructions
840 and starting points for threads.
842 The opcodes.txt file has a more detailed description of all the
843 various instructions.
846 THE RELATIONSHIP BETWEEN FUNCTORS, THREADS AND EVENTS
848 Given the above summary of the major components of vvp, some
849 description of their relationship is warranted. Functors provide a
850 structural description of the design (so far as it can be described
851 structurally) and these functors run independently of the threads. In
852 particular, when an input to a functor is set, it calculates a new
853 output value; and if that output is different from the existing
854 output, a propagation event is created. Functor output is calculated
855 by truth table lookup, without the aid of threads.
857 Propagation events are one of three kinds of events in vvp. They are
858 scheduled to execute at some time, and they simply point to the functor
859 that is to have its output propagated. When the event expires, the
860 output of the referenced functor is propagated to all the inputs that
861 it is connected to, and those functors in turn create new events if
862 needed.
864 Assignment events (the second of three types of events) are created
866 executed (a %assign in vvp) an assign event is created, which includes
867 the vvp_ipoint_t pointer to the functor input to receive the value,
868 as well as the value. These are distinct from propagation events because:
870 a) There is no functor that has as its output the value to be
871 assigned (this is how values get into the functor net in
872 the first place), and
874 b) This allows for behavioral code to create waveforms of
875 arbitrary length that feed into a variable. Verilog allows
876 this of non-blocking assignments, but not of gate outputs.
878 The last type of event is the thread schedule event. This event simply
879 points to a thread to be executed. Threads are made up of a virtual
880 processor with a program counter and some private storage. Threads
881 can execute %assign instructions to create assignment events, and can
882 execute %set instructions to do blocking assignments. Threads can also
883 use %load to read the output of functors.
885 The core event scheduler takes these three kinds of events and calls
886 the right kind of code to cause things to happen in the design. If the
887 event is a propagate or assignment event, the network of functors is
888 tickled; if the event is a thread schedule, then a thread is run. The
889 implementation of the event queue is not important, but currently is
890 implemented as a ``skip list''. That is, it is a sorted singly linked
891 list with skip pointers that skip over delta-time events.
893 The functor net and the threads are distinct. They communicate through
894 thread instructions %set, %assign, %waitfor and %load. So far as a thread
895 is concerned, the functor net is a blob of structure that it pokes and
896 prods via certain functor access instructions.
899 VVP COMPILATION AND EXECUTION
901 The vvp program operates in a few steps:
903 1) Initialization
904 Data structures are cleared to empty, and tables are
905 readied for compilation.
907 2) Compilation
908 The input file is read and compiled. Symbol tables are
909 build up as needed, objects are allocated and linked
910 together.
912 3) Cleanup
913 Symbol tables and other resources used only for
914 compilation are released to reduce the memory
915 footprint.
917 4) Simulation
918 Event simulation is run.
921 The initialization step is performed by the compile_init() function in
922 compile.cc. This function in turn calls all the *_init() functions in
923 other parts of the source that need initialization for compile. All
926 Compilation is controlled by the parser, it parse.y. As the parser
927 reads and parses input, the compilation proceeds in the rules by
928 calling various compile_* functions. All these functions live in the
929 compile.cc file. Compilation calls other sections of the code as
930 needed.
932 When the parser completes compilation, compile_cleanup() is called to
933 finish the compilation process. Unresolved references are completed,
934 then all the symbol tables and other compile-time-only resources are
935 released. Once compile_cleanup() returns, there is no more use for the
936 parser for the function in compile.cc.
938 After cleanup, the simulation is started. This is done by executing
939 the schedule_simulate() function. This does any final setup and starts
940 the simulation running and the event queue running.
943 HOW TO GET FROM THERE TO HERE
945 The vvp simulation engine is designed to be able to take as input a
946 compiled form of Verilog. That implies that there is a compiler that
947 compiles Verilog into a form that the vvp engine can read.
950 * Boolean logic gates
952 Gates like AND, OR and NAND are implemented simply and obviously by
953 functor statements. Any logic up to 4 inputs can be implemented with a
954 single functor. For example:
956 and gate (out, i1, i2, i3);
958 becomes:
960 gate .functor and, i1, i2, i3;
962 Notice the first parameter of the .functor is the type. The type
963 includes a truth table that describes the output with a given
964 input. If the gate is wider then four inputs, then cascade
965 functors. For example:
967 and gate (out, i1, i2, i3, i4, i5, i6, i7, i8);
969 becomes:
971 gate.0 .functor and, i1, i2, i3, i4;
972 gate.1 .functor and, i5, i6, i7, i8;
976 * reg and other variables
978 Reg and integer are cases of what Verilog calls ``variables.''
979 Variables are, simply put, things that behavioral code can assign
980 to. These are not the same as ``nets,'' which include wires and the
981 like.
983 Each bit of a variable is created by a ``.var'' statement. For example:
985 reg a;
987 becomes:
992 * named events
994 Events in general are implemented as functors, but named events in
995 particular have no inputs and only the event output. The way to
996 generate code for these is like so:
1000 This creates a functor and makes it into a mode-2 functor. Then the
1002 generated. This is sufficient to trigger the event.
1004 /*
1005 * Copyright (c) 2001 Stephen Williams (steve@icarus.com)
1006 *
1007 * This source code is free software; you can redistribute it
1008 * and/or modify it in source code form under the terms of the GNU
1009 * General Public License as published by the Free Software
1010 * Foundation; either version 2 of the License, or (at your option)
1011 * any later version.
1012 *
1013 * This program is distributed in the hope that it will be useful,
1014 * but WITHOUT ANY WARRANTY; without even the implied warranty of
1015 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
1016 * GNU General Public License for more details.
1017 *
1018 * You should have received a copy of the GNU General Public License
1019 * along with this program; if not, write to the Free Software
1021 */</pre>
1023 </div>
1024 </div>
1025 </body>
1026 </html>