#20 multiple "real" drivers

[h2opolo]

I have another test case for reals. I want to be able to the same signal which has a type "real" from multiple sources. It doesn't seem to work for me. If you comment out the line "rcvr U1b(vo);" it works fine; but if I add another module then it chokes. I know this sort of thing does work for VCS and NCVerilog with a System Verilog option. I was hoping this would work for iverilog since it can handle "real" types. In VCS, I have to add a qualifier in establishing the type. Instead of

real vo;

it would be:

ref real vo;

Take a look at the testcase and let me know what you think:

//TESTCASE

module top();

wire real vo;

rcvr U1(vo);
rcvr U1b(vo);

drvr U2(vo);
// chokes on the following if there is something
// else attached to vo even if it also is real
drvr2 U2a(vo);

initial
begin
$dumpvars(0);
$dumpfile("output.vcd");
#4100;
$finish;
end

endmodule

module rcvr(vo);
input vo;
wire real vo;

always @(vo)
begin
$display(" \nI am printing a real value %f at %g\n", vo,$time);
end

endmodule

module drvr(vo) ;
output vo;
real vo;
initial begin
vo = 3.3;
#1000 vo = 4.5776;
#2000 vo = -4;
end

module drvr2(vo) ;
output vo;
real vo;
endmodule

[h2opolo]

real test

[Stephen Williams]

Logged In: YES
user_id=97566
Originator: NO

Verilog doesn't support multiple drivers for a real. What you've done in the SystemVerilog case is not multiply-drive a real net, but share a real variable by reference.

So what do you suppose happens if two drivers drive two different values to a real net?

[h2opolo]

Logged In: YES
user_id=1970489
Originator: YES

In the case of two different drivers driving different values to a real net, I would think you call it a contention case just like two different booleans with the same strength. I don't know how this maps into real space; but it would be nice if there was a contention case for reals. The other possibility is you let it resolve by whatever updates it last just like a register (I guess this sort achieves which you describe as sharing with reference). If we could model reals, this opens up the possibility of doing mixed signal simulation of huge designs.
Here are some other thoughts. For example a dumb example would be an inverter, instead of logic signals I could use reals. There are two transistors driving the same "real" node just not simultaneously. A better example is a level shifter which uses other voltages than the input voltage. What if I wanted to simulate multiple power domain designs? Verification is not as straightforward with treating everything as booleans.

[Stephen Williams]

Logged In: YES
user_id=97566
Originator: NO

Bool nets also cannot have multiple drivers. Them's the rules. If you want to handle multiple drivers, you must use logic values (using SystemVerilog terminology, which Icarus Verilog does support to some degree) since only the logic type has resolution rules.

For the other functionality you are after, you are talking about Verilog-AMS, and there is specific syntax to handle that.

And consider what happens when you have two transistors driving two different "voltages" onto a wire. What you get will depend on the *current* through the devices, and parasitic resistances of the circuit. All this is exactly what Verilog-AMS is about.

What you've done with SystemVerilog is to link a variable around, and I think what you get is the last assignment to the variable, without resolution. In fact it is not a net at all.

I'm converting this PR into a Feature Request.

[h2opolo]

Logged In: YES
user_id=1970489
Originator: YES

An inverter has two devices (nmos and pmos) driving a single net and therefore there is a possibility of contention and Verilog handles this. That's all I was really trying stating. Therefore my humble request is to have two or more "real" drivers which can drive a single net. They wouldn't drive the net at the same time just like an inverter. In the test case I sent, one of the drivers was a stub and therefore wasn't actively driving the net.
I have been using Verilog AMS and it has been disappointing to see the performance which is why I've turned to looking at things like System Verilog and Cosimulation of myhdl with iverilog. If there are a lot of nets, it still computationally intensive for an Analog solver to form the circuit matrix, compute the Jacobian based on some integration method. Oh by the way I appreciate the ease at which I can co-simulate Iverilog with myhdl.
In general I love your tool and I appreciate the capability it offers to the design community, you do an incredible service. Please keep up the good work and please consider my request.

Jon

[Cary R.]

Logged In: YES
user_id=1651735
Originator: NO

Jon,

Here's an excerpt from the V-AMS manual.

"Verilog-AMS HDL supports ports which are declared to be real-valued and have a discrete-time discipline. This is done using the net type wreal (defined in 3.7). There can be a maximum of one driver of a real-valued net."

So the one standard that you would expect to allow multiple real drivers strictly forbids them. FYI "wreal" is similar to, maybe the same as, "wire real" in Icarus. I would strongly advocate that we don't try to invent a method for real resolution. I have always been able to write an appropriate analog model with only one driver. Here's a simple example of a digital input real output buffer. It has a single driver, but also has controllable output levels. Much more than this and you should be using a full continuous time simulation engine and right now Icarus doesn't support that.

module top;
reg in = 1'b0;
wire real rout = in ? 2.65 : 0.05;

initial begin
$monitor(in,, rout);
#1 in = 1'b1;
// For an `bx or `bz select the resolution is specified to be 0.0.
#1 in = 1'bx;
#1 in = 1'bz;
end

endmodule

Icarus supports the Verilog-A/(1364-2005)? math functions either directly with a flag using the latest code from git or as an extension that you can download from the download section. The version available as a separate download has an example Verilog file with some simple analog modeling.

I think this request should be closed, since this is not something we should be implementing. We need to implement a full continuous time simulation engine to do this correctly. For now there are other techniques that can be used to model this type of functionality.

[Stephen Williams]

Logged In: YES
user_id=97566
Originator: NO

I think we have concluded that double-driving real values makes no sense outside of Verilog-A/MS contribution statements, so I'm closing this feature request.