Mikhail Ravkine wrote:
>> By interface, do you mean the set of nets in a Verilog module
>> declaration? Or do you mean a high-level communication pathway
>> between two modules (like a FIFO with receiver-is-busy
>> handshaking)?
>
> Set of nets. It has two uses, one is to make connecting up
> bundles of wires between modules easier and the other is to bind
> RTL code to Classes in such a way that the class doesn't actually
> know the hiearchical name of the pins it's driving.
Thanks to Ruby's dynamic typing, I believe this is already possible.
For instance, suppose we have two Verilog modules:
module foo(input a, input b);
endmodule
module bar(input b, input c, input a);
endmodule
Both of these modules conform to an interface composed of the
signals a & b. So, in Ruby we can:
mod = vpi_handle_by_name("foo", nil)
mod.a.intVal = 0
mod.b.intVal = 1
mod.c.intVal = 0 # ArgumentError: "VpiC" is not a valid property
mod = vpi_handle_by_name("bar", nil)
mod.a.intVal = 0
mod.b.intVal = 1
mod.c.intVal = 0 # OK!
Furthermore, the order in which these signals are specified in the
module declarations is irrelevant in Ruby. So it seems that we
already have a good implementation of "interfaces" for free.
> This second use allows for multiple instances of the same BFM
> (pin-wiggle) class for example to be driving different
> pin-compatible logical interfaces on your DUT and is the one that
> I'm most interested in.
I suppose the BFM would be a Ruby method then:
def wiggle iface
iface.some_signal.z!
iface.another_signal.intVal = 55
end
wiggle mod1
wiggle mod2
