Regarding Modport and Clocking Block

Hi ,

I have following code :: Code

Via +define+ADD I tried to test what happens if a user inadvertently drives signals declared with input direction in modport and clocking block.

I observe all tools throw an error when driving signals ’ out ’ and ’ ack ’ declared as input within the clocking block however
only 1 tool throws an error when driving signals ’ a ’ and ’ b ’ declared as input within modport RTL .

[Q1] Are input signals within modport legal to be driven as per LRM ?

 Within  modport  TB  I  have  added  clocking  block  ' cb ' .  

[Q2] If user wants to drive output signal ’ a ’ within ’ cb ’ via modport TB what’s the correct way ?
Should it be inf.TB.cb.a <= 5 ; OR inf.cb.a <= 5 ; ?

[Q3] Are modport meant for RTL designs only ? Can it be used for Testbench as well ?
Similarly are clocking blocks meant only for Testbench ?

[Q4] Direction of signals can be defined within clocking blocks as well as modports .
**So what’s the point of adding a clocking block to a modport ?

 Is  it  to  add  a  relative  timing  of  reading / writing  these  signals ?**

 Asynchronous  signals ( Eg: Asynchronous Reset ) aren't  related  to  clock . 
 Hence  these  signals  aren't  part  of  clocking  block  and  are  added  to  modport directly .

[Q5] Output Signals of a clocking block ( clockvar ) are driven using <= .
Does the update occur in NBA region OR Re-NBA region ?

In reply to Have_A_Doubt:

  • [A1] The LRM says modports directions are declared as if they were inside the module being connected. It does not explicitly say modports should follow the same connection rules as a module port. Unfortunately most simulation tools have chosen to ignore modport directions while synthesis tools follow the direction rules. That makes using modports useless for testbenches.
  • [A2] You should use
    inf.cb.a <= 5;
    . A modport is an access privilege list, not a hierarchical scope.
  • [A3] As I said in [A1], modports are mainly for RTL. If you use interfaces in RTL, synthesis tools require modports. Clocking blocks are most often used inside an interface. Synthesis tools have chosen not to support them, but there is nothing unsynthesizable about them. I feel you can avoid clocking blocks with the proper use of non-blocking assignments.
  • [A4] A clocking block creates a set of mirror variables for sampling input signals, or driving a output signals. An inout signal creates two separate clocking block variables; one for sampling and one for driving. Putting a clocking block name in a modport gives you access to all clocking block variables without having to specify every clocking block variable individually. The directions used in the clocking block variable declaration are related, by not necessarily always the same as the modport directions.
  • [A5] Clocking block drives occur in the re-NBA region. If you are not using program blocks, there is no need to know the difference.