| blob | 1e78e134201a553a4b03b464faa5055bc8095403 |
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. */
387 }
391 /* Detect the special case that the l-value width exactly
392 matches the gate count. In this case, we will make a single
393 gate that has the desired vector width. */
400 "Collapsed gate array into single wide "
402 }
404 /* Allocate all the netlist nodes for the gates. */
408 /* Calculate the gate delays from the delay expressions
409 given in the source. For logic gates, the decay time
410 is meaningless because it can never go to high
411 impedance. However, the bufif devices can generate
412 'bz output, so we will pretend that anything can.
414 If only one delay value expression is given (i.e., #5
415 nand(foo,...)) then rise, fall and decay times are
416 all the same value. If two values are given, rise and
417 fall times are use, and the decay time is the minimum
418 of the rise and fall times. Finally, if all three
419 values are given, they are taken as specified. */
429 /* Now make as many gates as the bit count dictates. Give each
430 a unique name, and set the delay times. */
433 ostringstream tmp;
437 else
613 instance_width);
650 }
664 }
669 /* The gates have all been allocated, this loop runs through
670 the parameters and attaches the ports of the objects. */
679 }
681 ? lval_sig
689 /* Handle the case where there is one gate that
690 carries the whole vector width. */
695 NetReplicate*rep
698 instance_width,
699 instance_width);
711 }
721 }
726 /* Handle the case where a single bit is connected
727 repetitively to all the instances. */
733 /* Handle the general case that each bit of the
734 value is connected to a different instance. In
735 this case, the output is handled slightly
736 different from the inputs. */
741 count);
744 /* Connect the concat to the signal. */
747 /* Connect the outputs of the gates to the concat. */
757 }
760 /* Use part selects to get the bits
761 connected to the inputs of out gate. */
773 }
781 }
783 }
784 }
789 {
808 }
819 }
832 }
837 }
842 }
844 /*
845 * Instantiate a module by recursively elaborating it. Set the path of
846 * the recursive elaboration so that signal names get properly
847 * set. Connect the ports of the instantiated module to the signals of
848 * the parameters. This is done with BUFZ gates so that they look just
849 * like continuous assignment connections.
850 */
852 {
860 }
862 // This is the array of pin expressions, shuffled to match the
863 // order of the declaration. If the source instantiation uses
864 // bind by order, this is the same as the source list.Otherwise,
865 // the source list is rearranged by name binding into this list.
868 // If the instance has a pins_ member, then we know we are
869 // binding by name. Therefore, make up a pins array that
870 // reflects the positions of the named ports.
874 // Scan the bindings, matching them with port names.
877 // Given a binding, look at the module port names
878 // for the position that matches the binding name.
881 // If the port name doesn't exist, the find_port
882 // method will return the port count. Detect that
883 // as an error.
890 }
892 // If I already bound something to this port, then
893 // the pins array will already have a pointer
894 // value where I want to place this expression.
898 endl;
901 }
903 // OK, do the binding by placing the expression in
904 // the right place.
906 }
911 /* Handle the special case that no ports are
912 connected. It is possible that this is an empty
913 connect-by-name list, so we'll allow it and assume
914 that is the case. */
921 /* Otherwise, this is a positional list of port
922 connections. In this case, the port count must be
923 right. Check that is is, the get the pin list. */
932 }
934 // No named bindings, just use the positional list I
935 // already have.
938 }
940 // Elaborate these instances of the module. The recursive
941 // elaboration causes the module to generate a netlist with
942 // the ports represented by NetNet objects. I will find them
943 // later.
948 }
952 // Now connect the ports of the newly elaborated designs to
953 // the expressions that are the instantiation parameters. Scan
954 // the pins, elaborate the expressions attached to them, and
955 // bind them to the port of the elaborated module.
957 // This can get rather complicated because the port can be
958 // unconnected (meaning an empty parameter is passed) connected
959 // to a concatenation, or connected to an internally
960 // unconnected port.
964 // Skip unconnected module ports. This happens when a
965 // null parameter is passed in.
969 // While we're here, look to see if this
970 // unconnected (from the outside) port is an
971 // input. If so, consider printing a port binding
972 // warning.
990 }
991 }
994 }
997 // Inside the module, the port is zero or more signals
998 // that were already elaborated. List all those signals
999 // and the NetNet equivalents, for all the instances.
1007 }
1009 // Count the internal vector bits of the port.
1015 // Scan the module sub-ports for this instance...
1027 }
1028 }
1030 // If I find that the port is unconnected inside the
1031 // module, then there is nothing to connect. Skip the
1032 // argument.
1035 }
1037 // We know by design that each instance has the same
1038 // width port. Therefore, the prts_pin_count must be an
1039 // even multiple of the instance count.
1046 // Elaborate the expression that connects to the
1047 // module[s] port. sig is the thing outside the module
1048 // that connects to the port.
1054 /* Input to module. elaborate the expression to
1055 the desired width. If this in an instance
1056 array, then let the net determine it's own
1057 width. We use that, then, to decide how to hook
1058 it up.
1060 NOTE that this also handles the case that the
1061 port is actually empty on the inside. We assume
1062 in that case that the port is input. */
1065 desired_vector_width,
1072 }
1076 /* Inout to/from module. This is a more
1077 complicated case, where the expression must be
1078 an lnet, but also an r-value net.
1080 Normally, this winds up being the same as if we
1081 just elaborated as an lnet, as passing a simple
1082 identifier elaborates to the same NetNet in
1083 both cases so the extra elaboration has no
1084 effect. But if the expression passed to the
1085 inout port is a part select, aspecial part
1086 select must be created that can paqss data in
1087 both directions.
1089 Use the elaborate_bi_net method to handle all
1090 the possible cases. */
1102 }
1107 /* Port type must be OUTPUT here. */
1109 /* Output from module. Elaborate the port
1110 expression as the l-value of a continuous
1111 assignment, as the port will continuous assign
1112 into the port. */
1124 }
1126 }
1130 #ifndef NDEBUG
1134 }
1135 #endif
1137 /* If we are working with an instance array, then the
1138 signal width must match the port width exactly. */
1149 }
1155 }
1157 // Check that the parts have matching pin counts. If
1158 // not, they are different widths. Note that idx is 0
1159 // based, but users count parameter positions from 1.
1181 }
1185 }
1187 // Connect the sig expression that is the context of the
1188 // module instance to the ports of the elaborated module.
1190 // The prts_pin_count variable is the total width of the
1191 // port and is the maximum number of connections to
1192 // make. sig is the elaborated expression that connects
1193 // to that port. If sig has too few pins, then reduce
1194 // the number of connections to make.
1196 // Connect this many of the port pins. If the expression
1197 // is too small, then reduce the number of connects.
1202 // The spin_modulus is the width of the signal (not the
1203 // port) if this is an instance array. This causes
1204 // signals wide enough for a single instance to be
1205 // connected to all the instances.
1210 // Now scan the concatenation that makes up the port,
1211 // connecting pins until we run out of port pins or sig
1212 // pins. The sig object is the NetNet that is connected
1213 // to the port from the outside, and the prts object is
1214 // an array of signals to be connected to the sig.
1221 // The simplest case, there are no
1222 // parts/concatenations on the inside of the
1223 // module, so the port and sig need simply be
1224 // connected directly.
1236 }
1238 // The signal width is exactly the width of a
1239 // single instance of the port. In this case,
1240 // connect the sig to all the ports identically.
1247 prts_vector_width,
1254 }
1265 }
1275 }
1292 }
1294 }
1296 }
1298 /*
1299 * From a UDP definition in the source, make a NetUDP
1300 * object. Elaborate the pin expressions as netlists, then connect
1301 * those networks to the pins.
1302 */
1305 {
1312 /* When the parser notices delay expressions in front of a
1313 module or primitive, it interprets them as parameter
1314 overrides. Correct that misconception here. */
1316 PDelays tmp_del;
1328 }
1338 }
1348 }
1350 }
1370 // This is the array of pin expressions, shuffled to match the
1371 // order of the declaration. If the source instantiation uses
1372 // bind by order, this is the same as the source
1373 // list. Otherwise, the source list is rearranged by name
1374 // binding into this list.
1377 // Detect binding by name. If I am binding by name, then make
1378 // up a pins array that reflects the positions of the named
1379 // ports. If this is simply positional binding in the first
1380 // place, then get the binding from the base class.
1385 // Scan the bindings, matching them with port names.
1388 // Given a binding, look at the module port names
1389 // for the position that matches the binding name.
1392 // If the port name doesn't exist, the find_port
1393 // method will return the port count. Detect that
1394 // as an error.
1401 }
1403 // If I already bound something to this port, then
1404 // the (*exp) array will already have a pointer
1405 // value where I want to place this expression.
1409 endl;
1412 }
1414 // OK, do the binding by placing the expression in
1415 // the right place.
1417 }
1421 /* Otherwise, this is a positional list of port
1422 connections. In this case, the port count must be
1423 right. Check that is is, the get the pin list. */
1432 }
1434 // No named bindings, just use the positional list I
1435 // already have.
1438 }
1441 /* Handle the output port of the primitive special. It is an
1442 output port (the only output port) so must be passed an
1443 l-value net. */
1459 }
1460 }
1462 /* Run through the pins, making netlists for the pin
1463 expressions and connecting them to the pin in question. All
1464 of this is independent of the nature of the UDP. */
1474 }
1477 }
1479 // All done. Add the object to the design.
1481 }
1485 {
1486 // Look for the module type
1492 }
1496 {
1497 // Look for the module type
1502 }
1504 // Try a primitive type
1510 }
1514 }
1517 {
1518 // Look for the module type
1523 }
1525 // Try a primitive type
1530 // Not a module or primitive that I know about yet, so try to
1531 // load a library module file (which parses some new Verilog
1532 // code) and try again.
1535 // Try again to find the module type
1540 }
1542 // Try again to find a primitive type
1546 }
1549 // Not a module or primitive that I know about or can find by
1550 // any means, so give up.
1554 }
1558 {
1564 }
1568 {
1571 }
1573 /*
1574 * This function elaborates delay expressions. This is a little
1575 * different from normal elaboration because the result may need to be
1576 * scaled.
1577 */
1579 {
1582 /* If the delay expression is a real constant or vector
1583 constant, then evaluate it, scale it to the local time
1584 units, and return an adjusted NetEConst. */
1596 }
1607 }
1610 /* The expression is not constant, so generate an expanded
1611 expression that includes the necessary scale shifts, and
1612 return that expression. */
1619 }
1623 }
1630 }
1634 }
1637 }
1640 {
1643 /* elaborate the lval. This detects any part selects and mux
1644 expressions that might exist. */
1648 /* If there is an internal delay expression, elaborate it. */
1656 /* Elaborate the r-value expression, then try to evaluate it. */
1658 /* Find out what the r-value width is going to be. We guess it
1659 will be the l-value width, but it may turn out to be
1660 something else based on self-determined widths inside. */
1665 /* Now elaborate to the expected width. Pass the lwidth to
1666 prune any constant result to fit with the lvalue at hand. */
1672 /* Rewrite delayed assignments as assignments that are
1673 delayed. For example, a = #<d> b; becomes:
1675 begin
1676 tmp = b;
1677 #<d> a = tmp;
1678 end
1680 If the delay is an event delay, then the transform is
1681 similar, with the event delay replacing the time delay. It
1682 is an event delay if the event_ member has a value.
1684 This rewriting of the expression allows me to not bother to
1685 actually and literally represent the delayed assign in the
1686 netlist. The compound statement is exactly equivalent. */
1698 //XXXX delete rv;
1700 }
1709 /* Generate an assignment of the l-value to the temporary... */
1715 /* Generate an assignment of the temporary to the r-value... */
1719 /* Generate the delay statement with the final
1720 assignment attached to it. If this is an event delay,
1721 elaborate the PEventStatement. Otherwise, create the
1722 right NetPDelay object. */
1728 "unable to elaborate event expression."
1732 }
1739 }
1741 /* And build up the complex statement. */
1747 }
1749 /* Based on the specific type of the l-value, do cleanup
1750 processing on the r-value. */
1753 // The r-value is a real. Casting will happen in the
1754 // code generator, so leave it.
1761 }
1767 }
1769 /*
1770 * Elaborate non-blocking assignments. The statement is of the general
1771 * form:
1772 *
1773 * <lval> <= #<delay> <rval> ;
1774 */
1776 {
1784 }
1786 /* Elaborate the l-value. */
1792 /* Elaborate and precalculate the r-value. */
1797 /* Handle the (common) case that the r-value is a vector. This
1798 includes just about everything but reals. In this case, we
1799 need to pad the r-value to match the width of the l-value.
1801 If in this case the l-val is a variable (i.e. real) then
1802 the width to pad to will be 0, so this code is harmless. */
1809 }
1815 /* All done with this node. Mark its line number and check it in. */
1820 }
1823 /*
1824 * This is the elaboration method for a begin-end block. Try to
1825 * elaborate the entire block, even if it fails somewhere. This way I
1826 * get all the error messages out of it. Then, if I detected a failure
1827 * then pass the failure up.
1828 */
1830 {
1846 }
1850 }
1857 // Handle the special case that the block contains only one
1858 // statement. There is no need to keep the block node. Also,
1859 // don't elide named blocks, because they might be referenced
1860 // elsewhere.
1865 }
1870 // If the statement fails to elaborate, then simply
1871 // ignore it. Presumably, the elaborate for the
1872 // statement already generated an error message and
1873 // marked the error count in the design so no need to
1874 // do any of that here.
1877 }
1879 // If the result turns out to be a noop, then skip it.
1884 }
1887 }
1890 }
1892 /*
1893 * Elaborate a case statement.
1894 */
1896 {
1904 }
1906 /* Count the items in the case statement. Note that there may
1907 be some cases that have multiple guards. Count each as a
1908 separate item. */
1915 else
1917 }
1922 /* Iterate over all the case items (guard/statement pairs)
1923 elaborating them. If the guard has no expression, then this
1924 is a "default" cause. Otherwise, the guard has one or more
1925 expressions, and each guard is a case. */
1933 /* If there are no expressions, then this is the
1934 default case. */
1944 /* If there are one or more expressions, then
1945 iterate over the guard expressions, elaborating
1946 a separate case for each. (Yes, the statement
1947 will be elaborated again for each.) */
1958 }
1959 }
1962 }
1965 {
1972 // Elaborate and try to evaluate the conditional expression.
1979 }
1981 // If the condition of the conditional statement is constant,
1982 // then look at the value and elaborate either the if statement
1983 // or the else statement. I don't need both. If there is no
1984 // else_ statement, the use an empty block as a noop.
1990 }
2004 }
2007 else
2009 }
2011 // If the condition expression is more than 1 bits, then
2012 // generate a comparison operator to get the result down to
2013 // one bit. Turn <e> into <e> != 0;
2019 }
2028 }
2030 // Well, I actually need to generate code to handle the
2031 // conditional, so elaborate.
2035 // Detect the special cases that the if or else statements are
2036 // empty blocks. If this is the case, remove the blocks as
2037 // null statements.
2042 }
2043 }
2049 }
2050 }
2055 }
2058 {
2061 else
2063 }
2065 /*
2066 * A call to a system task involves elaborating all the parameters,
2067 * then passing the list to the NetSTask object.
2068 *XXXX
2069 * There is a single special case in the call to a system
2070 * task. Normally, an expression cannot take an unindexed
2071 * memory. However, it is possible to take a system task parameter a
2072 * memory if the expression is trivial.
2073 */
2075 {
2080 /* Catch the special case that the system task has no
2081 parameters. The "()" string will be parsed as a single
2082 empty parameter, when we really mean no parameters at all. */
2092 /* Attempt to pre-evaluate the parameters. It may be
2093 possible to at least partially reduce the
2094 expression. */
2099 }
2100 }
2101 }
2105 }
2107 /*
2108 * A call to a user defined task is different from a call to a system
2109 * task because a user task in a netlist has no parameters: the
2110 * assignments are done by the calling thread. For example:
2111 *
2112 * task foo;
2113 * input a;
2114 * output b;
2115 * [...]
2116 * endtask;
2117 *
2118 * [...] foo(x, y);
2119 *
2120 * is really:
2121 *
2122 * task foo;
2123 * reg a;
2124 * reg b;
2125 * [...]
2126 * endtask;
2127 *
2128 * [...]
2129 * begin
2130 * a = x;
2131 * foo;
2132 * y = b;
2133 * end
2134 */
2136 {
2144 }
2152 }
2163 }
2172 }
2176 /* Handle tasks with no parameters specially. There is no need
2177 to make a sequential block to hold the generated code. */
2182 }
2187 /* Detect the case where the definition of the task is known
2188 empty. In this case, we need not bother with calls to the
2189 task, all the assignments, etc. Just return a no-op. */
2194 }
2196 /* Generate assignment statement statements for the input and
2197 INOUT ports of the task. These are managed by writing
2198 assignments with the task port the l-value and the passed
2199 expression the r-value. We know by definition that the port
2200 is a reg type, so this elaboration is pretty obvious. */
2217 }
2219 /* Generate the task call proper... */
2225 /* Generate assignment statements for the output and INOUT
2226 ports of the task. The l-value in this case is the
2227 expression passed as a parameter, and the r-value is the
2228 port to be copied out.
2230 We know by definition that the r-value of this copy-out is
2231 the port, which is a reg. The l-value, however, may be any
2232 expression that can be a target to a procedural
2233 assignment, including a memory word. */
2239 /* Skip input ports. */
2245 /* Elaborate an l-value version of the port expression
2246 for output and inout ports. If the expression does
2247 not exist then quietly skip it, but if the expression
2248 is not a valid l-value print an error message. Note
2249 that the elaborate_lval method already printed a
2250 detailed message. */
2258 }
2261 }
2269 /* Generate the assignment statement. */
2273 }
2276 }
2278 /*
2279 * Elaborate a procedural continuous assign. This really looks very
2280 * much like other procedural assignments, at this point, but there
2281 * is no delay to worry about. The code generator will take care of
2282 * the differences between continuous assign and normal assignments.
2283 */
2285 {
2310 }
2314 }
2317 {
2327 }
2329 /*
2330 * Elaborate the delay statement (of the form #<expr> <statement>) as a
2331 * NetPDelay object. If the expression is constant, evaluate it now
2332 * and make a constant delay. If not, then pass an elaborated
2333 * expression to the constructor of NetPDelay so that the code
2334 * generator knows to evaluate the expression at run time.
2335 */
2337 {
2345 }
2347 /* This call evaluates the delay expression to a NetEConst, if
2348 possible. This includes transforming NetECReal values to
2349 integers, and applying the proper scaling. */
2356 else
2364 else
2366 }
2368 }
2370 /*
2371 * The disable statement is not yet supported.
2372 */
2374 {
2385 }
2400 }
2405 }
2407 /*
2408 * An event statement is an event delay of some sort, attached to a
2409 * statement. Some Verilog examples are:
2410 *
2411 * @(posedge CLK) $display("clock rise");
2412 * @event_1 $display("event triggered.");
2413 * @(data or negedge clk) $display("data or clock fall.");
2414 *
2415 * The elaborated netlist uses the NetEvent, NetEvWait and NetEvProbe
2416 * classes. The NetEvWait class represents the part of the netlist
2417 * that is executed by behavioral code. The process starts waiting on
2418 * the NetEvent when it executes the NetEvWait step. Net NetEvProbe
2419 * and NetEvTrig are structural and behavioral equivalents that
2420 * trigger the event, and awakens any processes blocking in the
2421 * associated wait.
2422 *
2423 * The basic data structure is:
2424 *
2425 * NetEvWait ---/---> NetEvent <----\---- NetEvProbe
2426 * ... | | ...
2427 * NetEvWait ---+ +---- NetEvProbe
2428 * | ...
2429 * +---- NetEvTrig
2430 *
2431 * That is, many NetEvWait statements may wait on a single NetEvent
2432 * object, and Many NetEvProbe objects may trigger the NetEvent
2433 * object. The many NetEvWait objects pointing to the NetEvent object
2434 * reflects the possibility of different places in the code blocking
2435 * on the same named event, like so:
2436 *
2437 * event foo;
2438 * [...]
2439 * always begin @foo <statement1>; @foo <statement2> end
2440 *
2441 * This tends to not happen with signal edges. The multiple probes
2442 * pointing to the same event reflect the possibility of many
2443 * expressions in the same blocking statement, like so:
2444 *
2445 * wire reset, clk;
2446 * [...]
2447 * always @(reset or posedge clk) <stmt>;
2448 *
2449 * Conjunctions like this cause a NetEvent object be created to
2450 * represent the overall conjunction, and NetEvProbe objects for each
2451 * event expression.
2452 *
2453 * If the NetEvent object represents a named event from the source,
2454 * then there are NetEvTrig objects that represent the trigger
2455 * statements instead of the NetEvProbe objects representing signals.
2456 * For example:
2457 *
2458 * event foo;
2459 * always @foo <stmt>;
2460 * initial begin
2461 * [...]
2462 * -> foo;
2463 * [...]
2464 * -> foo;
2465 * [...]
2466 * end
2467 *
2468 * Each trigger statement in the source generates a separate NetEvTrig
2469 * object in the netlist. Those trigger objects are elaborated
2470 * elsewhere.
2471 *
2472 * Additional complications arise when named events show up in
2473 * conjunctions. An example of such a case is:
2474 *
2475 * event foo;
2476 * wire bar;
2477 * always @(foo or posedge bar) <stmt>;
2478 *
2479 * Since there is by definition a NetEvent object for the foo object,
2480 * this is handled by allowing the NetEvWait object to point to
2481 * multiple NetEvent objects. All the NetEvProbe based objects are
2482 * collected and pointed as the synthetic NetEvent object, and all the
2483 * named events are added into the list of NetEvent object that the
2484 * NetEvWait object can refer to.
2485 */
2489 {
2497 }
2499 /* Create a single NetEvent and NetEvWait. Then, create a
2500 NetEvProbe for each conjunctive event in the event
2501 list. The NetEvProbe objects all refer back to the NetEvent
2502 object. */
2511 /* If there are no expressions, this is a signal that it is an
2512 @* statement. Generate an expression to use. */
2523 }
2530 }
2547 /* If the expression is an identifier that matches a
2548 named event, then handle this case all at once at
2549 skip the rest of the expression handling. */
2562 }
2563 }
2566 /* So now we have a normal event expression. Elaborate
2567 the sub-expression as a net and decide how to handle
2568 the edge. */
2580 }
2605 }
2612 }
2614 /* If there was at least one conjunction that was an
2615 expression (and not a named event) then add this
2616 event. Otherwise, we didn't use it so delete it. */
2620 /* NOTE: This event that I am adding to the wait may be
2621 a duplicate of another event somewhere else. However,
2622 I don't know that until all the modules are hooked
2623 up, so it is best to leave find_similar_event to
2624 after elaboration. */
2627 }
2630 }
2632 /*
2633 * This is the special case of the event statement, the wait
2634 * statement. This is elaborated into a slightly more complicated
2635 * statement that uses non-wait statements:
2636 *
2637 * wait (<expr>) <statement>
2638 *
2639 * becomes
2640 *
2641 * begin
2642 * while (1 !== <expr>)
2643 * @(<expr inputs>) <noop>;
2644 * <statement>;
2645 * end
2646 */
2649 {
2658 }
2662 /* Elaborate wait expression. Don't eval yet, we will do that
2663 shortly, after we apply a reduction or. */
2670 }
2672 // If the condition expression is more than 1 bits, then
2673 // generate a reduction operator to get the result down to
2674 // one bit. In other words, Turn <e> into |<e>;
2680 }
2686 }
2688 /* precalculate as much as possible of the wait expression. */
2692 }
2694 /* Detect the unusual case that the wait expression is
2695 constant. Constant true is OK (it becomes transparent) but
2696 constant false is almost certainly not what is intended. */
2702 /* Constant true -- wait(1) <s1> reduces to <s1>. */
2707 }
2709 /* Otherwise, false. wait(0) blocks permanently. */
2716 /* Create an event wait and an otherwise unreferenced
2717 event variable to force a perpetual wait. */
2728 }
2730 /* Invert the sense of the test with an exclusive NOR. In
2731 other words, if this adjusted expression returns TRUE, then
2732 wait. */
2739 }
2754 }
2761 }
2775 /* If there is no real substatement (i.e., "wait (foo) ;") then
2776 we are done. */
2780 /* Create a sequential block to combine the wait loop and the
2781 delayed statement. */
2788 }
2792 {
2802 }
2808 }
2810 /*
2811 * Forever statements are represented directly in the netlist. It is
2812 * theoretically possible to use a while structure with a constant
2813 * expression to represent the loop, but why complicate the code
2814 * generators so?
2815 */
2817 {
2823 }
2825 /*
2826 * Force is like a procedural assignment, most notably prodedural
2827 * continuous assignment:
2828 *
2829 * force <lval> = <rval>
2830 *
2831 * The <lval> can be anything that a normal behavioral assignment can
2832 * take, plus net signals. This is a little bit more lax then the
2833 * other proceedural assignments.
2834 */
2836 {
2861 }
2865 }
2867 /*
2868 * elaborate the for loop as the equivalent while loop. This eases the
2869 * task for the target code generator. The structure is:
2870 *
2871 * begin : top
2872 * name1_ = expr1_;
2873 * while (cond_) begin : body
2874 * statement_;
2875 * name2_ = expr2_;
2876 * end
2877 * end
2878 */
2880 {
2892 /* make the expression, and later the initial assignment to
2893 the condition variable. The statement in the for loop is
2894 very specifically an assignment. */
2901 }
2905 /* Calculate the width of the initialization as if this were
2906 any other assignment statement. */
2911 /* Make the r-value of the initial assignment, and size it
2912 properly. Then use it to build the assignment statement. */
2921 }
2931 /* Elaborate the statement that is contained in the for
2932 loop. If there is an error, this will return 0 and I should
2933 skip the append. No need to worry, the error has been
2934 reported so it's OK that the netlist is bogus. */
2940 /* Elaborate the increment assignment statement at the end of
2941 the for loop. This is also a very specific assignment
2942 statement. Put this into the "body" block. */
2949 }
2954 /* Make the rvalue of the increment expression, and size it
2955 for the lvalue. */
2963 /* Elaborate the condition expression. Try to evaluate it too,
2964 in case it is a constant. This is an interesting case
2965 worthy of a warning. */
2970 }
2975 }
2978 /* All done, build up the loop. */
2984 }
2986 /*
2987 * (See the PTask::elaborate methods for basic common stuff.)
2988 *
2989 * The return value of a function is represented as a reg variable
2990 * within the scope of the function that has the name of the
2991 * function. So for example with the function:
2992 *
2993 * function [7:0] incr;
2994 * input [7:0] in1;
2995 * incr = in1 + 1;
2996 * endfunction
2997 *
2998 * The scope of the function is <parent>.incr and there is a reg
2999 * variable <parent>.incr.incr. The elaborate_1 method is called with
3000 * the scope of the function, so the return reg is easily located.
3001 *
3002 * The function parameters are all inputs, except for the synthetic
3003 * output parameter that is the return value. The return value goes
3004 * into port 0, and the parameters are all the remaining ports.
3005 */
3008 {
3015 }
3025 }
3028 }
3031 {
3041 }
3044 {
3053 }
3058 // If the expression is a constant, handle certain special
3059 // iteration counts.
3072 }
3073 }
3077 }
3079 /*
3080 * A task definition is elaborated by elaborating the statement that
3081 * it contains, and connecting its ports to NetNet objects. The
3082 * netlist doesn't really need the array of parameters once elaboration
3083 * is complete, but this is the best place to store them.
3084 *
3085 * The first elaboration pass finds the reg objects that match the
3086 * port names, and creates the NetTaskDef object. The port names are
3087 * in the form task.port.
3088 *
3089 * task foo;
3090 * output blah;
3091 * begin <body> end
3092 * endtask
3093 *
3094 * So in the foo example, the PWire objects that represent the ports
3095 * of the task will include a foo.blah for the blah port. This port is
3096 * bound to a NetNet object by looking up the name. All of this is
3097 * handled by the PTask::elaborate_sig method and the results stashed
3098 * in the created NetTaskDef attached to the scope.
3099 *
3100 * Elaboration pass 2 for the task definition causes the statement of
3101 * the task to be elaborated and attached to the NetTaskDef object
3102 * created in pass 1.
3103 *
3104 * NOTE: I am not sure why I bothered to prepend the task name to the
3105 * port name when making the port list. It is not really useful, but
3106 * that is what I did in pform_make_task_ports, so there it is.
3107 */
3110 {
3126 }
3127 }
3130 }
3133 {
3148 }
3155 }
3160 }
3162 /*
3163 * The while loop is fairly directly represented in the netlist.
3164 */
3166 {
3170 }
3173 {
3177 }
3187 }
3190 // Evaluate the attributes for this process, if there
3191 // are any. These attributes are to be attached to the
3192 // NetProcTop object.
3206 /* Detect the special case that this is a combinational
3207 always block. We want to attach an _ivl_schedule_push
3208 attribute to this process so that it starts up and
3209 gets into its wait statement before non-combinational
3210 code is executed. */
3233 }
3243 }
3246 {
3250 /* Do not elaborate specify delay paths if this feature is
3251 turned off. */
3255 /* Check for various path types that are not supported. */
3263 }
3273 /* Elaborate the delay values themselves. Remember to scale
3274 them for the timescale/precision of the scope. */
3292 }
3294 }
3309 }
3318 // FIXME: Look for constant expressions here?
3320 // Get a net form.
3323 }
3325 /* Create all the various paths from the path specifier. */
3335 }
3343 }
3351 }
3357 // The presence of the data_source_expression indicates
3358 // that this is an edge sensitive path. If so, then set
3359 // the edges. Note that edge==0 is BOTH edges.
3363 }
3389 }
3404 }
3408 }
3414 }
3416 }
3418 /*
3419 * When a module is instantiated, it creates the scope then uses this
3420 * method to elaborate the contents of the module.
3421 */
3423 {
3427 // Elaborate specparams
3461 }
3466 }
3467 }
3469 // Elaborate within the generate blocks.
3474 }
3476 // Elaborate functions.
3485 }
3487 // Elaborate the task definitions. This is done before the
3488 // behaviors so that task calls may reference these, and after
3489 // the signals so that the tasks can reference them.
3498 }
3500 // Get all the gates of the module and elaborate them by
3501 // connecting them to the signals. The gate may be simple or
3502 // complex.
3510 }
3512 // Elaborate the behaviors, making processes out of them. This
3513 // involves scanning the PProcess* list, creating a NetProcTop
3514 // for each process.
3521 }
3523 // Elaborate the specify paths of the module.
3529 }
3532 }
3535 {
3543 // Check that this scope is one that is contained in the
3544 // container that the caller passed in.
3553 }
3556 }
3559 {
3569 }
3574 };
3577 {
3582 // This is the output design. I fill it in as I scan the root
3583 // module and elaborate what I find.
3586 // Scan the root modules, and elaborate their scopes.
3591 // Look for the root module in the list.
3600 }
3602 // Get the module definition for this root instance.
3605 // Make the root scope.
3614 // Recursively elaborate from this root scope down. This
3615 // does a lot of the grunt work of creating sub-scopes, etc.
3619 }
3625 }
3627 // Errors already? Probably missing root modules. Just give up
3628 // now and return nothing.
3632 // This method recurses through the scopes, looking for
3633 // defparam assignments to apply to the parameters in the
3634 // various scopes. This needs to be done after all the scopes
3635 // and basic parameters are taken care of because the defparam
3636 // can assign to a parameter declared *after* it.
3640 // At this point, all parameter overrides are done. Scan the
3641 // scopes and evaluate the parameters all the way down to
3642 // constants.
3645 // With the parameters evaluated down to constants, we have
3646 // what we need to elaborate signals and memories. This pass
3647 // creates all the NetNet and NetMemory objects for declared
3648 // objects.
3656 }
3657 }
3659 // Now that the structure and parameters are taken care of,
3660 // run through the pform again and generate the full netlist.
3666 }
3672 }
3675 }