The main issue is how to handle resolution of multiple drivers on a 2-state net. A related issue is how to handle connection of a 2-state net to a 4-state net through a port. I can see a number of possible solutions: 1. Avoid the issue by only allowing 2-state nets of net type uwire. Since these can only have a single driver, there is no need for resolution. There is still an issue with the driver on a 4-state uwire connected through a port to a 2-state uwire. What values would be read from the 2-state uwire? This could be illegal. It could be treated like the port was a continuous assignment from the 4-state side to the 2-state side, which would map the values to 2-state, though uwire normally requires port-collapsing so it can guarantee the single-driver rule. The 4-state could win during collapsing, making both sides 4-state. Or the 4-state value driven onto the uwire could be mapped to 2-state when read through a 2-state uwire. But if we are willing to do this kind of mapping, one of the later solutions may be better. Note that we could allow this limited solution initially, and then go back and allow a more general case later. 2. Be a little more general and allow wor and wand nets also, but no drive strengths on the drivers. The resolution functions would be wire-OR and wire-AND, which produce 2-state results for 2-state inputs. The issues with connecting 2-state and 4-state nets through ports would be much the same as above. 3. Perform the resolution using 4-state resolution functions, producing 4-state results. Map the 4-state value to 2-state when read through a 2-state net, at least in some circumstances. There would be some further decisions to be made. Would driving a value onto a 2-state net convert the value to 2-state first and drive that, so 4-state values only resulted from resolution? Or would the full 4-state value be driven onto the net, including x and z, with mapping only done during reading? If you want the driver to be able to stop driving, it needs to be able to drive a z, even if the net is supposedly 2-state. In what contexts would the value be converted to 2-state when read? Using the value in an expression in procedural code should presumably map it to 2-state. But connecting the value to the input of a switch primitive should presumably pass the full 4-state value through. The RHS of a continuous assignment needs special consideration. This seems like an expression, and therefore seems like it should be mapped. But port connections are defined to use continuous assignments. If you want driver resolution to be done properly, you need to pass the 4-state value through ports. Another way of putting this is that you want to get pretty much the same result if you use a continuous assignment for the port as if you collapse the port. You could have a special case for port connections that are potentially collapsible (i.e. qualify as net_lvalues), and have those read 4-state, while more complex port expressions read 2-state. That is rather ugly though. This is close to what Dave described. I don't agree that you have to regard reading a 4-state net as mapping a 120-state value into a 4-state value on the read to be able to do this though. You can regard reading a 4-state net as reading the 4-state value of the net, and ignoring the separate attached strength, while still mapping a 4-state value to 2-state when reading the 2-state value of the net. Viewing both as a mapping has a nice consistency, but I don't think that is necessary to be able to do the mapping for 2-state. I do agree that there are some valuable parallels between the two situations. Note that the cases I mentioned above where you want to pass 4-state values (switch primitives and collapsed port connections) are ones where you also pass strength information. But the LRM allows connections not to be collapsed, and to be treated as continuous assignments instead. When this is done, strength information is not passed. This allows users to tell whether the port collapsed or not, and may not work as desired if it doesn't, but doesn't seem to cause too much trouble. On the other hand, if an implementation could decide whether to pass 4-state information or 2-state information, depending on whether it collapsed the port or not, I think that would cause a lot more trouble. There are other cases where decisions would need to be made. For example, what about non-switch primitives, and timing checks and path delays? Should those map the values to 2-state or not? The need to make all these additional decisions is the main obstacle to this approach. Steven Sharp sharp@cadence.comReceived on Wed May 17 15:39:33 2006
This archive was generated by hypermail 2.1.8 : Wed May 17 2006 - 15:39:42 PDT