- + Issue 2: Driver-receiver Segregation

[Kevin Cameron, 02 Jan 2001]


^ Issue   < Previous

Proposal

There are two opposing views of how A/D conversion module insertion should work, for the sake of argument I will call the current scheme (Cadence's) "port bound", and the alternative "process bound" - indicating that possible connect modules are bound to the port of a module or to the driving/receiving process.

As both approaches have benefits and drawbacks, I propose adding a "binding" attribute in the discipline declarations to indicate which mode to use, e.g.: 


   discipline ttl
     binding port ; // stated only for clarity
     potential ttl_volt ;
     ....
   enddiscipline

   discipline tsmc0u18
     binding process ;
     potential cms1v2 ;
     ....
   enddiscipline
"Port bound" would be the default (for backward compatibility), and "process bound" would use the alternative resolution semantics which ignore the design hierarchy and connect modules would be inserted as close as possible to their associated process (i.e. children of the module instance owning the process).

"Process bound" disciplines would be ignored in modules containing no processes (same as "empty" disciplines?), or if there are no processes attached to ports of those disciplines.

Note: Since process bound discipline conversion does not require ports it should also work inside modules and be invariant with hierarchy changes (e.g. flattening).