Date: Sun Dec 04 2005 - 22:51:58 PST
Shalom, I do not think outputs wired together at in a higher level module constitute a violation of the rule in 11.2. They are separate variables in each of the lower level modules where the procedural statements are placed. And if you are trying to model a bi-directional tri-state bus, then you will have to use an inout port, which requires wires on the upper and lower module connections. Dave ________________________________ From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom Sent: Saturday, December 03, 2005 11:38 PM To: sv-bc@eda.org Subject: [sv-bc] @* vs. always_comb I bet you though this issue was dead, didn't you? I recently came across the claim that there is a standard situation where neither always_comb nor always_latch is appropriate, but @* does work. If this is really so, then we can't just deprecate @* and say to use always_comb instead. We'll have to make sure that @* works properly. The situation is of modeling a three-state bus. In this case, we get statements like always @* sig = cond1 ? in1 : 1'bz ; always @* sig = cond2 ? in2 : 1'bz ; etc. The catch is that these statements will be found in different modules and the three-state outputs are wired together at a higher level in the hierarchy, thus violating the always_comb condition in 11.2 that "the variables written on the left-hand side of assignments shall not be written to by any other process." Comments? I do not remember seeing this noted elsewhere. Maybe it was and I just don't remember. Thanks, Shalom Shalom Bresticker Intel Jerusalem LAD DA +972 2 589-6852 +972 54 721-1033 I don't represent Intel
