MODPORTS are used to define direction of signal inside interface.can we access signals of interface inside modules without MODPORTS? If “yes” then what are the use of MODPORTS?
Modports were primarily added to SystemVerilog for Synthesis tools. Synthesis tools sometimes only look at portions of the design hierarchy and need direction information at the boundaries they are analyzing. They can also be used to show intended usage. In an interface port or virtual interface variable declaration, designating a modport is a requirement for access. When you make a connection to an actual interface instance, you can provide a specific modport to a module port connection.
If you are only using interfaces for verification, we do not recommend using modports as some simulators do not even perform all the necessary design rule checks.
In reply to dave_59:
Hi Dave,
Thanks for reply.
can you plesae elaborate more on this.
In reply to ajith.r:
Can you elaborate on why you think you need to use modports. There a lot of stuff in the SystemVerilog LRM that could be removed, and no one would miss it.
In reply to dave_59:
This was the question asked during my previous interview.
In reply to ajith.r:
- In an interface port or virtual interface variable declaration, designating a modport is a requirement for access. When you make a connection to an actual interface instance, you can provide a specific modport to a module port connection.
- If you are only using interfaces for verification, we do not recommend using modports as some simulators do not even perform all the necessary design rule checks.
Dave, aren’t statements 1 and 2 sort of contradicting with the popularity of classes and UVM for verification? Also, as you said, showing the intent is not only meaningful, but the compiler would check for illegal assignments (eg…, a driver assigning to an input)?
I kind of like the modport.
Question: on design rule checks, what specifically are you addressing? the driving or reading values?
Ben SystemVerilog.us
In reply to ben@SystemVerilog.us:
Ben,
The UVM does not provide much direction in the area of testbench to DUT connections other than recommending how to pass virtual interface handles around. My DVCon 2012 Paper does attempt to provide some guidelines.
The design rule checks that I am referring to apply to driving variables connected to ports. Because of legacy Verilog rules for port collapsing of wires, there are no rules that would prevent driving input wires from the lower level or output wires from the higher level. So the directionality of wire ports are ignored by simulation, and only used by synthesis tools when ports are at the top level.
Because SystemVerilog variables allow a single continuous driver, and ports connected using variables are treated as continuous assignments, SV can enforce the associated port direction.
I’ve seen many cases in an interface where there is a clocking block output and a modport output on the same variable that should have been an error, but it “works” because of the way the testbench is structured by only driving values from one side during the entire test. Had both sides attempted to drive the same variable, you get last write wins semantics, not a proper multiple continuous driver resolution. But because the simulator is ignoring the direction, the modport direction information is useless. And there is really no reason to limit the visibility of interface signals in a testbench. So the whole point of declaring modports for testbench use is lost.