[sv-bc] FW: Matnis 1366: 1364, 14.2.1: variables as module path destinations

Mantis 1366

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
Sent: Monday, February 20, 2006 12:32 PM
To: sv-bc@eda.org
Subject: [sv-bc] 1364, 14.2.1: variables as module path destinations

Hi,

1364-2005, 14.2.1, says that a module path destination may be a variable as well as a net.

One vendor has told me that "many of us consider [this] a simple erratum in the IEEE spec".
 
Before presenting the discussion, I would like to point out that some vendors do allow variables as path destinations and I know of existing code which uses them, so changing this now would present a compatibility problem. However, it might be appropriate to add to the LRM a fuller discussion of the behavior.

Among other things, the vendor wrote:

"A reg has to be updated by behavioral code which may impose behavioral delays. Unlike distributed delays on gate and continuous assignments that drive a net, the effects
of behavioral delays cannot be changed by delay mode.

E.g. if simulated with delay_mode_path, the continuous assignment delay of #2 in cellw will be ignored, and the specify path delay #1 will be used for the actual delay from x to y. However, the behavioral delay #2 in cellr will not be ignored, and since it is bigger than the specify path delay, the actual delay from x to y will be #2, not #1.

module cellr (x, y);
    input x;
    output y;
    reg y;
    wire x;
    always @(x)
       y <= #2 x;
    specify
       (x=>y) = 1;
    endspecify
endmodule

module cellw (x, y);
    input x;
    output y;
    wire y;
    wire x;
    assign #2 y = 2;
    specify
       (x=>y) = 1;
    endspecify
endmodule"


The vendor also suggested a workaround which would give the required behavior, defining the reg as an internal signal, defining the output port as a net and adding a buffer between them, such as replacing 

module dlat(ck, db, o);  
input ck, db; 
output o;  
wire ck, db; 
reg o;     
always @ (ck or db) if(ck) o_reg <= #1 ~db;  
specify  
(ck *> o) = (0.1, 0.1);  
endspecify  endmodule

with the following:  

module dlat(ck, db, o);  
input ck, db; 
output o;  
wire ck, db, o; 
reg o_reg; 
always @ (ck or db) if(ck) o_reg <= #1 ~db; 
buf (o, o_reg);    
specify  (ck *> o) = (0.1, 0.1);  
endspecify 


To this, I replied:

"Given your explanation of how this works, what happens in this case? The buf has no inherent delay. The specify block specifies a delay from ck to o of 0.1. However, the always construct specifies a delay of #1 from ck to o_reg, where o_reg is an intermediate value on the way to o.

So what delay will there really be?"


I got the following reply:

"For the given testcase, the delay from "ck" to "o" is a bit complex. It depends on how ck and db transitions. One scenario is that,  ck transition to 1 at time T,  which causes o_reg (and hence "o") to be updated 1 ns later, at T+1, at which point, the path delay algorithm looks at ck, assuming there is no transition on ck since it transitioned to 1 at T, then (T+0.1) is the time where timing output "o" is supposed to transition, but since (T+0.1) is less than current time (T+1 ), "o" is scheduled to transition at current time, (T+1). Hence you will not see the effects of the path delay

Another scenario is, db transitioning at T (and clk is high) causes o_reg to transition at T+1. if clk transition to low after (T + 0.9) but before (T+1), then "o" will be scheduled to transition at 0.1ns after clk transition. The path delay is in effect in this case.

This behavior will be the same even if it is explicitly run in path_delay_mode, since the delays in the always statement will not be ignored regardless. That's difference between these delays and the structural delays."


To which I replied:

"So as I understand it, the same problem occurs both if the module path delay is specified on a net output which buffers the reg variable or if the module path delay would be specified directly on the reg variable (as the standard permits).

This behavior is not explained in the standard, I think.

So the workaround (which is what I told my user to do) does not really solve the problem you state."


I have not yet received a reply from the vendor, so that is where it stands currently.

I would like to hear what other members of the committee think about this feature of the standard.

Thanks,
Shalom 


Shalom Bresticker
Intel Jerusalem LAD DA
+972 2 589-6852
+972 54 721-1033
I don't represent Intel