| blob | e3b3463c06f09babd50545d95a0cad9c1aa44df1 |
1 /*
2 * Copyright (c) 1998-2006 Stephen Williams (steve@icarus.com)
3 *
4 * This source code is free software; you can redistribute it
5 * and/or modify it in source code form under the terms of the GNU
6 * General Public License as published by the Free Software
7 * Foundation; either version 2 of the License, or (at your option)
8 * any later version.
9 *
10 * This program is distributed in the hope that it will be useful,
11 * but WITHOUT ANY WARRANTY; without even the implied warranty of
12 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
13 * GNU General Public License for more details.
14 *
15 * You should have received a copy of the GNU General Public License
16 * along with this program; if not, write to the Free Software
17 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
18 */
19 #ifdef HAVE_CVS_IDENT
21 #endif
25 /*
26 * Elaboration takes as input a complete parse tree and the name of a
27 * root module, and generates as output the elaborated design. This
28 * elaborated design is presented as a Module, which does not
29 * reference any other modules. It is entirely self contained.
30 */
32 # include <typeinfo>
33 # include <sstream>
34 # include <list>
48 {
62 }
64 }
68 {
71 }
73 /*
74 * Elaborate the continuous assign. (This is *not* the procedural
75 * assign.) Elaborate the lvalue and rvalue, and do the assignment.
76 */
78 {
90 /* Normally, l-values to continuous assignments are NOT allowed
91 to implicitly declare nets. However, so many tools do allow
92 it that Icarus Verilog will allow it, at least if extensions
93 are enabled. */
98 /* Elaborate the l-value. */
102 }
110 }
112 /* Handle the special case that the rval is simply an
113 identifier. Get the rval as a NetNet, then use NetBUFZ
114 objects to connect it to the l-value. This is necessary to
115 direct drivers. This is how I attach strengths to the
116 assignment operation. */
124 }
132 }
135 /* If the right hand net is the same type as the left
136 side net (i.e., WIRE/WIRE) then it is enough to just
137 connect them together. Otherwise, put a bufz between
138 them to carry strengths from the rval.
140 While we are at it, handle the case where the r-value
141 is not as wide as the l-value by padding with a
142 constant-0. */
150 /* If the device is linked to itself, a driver is
151 needed. Should I print a warning here? */
155 /* If the nets are different type (i.e., reg vs. tri) then
156 a driver is needed. */
160 /* If there is a delay, then I need a driver to carry
161 it. */
165 /* If there is a strength to be carried, then I need a
166 driver to carry that strength. */
173 /* If the r-value is more narrow then the l-value, pad
174 it to the desired width. */
197 }
209 }
213 /* Don't need a driver, presumably because the
214 r-value already has the needed drivers. Just
215 hook things up. If the r-value is too narrow
216 for the l-value, then sign extend it or zero
217 extend it, whichever makes sense. */
223 }
228 /* Do need a driver. Use BUFZ objects to carry the
229 strength and delays. */
237 else
241 else
245 else
248 }
261 }
264 }
266 /* Elaborate the r-value. Account for the initial decays,
267 which are going to be attached to the last gate before the
268 generated NetNet. */
278 }
284 }
289 /* If the r-value insists on being smaller then the l-value
290 (perhaps it is explicitly sized) the pad it out to be the
291 right width so that something is connected to all the bits
292 of the l-value. */
296 /* If, on the other hand, the r-value insists on being
297 LARGER then the l-value, use a part select to chop it down
298 down to size. */
310 }
317 }
319 /*
320 * Elaborate a Builtin gate. These normally get translated into
321 * NetLogic nodes that reflect the particular logic function.
322 */
324 {
333 /* If the Verilog source has a range specification for the
334 gates, then I am expected to make more than one
335 gate. Figure out how many are desired. */
348 }
355 }
365 else
375 }
376 }
378 /* Now we have a gate count. Elaborate the output expression
379 only. We do it early so that we can see if we can make a
380 wide gate instead of an array of gates. */
385 /* Detect the special case that the l-value width exactly
386 matches the gate count. In this case, we will make a single
387 gate that has the desired vector width. */
394 "Collapsed gate array into single wide "
396 }
398 /* Allocate all the netlist nodes for the gates. */
402 /* Calculate the gate delays from the delay expressions
403 given in the source. For logic gates, the decay time
404 is meaningless because it can never go to high
405 impedance. However, the bufif devices can generate
406 'bz output, so we will pretend that anything can.
408 If only one delay value expression is given (i.e., #5
409 nand(foo,...)) then rise, fall and decay times are
410 all the same value. If two values are given, rise and
411 fall times are use, and the decay time is the minimum
412 of the rise and fall times. Finally, if all three
413 values are given, they are taken as specified. */
423 /* Now make as many gates as the bit count dictates. Give each
424 a unique name, and set the delay times. */
427 ostringstream tmp;
431 else
515 }
529 }
534 /* The gates have all been allocated, this loop runs through
535 the parameters and attaches the ports of the objects. */
540 ? lval_sig
548 /* Handle the case where there is one gate that
549 carries the whole vector width. */
554 NetReplicate*rep
557 instance_width,
558 instance_width);
570 }
580 }
585 /* Handle the case where a single bit is connected
586 repetitively to all the instances. */
592 /* Handle the general case that each bit of the
593 value is connected to a different instance. In
594 this case, the output is handled slightly
595 different from the inputs. */
600 count);
603 /* Connect the concat to the signal. */
606 /* Connect the outputs of the gates to the concat. */
616 }
619 /* Use part selects to get the bits
620 connected to the inputs of out gate. */
632 }
640 }
642 }
643 }
645 /*
646 * Instantiate a module by recursively elaborating it. Set the path of
647 * the recursive elaboration so that signal names get properly
648 * set. Connect the ports of the instantiated module to the signals of
649 * the parameters. This is done with BUFZ gates so that they look just
650 * like continuous assignment connections.
651 */
653 {
661 }
663 // This is the array of pin expressions, shuffled to match the
664 // order of the declaration. If the source instantiation uses
665 // bind by order, this is the same as the source list.Otherwise,
666 // the source list is rearranged by name binding into this list.
669 // If the instance has a pins_ member, then we know we are
670 // binding by name. Therefore, make up a pins array that
671 // reflects the positions of the named ports.
675 // Scan the bindings, matching them with port names.
678 // Given a binding, look at the module port names
679 // for the position that matches the binding name.
682 // If the port name doesn't exist, the find_port
683 // method will return the port count. Detect that
684 // as an error.
691 }
693 // If I already bound something to this port, then
694 // the pins array will already have a pointer
695 // value where I want to place this expression.
699 endl;
702 }
704 // OK, do the binding by placing the expression in
705 // the right place.
707 }
712 /* Handle the special case that no ports are
713 connected. It is possible that this is an empty
714 connect-by-name list, so we'll allow it and assume
715 that is the case. */
722 /* Otherwise, this is a positional list of port
723 connections. In this case, the port count must be
724 right. Check that is is, the get the pin list. */
733 }
735 // No named bindings, just use the positional list I
736 // already have.
739 }
741 // Elaborate these instances of the module. The recursive
742 // elaboration causes the module to generate a netlist with
743 // the ports represented by NetNet objects. I will find them
744 // later.
749 }
753 // Now connect the ports of the newly elaborated designs to
754 // the expressions that are the instantiation parameters. Scan
755 // the pins, elaborate the expressions attached to them, and
756 // bind them to the port of the elaborated module.
758 // This can get rather complicated because the port can be
759 // unconnected (meaning an empty parameter is passed) connected
760 // to a concatenation, or connected to an internally
761 // unconnected port.
765 // Skip unconnected module ports. This happens when a
766 // null parameter is passed in.
770 // While we're here, look to see if this
771 // unconnected (from the outside) port is an
772 // input. If so, consider printing a port binding
773 // warning.
791 }
792 }
795 }
798 // Inside the module, the port is zero or more signals
799 // that were already elaborated. List all those signals
800 // and the NetNet equivalents, for all the instances.
808 }
810 // Count the internal vector bits of the port.
816 // Scan the module sub-ports for this instance...
828 }
829 }
831 // If I find that the port is unconnected inside the
832 // module, then there is nothing to connect. Skip the
833 // argument.
836 }
838 // We know by design that each instance has the same
839 // width port. Therefore, the prts_pin_count must be an
840 // even multiple of the instance count.
847 // Elaborate the expression that connects to the
848 // module[s] port. sig is the thing outside the module
849 // that connects to the port.
855 /* Input to module. elaborate the expression to
856 the desired width. If this in an instance
857 array, then let the net determine it's own
858 width. We use that, then, to decide how to hook
859 it up.
861 NOTE that this also handles the case that the
862 port is actually empty on the inside. We assume
863 in that case that the port is input. */
866 desired_vector_width,
873 }
877 /* Inout to/from module. This is a more
878 complicated case, where the expression must be
879 an lnet, but also an r-value net.
881 Normally, this winds up being the same as if we
882 just elaborated as an lnet, as passing a simple
883 identifier elaborates to the same NetNet in
884 both cases so the extra elaboration has no
885 effect. But if the expression passed to the
886 inout port is a part select, aspecial part
887 select must be created that can paqss data in
888 both directions.
890 Use the elaborate_bi_net method to handle all
891 the possible cases. */
903 }
908 /* Port type must be OUTPUT here. */
910 /* Output from module. Elaborate the port
911 expression as the l-value of a continuous
912 assignment, as the port will continuous assign
913 into the port. */
925 }
927 }
931 #ifndef NDEBUG
935 }
936 #endif
938 /* If we are working with an instance array, then the
939 signal width must match the port width exactly. */
950 }
956 }
958 // Check that the parts have matching pin counts. If
959 // not, they are different widths. Note that idx is 0
960 // based, but users count parameter positions from 1.
980 }
981 }
983 // Connect the sig expression that is the context of the
984 // module instance to the ports of the elaborated module.
986 // The prts_pin_count variable is the total width of the
987 // port and is the maximum number of connections to
988 // make. sig is the elaborated expression that connects
989 // to that port. If sig has too few pins, then reduce
990 // the number of connections to make.
992 // Connect this many of the port pins. If the expression
993 // is too small, then reduce the number of connects.
998 // The spin_modulus is the width of the signal (not the
999 // port) if this is an instance array. This causes
1000 // signals wide enough for a single instance to be
1001 // connected to all the instances.
1006 // Now scan the concatenation that makes up the port,
1007 // connecting pins until we run out of port pins or sig
1008 // pins. The sig object is the NetNet that is connected
1009 // to the port from the outside, and the prts object is
1010 // an array of signals to be connected to the sig.
1017 // The simplest case, there are no
1018 // parts/concatenations on the inside of the
1019 // module, so the port and sig need simply be
1020 // connected directly.
1032 }
1034 // The signal width is exactly the width of a
1035 // single instance of the port. In this case,
1036 // connect the sig to all the ports identically.
1043 prts_vector_width,
1050 }
1061 }
1071 }
1088 }
1090 }
1092 }
1094 /*
1095 * From a UDP definition in the source, make a NetUDP
1096 * object. Elaborate the pin expressions as netlists, then connect
1097 * those networks to the pins.
1098 */
1101 {
1108 /* When the parser notices delay expressions in front of a
1109 module or primitive, it interprets them as parameter
1110 overrides. Correct that misconception here. */
1112 PDelays tmp_del;
1124 }
1134 }
1144 }
1146 }
1166 // This is the array of pin expressions, shuffled to match the
1167 // order of the declaration. If the source instantiation uses
1168 // bind by order, this is the same as the source
1169 // list. Otherwise, the source list is rearranged by name
1170 // binding into this list.
1173 // Detect binding by name. If I am binding by name, then make
1174 // up a pins array that reflects the positions of the named
1175 // ports. If this is simply positional binding in the first
1176 // place, then get the binding from the base class.
1181 // Scan the bindings, matching them with port names.
1184 // Given a binding, look at the module port names
1185 // for the position that matches the binding name.
1188 // If the port name doesn't exist, the find_port
1189 // method will return the port count. Detect that
1190 // as an error.
1197 }
1199 // If I already bound something to this port, then
1200 // the (*exp) array will already have a pointer
1201 // value where I want to place this expression.
1205 endl;
1208 }
1210 // OK, do the binding by placing the expression in
1211 // the right place.
1213 }
1217 /* Otherwise, this is a positional list of port
1218 connections. In this case, the port count must be
1219 right. Check that is is, the get the pin list. */
1228 }
1230 // No named bindings, just use the positional list I
1231 // already have.
1234 }
1237 /* Handle the output port of the primitive special. It is an
1238 output port (the only output port) so must be passed an
1239 l-value net. */
1255 }
1256 }
1258 /* Run through the pins, making netlists for the pin
1259 expressions and connecting them to the pin in question. All
1260 of this is independent of the nature of the UDP. */
1270 }
1273 }
1275 // All done. Add the object to the design.
1277 }
1281 {
1282 // Look for the module type
1288 }
1292 {
1293 // Look for the module type
1298 }
1300 // Try a primitive type
1306 }
1310 }
1313 {
1314 // Look for the module type
1319 }
1321 // Try a primitive type
1326 // Not a module or primitive that I know about yet, so try to
1327 // load a library module file (which parses some new Verilog
1328 // code) and try again.
1331 // Try again to find the module type
1336 }
1338 // Try again to find a primitive type
1342 }
1345 // Not a module or primitive that I know about or can find by
1346 // any means, so give up.
1350 }
1354 {
1360 }
1364 {
1367 }
1369 /*
1370 * This function elaborates delay expressions. This is a little
1371 * different from normal elaboration because the result may need to be
1372 * scaled.
1373 */
1375 {
1378 /* If the delay expression is a real constant or vector
1379 constant, then evaluate it, scale it to the local time
1380 units, and return an adjusted NetEConst. */
1392 }
1403 }
1406 /* The expression is not constant, so generate an expanded
1407 expression that includes the necessary scale shifts, and
1408 return that expression. */
1415 }
1419 }
1426 }
1430 }
1433 }
1436 {
1439 /* elaborate the lval. This detects any part selects and mux
1440 expressions that might exist. */
1444 /* If there is an internal delay expression, elaborate it. */
1452 /* Elaborate the r-value expression, then try to evaluate it. */
1454 /* Find out what the r-value width is going to be. We guess it
1455 will be the l-value width, but it may turn out to be
1456 something else based on self-determined widths inside. */
1461 /* Now elaborate to the expected width. Pass the lwidth to
1462 prune any constant result to fit with the lvalue at hand. */
1468 /* Rewrite delayed assignments as assignments that are
1469 delayed. For example, a = #<d> b; becomes:
1471 begin
1472 tmp = b;
1473 #<d> a = tmp;
1474 end
1476 If the delay is an event delay, then the transform is
1477 similar, with the event delay replacing the time delay. It
1478 is an event delay if the event_ member has a value.
1480 This rewriting of the expression allows me to not bother to
1481 actually and literally represent the delayed assign in the
1482 netlist. The compound statement is exactly equivalent. */
1494 //XXXX delete rv;
1496 }
1505 /* Generate an assignment of the l-value to the temporary... */
1511 /* Generate an assignment of the temporary to the r-value... */
1515 /* Generate the delay statement with the final
1516 assignment attached to it. If this is an event delay,
1517 elaborate the PEventStatement. Otherwise, create the
1518 right NetPDelay object. */
1524 "unable to elaborate event expression."
1528 }
1535 }
1537 /* And build up the complex statement. */
1543 }
1545 /* Based on the specific type of the l-value, do cleanup
1546 processing on the r-value. */
1549 // The r-value is a real. Casting will happen in the
1550 // code generator, so leave it.
1557 }
1563 }
1565 /*
1566 * Elaborate non-blocking assignments. The statement is of the general
1567 * form:
1568 *
1569 * <lval> <= #<delay> <rval> ;
1570 */
1572 {
1580 }
1582 /* Elaborate the l-value. */
1588 /* Elaborate and precalculate the r-value. */
1593 /* Handle the (common) case that the r-value is a vector. This
1594 includes just about everything but reals. In this case, we
1595 need to pad the r-value to match the width of the l-value.
1597 If in this case the l-val is a variable (i.e. real) then
1598 the width to pad to will be 0, so this code is harmless. */
1605 }
1611 /* All done with this node. Mark its line number and check it in. */
1616 }
1619 /*
1620 * This is the elaboration method for a begin-end block. Try to
1621 * elaborate the entire block, even if it fails somewhere. This way I
1622 * get all the error messages out of it. Then, if I detected a failure
1623 * then pass the failure up.
1624 */
1626 {
1642 }
1646 }
1653 // Handle the special case that the block contains only one
1654 // statement. There is no need to keep the block node. Also,
1655 // don't elide named blocks, because they might be referenced
1656 // elsewhere.
1661 }
1666 // If the statement fails to elaborate, then simply
1667 // ignore it. Presumably, the elaborate for the
1668 // statement already generated an error message and
1669 // marked the error count in the design so no need to
1670 // do any of that here.
1673 }
1675 // If the result turns out to be a noop, then skip it.
1680 }
1683 }
1686 }
1688 /*
1689 * Elaborate a case statement.
1690 */
1692 {
1700 }
1702 /* Count the items in the case statement. Note that there may
1703 be some cases that have multiple guards. Count each as a
1704 separate item. */
1711 else
1713 }
1718 /* Iterate over all the case items (guard/statement pairs)
1719 elaborating them. If the guard has no expression, then this
1720 is a "default" cause. Otherwise, the guard has one or more
1721 expressions, and each guard is a case. */
1729 /* If there are no expressions, then this is the
1730 default case. */
1740 /* If there are one or more expressions, then
1741 iterate over the guard expressions, elaborating
1742 a separate case for each. (Yes, the statement
1743 will be elaborated again for each.) */
1754 }
1755 }
1758 }
1761 {
1768 // Elaborate and try to evaluate the conditional expression.
1775 }
1777 // If the condition of the conditional statement is constant,
1778 // then look at the value and elaborate either the if statement
1779 // or the else statement. I don't need both. If there is no
1780 // else_ statement, the use an empty block as a noop.
1786 }
1800 }
1803 else
1805 }
1807 // If the condition expression is more than 1 bits, then
1808 // generate a comparison operator to get the result down to
1809 // one bit. Turn <e> into <e> != 0;
1815 }
1824 }
1826 // Well, I actually need to generate code to handle the
1827 // conditional, so elaborate.
1831 // Detect the special cases that the if or else statements are
1832 // empty blocks. If this is the case, remove the blocks as
1833 // null statements.
1838 }
1839 }
1845 }
1846 }
1851 }
1854 {
1857 else
1859 }
1861 /*
1862 * A call to a system task involves elaborating all the parameters,
1863 * then passing the list to the NetSTask object.
1864 *XXXX
1865 * There is a single special case in the call to a system
1866 * task. Normally, an expression cannot take an unindexed
1867 * memory. However, it is possible to take a system task parameter a
1868 * memory if the expression is trivial.
1869 */
1871 {
1876 /* Catch the special case that the system task has no
1877 parameters. The "()" string will be parsed as a single
1878 empty parameter, when we really mean no parameters at all. */
1888 /* Attempt to pre-evaluate the parameters. It may be
1889 possible to at least partially reduce the
1890 expression. */
1895 }
1896 }
1897 }
1901 }
1903 /*
1904 * A call to a user defined task is different from a call to a system
1905 * task because a user task in a netlist has no parameters: the
1906 * assignments are done by the calling thread. For example:
1907 *
1908 * task foo;
1909 * input a;
1910 * output b;
1911 * [...]
1912 * endtask;
1913 *
1914 * [...] foo(x, y);
1915 *
1916 * is really:
1917 *
1918 * task foo;
1919 * reg a;
1920 * reg b;
1921 * [...]
1922 * endtask;
1923 *
1924 * [...]
1925 * begin
1926 * a = x;
1927 * foo;
1928 * y = b;
1929 * end
1930 */
1932 {
1940 }
1948 }
1959 }
1968 }
1972 /* Handle tasks with no parameters specially. There is no need
1973 to make a sequential block to hold the generated code. */
1978 }
1983 /* Detect the case where the definition of the task is known
1984 empty. In this case, we need not bother with calls to the
1985 task, all the assignments, etc. Just return a no-op. */
1990 }
1992 /* Generate assignment statement statements for the input and
1993 INOUT ports of the task. These are managed by writing
1994 assignments with the task port the l-value and the passed
1995 expression the r-value. We know by definition that the port
1996 is a reg type, so this elaboration is pretty obvious. */
2013 }
2015 /* Generate the task call proper... */
2021 /* Generate assignment statements for the output and INOUT
2022 ports of the task. The l-value in this case is the
2023 expression passed as a parameter, and the r-value is the
2024 port to be copied out.
2026 We know by definition that the r-value of this copy-out is
2027 the port, which is a reg. The l-value, however, may be any
2028 expression that can be a target to a procedural
2029 assignment, including a memory word. */
2035 /* Skip input ports. */
2041 /* Elaborate an l-value version of the port expression
2042 for output and inout ports. If the expression does
2043 not exist then quietly skip it, but if the expression
2044 is not a valid l-value print an error message. Note
2045 that the elaborate_lval method already printed a
2046 detailed message. */
2054 }
2057 }
2065 /* Generate the assignment statement. */
2069 }
2072 }
2074 /*
2075 * Elaborate a procedural continuous assign. This really looks very
2076 * much like other procedural assignments, at this point, but there
2077 * is no delay to worry about. The code generator will take care of
2078 * the differences between continuous assign and normal assignments.
2079 */
2081 {
2106 }
2110 }
2113 {
2123 }
2125 /*
2126 * Elaborate the delay statement (of the form #<expr> <statement>) as a
2127 * NetPDelay object. If the expression is constant, evaluate it now
2128 * and make a constant delay. If not, then pass an elaborated
2129 * expression to the constructor of NetPDelay so that the code
2130 * generator knows to evaluate the expression at run time.
2131 */
2133 {
2141 }
2143 /* This call evaluates the delay expression to a NetEConst, if
2144 possible. This includes transforming NetECReal values to
2145 integers, and applying the proper scaling. */
2152 else
2160 else
2162 }
2164 }
2166 /*
2167 * The disable statement is not yet supported.
2168 */
2170 {
2181 }
2196 }
2201 }
2203 /*
2204 * An event statement is an event delay of some sort, attached to a
2205 * statement. Some Verilog examples are:
2206 *
2207 * @(posedge CLK) $display("clock rise");
2208 * @event_1 $display("event triggered.");
2209 * @(data or negedge clk) $display("data or clock fall.");
2210 *
2211 * The elaborated netlist uses the NetEvent, NetEvWait and NetEvProbe
2212 * classes. The NetEvWait class represents the part of the netlist
2213 * that is executed by behavioral code. The process starts waiting on
2214 * the NetEvent when it executes the NetEvWait step. Net NetEvProbe
2215 * and NetEvTrig are structural and behavioral equivalents that
2216 * trigger the event, and awakens any processes blocking in the
2217 * associated wait.
2218 *
2219 * The basic data structure is:
2220 *
2221 * NetEvWait ---/---> NetEvent <----\---- NetEvProbe
2222 * ... | | ...
2223 * NetEvWait ---+ +---- NetEvProbe
2224 * | ...
2225 * +---- NetEvTrig
2226 *
2227 * That is, many NetEvWait statements may wait on a single NetEvent
2228 * object, and Many NetEvProbe objects may trigger the NetEvent
2229 * object. The many NetEvWait objects pointing to the NetEvent object
2230 * reflects the possibility of different places in the code blocking
2231 * on the same named event, like so:
2232 *
2233 * event foo;
2234 * [...]
2235 * always begin @foo <statement1>; @foo <statement2> end
2236 *
2237 * This tends to not happen with signal edges. The multiple probes
2238 * pointing to the same event reflect the possibility of many
2239 * expressions in the same blocking statement, like so:
2240 *
2241 * wire reset, clk;
2242 * [...]
2243 * always @(reset or posedge clk) <stmt>;
2244 *
2245 * Conjunctions like this cause a NetEvent object be created to
2246 * represent the overall conjunction, and NetEvProbe objects for each
2247 * event expression.
2248 *
2249 * If the NetEvent object represents a named event from the source,
2250 * then there are NetEvTrig objects that represent the trigger
2251 * statements instead of the NetEvProbe objects representing signals.
2252 * For example:
2253 *
2254 * event foo;
2255 * always @foo <stmt>;
2256 * initial begin
2257 * [...]
2258 * -> foo;
2259 * [...]
2260 * -> foo;
2261 * [...]
2262 * end
2263 *
2264 * Each trigger statement in the source generates a separate NetEvTrig
2265 * object in the netlist. Those trigger objects are elaborated
2266 * elsewhere.
2267 *
2268 * Additional complications arise when named events show up in
2269 * conjunctions. An example of such a case is:
2270 *
2271 * event foo;
2272 * wire bar;
2273 * always @(foo or posedge bar) <stmt>;
2274 *
2275 * Since there is by definition a NetEvent object for the foo object,
2276 * this is handled by allowing the NetEvWait object to point to
2277 * multiple NetEvent objects. All the NetEvProbe based objects are
2278 * collected and pointed as the synthetic NetEvent object, and all the
2279 * named events are added into the list of NetEvent object that the
2280 * NetEvWait object can refer to.
2281 */
2285 {
2293 }
2295 /* Create a single NetEvent and NetEvWait. Then, create a
2296 NetEvProbe for each conjunctive event in the event
2297 list. The NetEvProbe objects all refer back to the NetEvent
2298 object. */
2307 /* If there are no expressions, this is a signal that it is an
2308 @* statement. Generate an expression to use. */
2319 }
2326 }
2343 /* If the expression is an identifier that matches a
2344 named event, then handle this case all at once at
2345 skip the rest of the expression handling. */
2358 }
2359 }
2362 /* So now we have a normal event expression. Elaborate
2363 the sub-expression as a net and decide how to handle
2364 the edge. */
2376 }
2401 }
2408 }
2410 /* If there was at least one conjunction that was an
2411 expression (and not a named event) then add this
2412 event. Otherwise, we didn't use it so delete it. */
2416 /* NOTE: This event that I am adding to the wait may be
2417 a duplicate of another event somewhere else. However,
2418 I don't know that until all the modules are hooked
2419 up, so it is best to leave find_similar_event to
2420 after elaboration. */
2423 }
2426 }
2428 /*
2429 * This is the special case of the event statement, the wait
2430 * statement. This is elaborated into a slightly more complicated
2431 * statement that uses non-wait statements:
2432 *
2433 * wait (<expr>) <statement>
2434 *
2435 * becomes
2436 *
2437 * begin
2438 * while (1 !== <expr>)
2439 * @(<expr inputs>) <noop>;
2440 * <statement>;
2441 * end
2442 */
2445 {
2454 }
2458 /* Elaborate wait expression. Don't eval yet, we will do that
2459 shortly, after we apply a reduction or. */
2466 }
2468 // If the condition expression is more than 1 bits, then
2469 // generate a reduction operator to get the result down to
2470 // one bit. In other words, Turn <e> into |<e>;
2476 }
2482 }
2484 /* precalculate as much as possible of the wait expression. */
2488 }
2490 /* Detect the unusual case that the wait expression is
2491 constant. Constant true is OK (it becomes transparent) but
2492 constant false is almost certainly not what is intended. */
2498 /* Constant true -- wait(1) <s1> reduces to <s1>. */
2503 }
2505 /* Otherwise, false. wait(0) blocks permanently. */
2512 /* Create an event wait and an otherwise unreferenced
2513 event variable to force a perpetual wait. */
2524 }
2526 /* Invert the sense of the test with an exclusive NOR. In
2527 other words, if this adjusted expression returns TRUE, then
2528 wait. */
2535 }
2550 }
2557 }
2571 /* If there is no real substatement (i.e., "wait (foo) ;") then
2572 we are done. */
2576 /* Create a sequential block to combine the wait loop and the
2577 delayed statement. */
2584 }
2588 {
2598 }
2604 }
2606 /*
2607 * Forever statements are represented directly in the netlist. It is
2608 * theoretically possible to use a while structure with a constant
2609 * expression to represent the loop, but why complicate the code
2610 * generators so?
2611 */
2613 {
2619 }
2621 /*
2622 * Force is like a procedural assignment, most notably prodedural
2623 * continuous assignment:
2624 *
2625 * force <lval> = <rval>
2626 *
2627 * The <lval> can be anything that a normal behavioral assignment can
2628 * take, plus net signals. This is a little bit more lax then the
2629 * other proceedural assignments.
2630 */
2632 {
2657 }
2661 }
2663 /*
2664 * elaborate the for loop as the equivalent while loop. This eases the
2665 * task for the target code generator. The structure is:
2666 *
2667 * begin : top
2668 * name1_ = expr1_;
2669 * while (cond_) begin : body
2670 * statement_;
2671 * name2_ = expr2_;
2672 * end
2673 * end
2674 */
2676 {
2688 /* make the expression, and later the initial assignment to
2689 the condition variable. The statement in the for loop is
2690 very specifically an assignment. */
2697 }
2701 /* Calculate the width of the initialization as if this were
2702 any other assignment statement. */
2707 /* Make the r-value of the initial assignment, and size it
2708 properly. Then use it to build the assignment statement. */
2717 }
2727 /* Elaborate the statement that is contained in the for
2728 loop. If there is an error, this will return 0 and I should
2729 skip the append. No need to worry, the error has been
2730 reported so it's OK that the netlist is bogus. */
2736 /* Elaborate the increment assignment statement at the end of
2737 the for loop. This is also a very specific assignment
2738 statement. Put this into the "body" block. */
2745 }
2750 /* Make the rvalue of the increment expression, and size it
2751 for the lvalue. */
2759 /* Elaborate the condition expression. Try to evaluate it too,
2760 in case it is a constant. This is an interesting case
2761 worthy of a warning. */
2766 }
2771 }
2774 /* All done, build up the loop. */
2780 }
2782 /*
2783 * (See the PTask::elaborate methods for basic common stuff.)
2784 *
2785 * The return value of a function is represented as a reg variable
2786 * within the scope of the function that has the name of the
2787 * function. So for example with the function:
2788 *
2789 * function [7:0] incr;
2790 * input [7:0] in1;
2791 * incr = in1 + 1;
2792 * endfunction
2793 *
2794 * The scope of the function is <parent>.incr and there is a reg
2795 * variable <parent>.incr.incr. The elaborate_1 method is called with
2796 * the scope of the function, so the return reg is easily located.
2797 *
2798 * The function parameters are all inputs, except for the synthetic
2799 * output parameter that is the return value. The return value goes
2800 * into port 0, and the parameters are all the remaining ports.
2801 */
2804 {
2811 }
2821 }
2824 }
2827 {
2837 }
2840 {
2849 }
2854 // If the expression is a constant, handle certain special
2855 // iteration counts.
2868 }
2869 }
2873 }
2875 /*
2876 * A task definition is elaborated by elaborating the statement that
2877 * it contains, and connecting its ports to NetNet objects. The
2878 * netlist doesn't really need the array of parameters once elaboration
2879 * is complete, but this is the best place to store them.
2880 *
2881 * The first elaboration pass finds the reg objects that match the
2882 * port names, and creates the NetTaskDef object. The port names are
2883 * in the form task.port.
2884 *
2885 * task foo;
2886 * output blah;
2887 * begin <body> end
2888 * endtask
2889 *
2890 * So in the foo example, the PWire objects that represent the ports
2891 * of the task will include a foo.blah for the blah port. This port is
2892 * bound to a NetNet object by looking up the name. All of this is
2893 * handled by the PTask::elaborate_sig method and the results stashed
2894 * in the created NetTaskDef attached to the scope.
2895 *
2896 * Elaboration pass 2 for the task definition causes the statement of
2897 * the task to be elaborated and attached to the NetTaskDef object
2898 * created in pass 1.
2899 *
2900 * NOTE: I am not sure why I bothered to prepend the task name to the
2901 * port name when making the port list. It is not really useful, but
2902 * that is what I did in pform_make_task_ports, so there it is.
2903 */
2906 {
2922 }
2923 }
2926 }
2929 {
2944 }
2951 }
2956 }
2958 /*
2959 * The while loop is fairly directly represented in the netlist.
2960 */
2962 {
2966 }
2969 {
2973 }
2983 }
2986 // Evaluate the attributes for this process, if there
2987 // are any. These attributes are to be attached to the
2988 // NetProcTop object.
3002 /* Detect the special case that this is a combinational
3003 always block. We want to attach an _ivl_schedule_push
3004 attribute to this process so that it starts up and
3005 gets into its wait statement before non-combinational
3006 code is executed. */
3029 }
3039 }
3042 {
3046 /* Do not elaborate specify delay paths if this feature is
3047 turned off. */
3051 /* Check for various path types that are not supported. */
3059 }
3069 /* Elaborate the delay values themselves. Remember to scale
3070 them for the timescale/precision of the scope. */
3088 }
3090 }
3105 }
3114 // FIXME: Look for constant expressions here?
3116 // Get a net form.
3119 }
3121 /* Create all the various paths from the path specifier. */
3131 }
3139 }
3147 }
3153 // The presence of the data_source_expression indicates
3154 // that this is an edge sensitive path. If so, then set
3155 // the edges. Note that edge==0 is BOTH edges.
3159 }
3185 }
3200 }
3204 }
3210 }
3212 }
3214 /*
3215 * When a module is instantiated, it creates the scope then uses this
3216 * method to elaborate the contents of the module.
3217 */
3219 {
3223 // Elaborate specparams
3257 }
3262 }
3263 }
3265 // Elaborate within the generate blocks.
3270 }
3272 // Elaborate functions.
3281 }
3283 // Elaborate the task definitions. This is done before the
3284 // behaviors so that task calls may reference these, and after
3285 // the signals so that the tasks can reference them.
3294 }
3296 // Get all the gates of the module and elaborate them by
3297 // connecting them to the signals. The gate may be simple or
3298 // complex.
3306 }
3308 // Elaborate the behaviors, making processes out of them. This
3309 // involves scanning the PProcess* list, creating a NetProcTop
3310 // for each process.
3317 }
3319 // Elaborate the specify paths of the module.
3325 }
3328 }
3331 {
3339 // Check that this scope is one that is contained in the
3340 // container that the caller passed in.
3349 }
3352 }
3355 {
3365 }
3370 };
3373 {
3378 // This is the output design. I fill it in as I scan the root
3379 // module and elaborate what I find.
3382 // Scan the root modules, and elaborate their scopes.
3387 // Look for the root module in the list.
3396 }
3398 // Get the module definition for this root instance.
3401 // Make the root scope.
3410 // Recursively elaborate from this root scope down. This
3411 // does a lot of the grunt work of creating sub-scopes, etc.
3415 }
3421 }
3423 // Errors already? Probably missing root modules. Just give up
3424 // now and return nothing.
3428 // This method recurses through the scopes, looking for
3429 // defparam assignments to apply to the parameters in the
3430 // various scopes. This needs to be done after all the scopes
3431 // and basic parameters are taken care of because the defparam
3432 // can assign to a parameter declared *after* it.
3436 // At this point, all parameter overrides are done. Scan the
3437 // scopes and evaluate the parameters all the way down to
3438 // constants.
3441 // With the parameters evaluated down to constants, we have
3442 // what we need to elaborate signals and memories. This pass
3443 // creates all the NetNet and NetMemory objects for declared
3444 // objects.
3452 }
3453 }
3455 // Now that the structure and parameters are taken care of,
3456 // run through the pform again and generate the full netlist.
3462 }
3468 }
3471 }