Hello SV LRM Gurus,
I'm posting this to www.svug.org as well to get to wider experts: While replying to the other post on "Interface wires" I remembered another long pending issue that has been bothering me. In SV interface.modport.clocking_block, if I have a signal declared as "output" one can't read it? So evena simple $display of an output won't work! I don't have access to a simulator right now, but am quite sure I've seen this clearly as an error from a tool. I end up making it inout for the debug sake alone - which I would really really avoid. I'm not quite sure if the same restriction applies to modport as well. If so are we going back to stone age :-) ? For long VHDL has/had this problem and I believe the FT-200X is debating over relaxing it. Why would SV make such a restriction? Honestly I can't take an argument of "involved semantics" issue - as a user this is one of the most painful stuff and the last thing we would expect with a good language like SV.

Any thoughts?

Thanks
Ajeetha, CVC
www.noveldv.com

AFAIK, a clocking block output is the only kind of output you can't read. That's because there's sampling of a clocking block output defined.

Dave

Ajeetha,

But what value are you looking to have displayed? If you want the current value of the target, you can just display that directly. If you want the value it will have in the future, well, you'll have to wait for the future to arrive.

Dave,
OK, I think I understand that - values are "scheduled" than updated immediately. But what about the default output skew of "0", even then I don't get it immediately? The $display is a simplification of the actual usage. Also one may want to display it from a completely different place than where it is being driven. For instance I can have a Debug Monitor that will simply display all TB driven/sampled signals and is a separate component in my Verif env. For it to reliably work I would need to declare all outputs as inouts instead. In reality this is a much serious user problem: Imagine I write a sample debug code like:

class my_debug_mon extends avm/vmm ;

virtual my_if.tb_mp my_vif; // It has clocking block my_cb

task my_mon;
forever ..
if (my_vif.my_cb.value_driven_kind == IP_Pkt)
$display("IP_Pkt with Starting Data as: %x ", my_vif.my_cb.data);
...

The above code is incomplete but does illustrate the kind of usage I'm looking at. Perhaps the WA is to use the Interface level objects, but this will be confusing as I will need to do the synchronization myself. I can't use the MP level items as I have only the my_cb directly under MP.

My fundamental question is: why put such a restriction when the good old VHDL is moving away from it and also Verilog didn't have it. Sure SV has complicated synchronization scheme, but the full power/need of it is debatable - after all we have been doing this for years without these interfaces and interface value addition (especially with this limitation) is not as much as things like class, assertions etc. IMHO.

Thanks
Ajeetha, CVC
www.noveldv.com

Ajeetha,

I think you are confusing modport port directions with clocking block variable declarations. There is no restriction on reading ports (modports or on regular modules') that are defined as outputs. Inputs, outputs, and inouts of clocking block variables define sampling or driving semantics. Although there usually is a correlation between the direction of a port and the definition of a clocking block variable, they are not the same thing semantically.

So you can have an signal defined as a modport output, but its clocking block definition uses an inout. An clocking block inout variable means that both sampling and driving semantics have been defined for that variable.

If you really want to read a variable's immediate value, then use the "raw" signal instead of using the clocking block.

Dave