Hi - we're finding some verilogams models run fine with cellview based netlister, but have functional errors with OSS based.

Are there any guidelines or differences in how the models should be written?

Also, I find sometimes the verilogams cellview misses the .cdb file upon creation --- which is a show stopper for OSS.  Any reason for this?



thanks,
Wave

Andrew - thanks for the reply on .cdb files.  Very useful.

I actually asked Mr. Spectre himself look at the code a bit and he narrowed it down to this region.  Vreg is within our tolerance limits, but something is sequenced (initial conditions) in the simulator to catch vreg_ok=0.

I guess there are more robust ways to write this for OSS.  
How specifically, I'm not sure...

regards,
Wave

//-- vreg

 always @(above(V(vreg,vssa) - vreg_min)) begin
   vreg_ok = 1;
   if(debug)
     $strobe("%t: %m: vreg_ok = %0b", $realtime, vreg_ok);
 end // vreg > vreg_min

 always @(above(-1.0*(V(vreg,vssa) - vreg_min))) begin
   vreg_ok = 0;
   $strobe("%t: %m: vreg has fallen below .  vreg_min = %e", $realtime, vreg_min);
 end // vreg < vreg_min

 always @(above(V(vreg,vssa) - vreg_max)) begin
   vreg_ok = 0;
   $strobe("%t: %m: ***WARNING*** vreg has risen above vreg_max.  vreg_max = %e", $realtime, vreg_max);
 end // vreg > vreg_max

Wave,
   I believe you have a race condition due to an ambiguity in your code. The problem is not with the oss netlister per see. The problem is that at time=0 the value of vreg starts off 0 and then immediately shifts to a value between vreg_min and vreg_max. So it is both above and below the threshold at time 0. As a result both the first two always blocks are executed 'simultaneously', and it is indeterministic which is executed last. This is a subtle case that probably should be handled better by the simulator.  However the situation is easy to remedy. Simply start vreg at 0 and then transition it to the desired value a short time after the simulation starts.

-Ken