Subject: RE: [sv-bc] Proposal to change interface ref-port default mode -or- documentation
From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Tue Sep 02 2003 - 15:57:13 PDT
Cliff,
Under the existing 3.1 standard, synthesis should error out if no modport
is used, except when there are no variables in the interface, that is,
except when there are only wires. This is because ref ports are not
part of the synthesizable subset.
Also, the "unknown wired logic" behavior you describe does not happen with
the new Presto tool, but only with the classic HDLC tool. Upgrade to Presto
and you should get an ELAB-366 error on such test cases, not just a warning.
For backward compatibility you can still get the HDLC behavior by setting
hdlin_prohibit_nontri_multiple_drivers=false. But by default all drivers
of a multiply driven net must be declared tri.
-- Brad
>>BTW surely the synthesis tool will catch any incorrect use?
>
>Not true. Synopsys currently allows assignments to the same variable from
>more than one clocked always block and WARNS about an unknown wired logic
>type and then proceeds to build two flip-flops with outputs anded together.
>In the pre-synthesis simulation, there is an assignment race condition
>(just like the new ref-port race condition), but the post-synthesis logic
>does not match either race-simulation.
>
>The only interface guideline that I have heard so far from synthesis tool
>vendors is that they will RECOMMEND that modports be used with interfaces
>(modports will not be a requirement). If the RTL code only has one
>procedural assignment to a ref-port and another module reads the ref-port
>module, the inferred logic will be reasonable and correct. If the RTL code
>has two procedural assignments from two different modules to a common
>ref-port, the inferred logic will have all of the problems of the
>two-flip-flop model above.
This archive was generated by hypermail 2b28 : Tue Sep 02 2003 - 15:59:58 PDT