triggering off of CMOS pads problem 
Author Message
 triggering off of CMOS pads problem

I hope I can explain my problem clearly, perhaps others have seen it.  
I'm attempting to use Verilog to simulate a CMOS chip design, and to do so
I've written several behavi{*filter*}models of other system blocks that talk to
my chip.

In particular one is a D/A converter with a serial interface, the system isn't
written in stone so I just picked the AD7869 as an example.  The serial
transmission clock has a minimum clock period requirement so I encoded that
in a $period system task to check.

Now I try to attach my behavi{*filter*}model in the real world.  My CMOS pad
drivers consist of P & N transistors to connect the pad to VDD or VSS,  they
are built so that when switching neither one will be changing at the same
time to avoid a condition when both are turned on causing a massive drain
from VDD to VSS and a toasted chip.  What this all means is the pads in
simulation always transition through HiZ to the next state.

The Verilog problem is this:  the $period system task uses the negedge
code of Verilog, which views transitions from 1->HiZ and HiZ->0 as a
negative edge, therefore it thinks the clock period is 1.5nS or something,
instead of 150nS!  Has anyone seen this 'real world' problem before?
Any solutions?

I saw the problem earlier in my behavi{*filter*}code:

  // No time delay code
  //
end

This always block would active *twice* per edge of sclock!  My kludge solution
was to put a #5 delay in just to avoid multiple activations per edge.
(Almost the exact opposite problem of previous messages in this group!)

I hope this wasn't too long winded and confusing.  Any help or discussion is
appreciated.  I'm hoping the answer isn't "don't use it"

Thanks,


ADG, Tektronix, Inc.            (503) 627-2140
Beaverton, OR



Sun, 06 Oct 1996 02:06:59 GMT  
 triggering off of CMOS pads problem

Quote:

>I hope I can explain my problem clearly, perhaps others have seen it.  
> [...]
>transmission clock has a minimum clock period requirement so I encoded that
>in a $period system task to check.

>Now I try to attach my behavi{*filter*}model in the real world.  My CMOS pad
> [...]
>from VDD to VSS and a toasted chip.  What this all means is the pads in
>simulation always transition through HiZ to the next state.

>The Verilog problem is this:  the $period system task uses the negedge
>code of Verilog, which views transitions from 1->HiZ and HiZ->0 as a
>negative edge, therefore it thinks the clock period is 1.5nS or something,
>instead of 150nS!  Has anyone seen this 'real world' problem before?
>Any solutions?

>I saw the problem earlier in my behavi{*filter*}code:
>[...]

>I hope this wasn't too long winded and confusing.  Any help or discussion is
>appreciated.  I'm hoping the answer isn't "don't use it"

>Thanks,


>ADG, Tektronix, Inc.                (503) 627-2140
>Beaverton, OR

As usual, it seems, when I post to this group I either come up with my own
answer or someone stops me in the hallway.  This was the latter case.
Here is some Verilog code that I wrote to illustrate the problem and also
my solutions:

`timescale 1 ns / 10ps
//This file will test Verilog's opinion of what is a negative edge:
// 1->HiZ?
// HiZ->0?

module test_negedge ;

  reg test;                             /* The test edge */
  wire test2 = test;                    /* $period only checks wires, not reg */

  reg thing1, thing2;

  specify
    $period(edge[10,x0] test2, 1, thing1);      /* 'New method' */
    $period(negedge test2, 1, thing2);          /* my 'old' method */
  endspecify

  // Show always block problem

    $display("%t Saw edge! test = %b",$time,test);

  // Show My kludge solution  

    $display("%t Saw edge with kludge sol'n! test = %b",$time,test);
    #2;                         /* Must be greater than transition time */
                                        /* But less than period */
  end

  // flag edges with edge construct

    $display("%t Saw period violation of new stuff! test = %b",$time,test);

    $display("%t Saw period violation of old stuff (expected)! test = %b",$time,test);

  initial begin
    test = 1;
    #0.5 test = 1'bz;
    #0.5 test = 1'b0;
    #5;
    test = 1'bz;
    #0.5 test = 1'b1;
    #5;
  end

endmodule //of test_negedge

-------------------------------------------------------------------
The above source illustrates both my $period problem plus the behavi{*filter*}
always statement with no delay.  It's interesting to note that I used the
construct "edge[10,x0] test2" to get the $period to work (This construct means
reference event is whenever test2 goes 1->0 or x(or z)->0) but that
construct doesn't work in the always activation.  So I had to keep the kludge
solution.  Verilog output is:

Tektronix Verilog Wrapper Version 2b1 - Tektronix, Inc.
********************************************************************
**                                                                **
**     verilog v1.7 (Wrapper Version 2b1, Tektronix, Inc.)        **
**            for use with R34 and R35 LMC libraries              **
**                                                                **
********************************************************************
VERILOG-XL 1.7   Apr 19, 1994  13:49:21
  * Copyright Cadence Design Systems, Inc. 1985, 1988.    *
  *     All Rights Reserved.       Licensed Software.     *
  * Confidential and proprietary information which is the *
  *      property of Cadence Design Systems, Inc.         *
Compiling source file "negedge.v"
Highest level modules:
test_negedge

                 100 Saw edge with kludge sol'n! test = z
                 100 Saw edge! test = z
                 100 Saw edge! test = 0

"negedge.v", 15: Timing violation in test_negedge
    $period( negedge test2:50,  : 100,  1.00 : 100 );

                 100 Saw period violation of old stuff (expected)! test = 0
44 simulation events + 5 accelerated events + 20 timing check events
CPU time: 0.1 secs to compile + 0.0 secs to link + 0.0 secs in simulation
End of VERILOG-XL 1.7   Apr 19, 1994  13:49:22

As you can see, the new $period command doesn't report a violation and the
kludged always block only triggers once.

I hope someone has benefitted from my question, if you ever think I'm wasting
bandwidth please tell me.

Thanks again.


ADG, Tektronix, Inc.            (503) 627-2140
Beaverton, OR



Sun, 06 Oct 1996 04:58:22 GMT  
 triggering off of CMOS pads problem
One alternative is to use a signal strength greater than hiz, one of the
charge strengths, possibly. In real life, CMOS has a charge capacitance,
and you would not expect to see a hiz. A hiz fries your inputs.

                                                John Williams



Sun, 06 Oct 1996 15:23:11 GMT  
 triggering off of CMOS pads problem

Quote:

>Now I try to attach my behavi{*filter*}model in the real world.  My CMOS pad
>drivers consist of P & N transistors to connect the pad to VDD or VSS,  they
>are built so that when switching neither one will be changing at the same
>time to avoid a condition when both are turned on causing a massive drain
>from VDD to VSS and a toasted chip.  What this all means is the pads in
>simulation always transition through HiZ to the next state.

>The Verilog problem is this:  the $period system task uses the negedge
>code of Verilog, which views transitions from 1->HiZ and HiZ->0 as a
>negative edge, therefore it thinks the clock period is 1.5nS or something,
>instead of 150nS!  Has anyone seen this 'real world' problem before?
>Any solutions?

I too had a similar problem building a behavi{*filter*}dram model, that
blew up in a similar manner. I ended up adding a section to the
ram inputs that cleaned up the ras input:

input RAS;
wire RAS;
reg cleanras;


begin

  if(RAS == 0) cleanras = 0;
  else ras = 1;

end

You have to decide what your "X" values get turned into, but thats the
basic idea. You may have to put this X filter external to the model
you built, since you are using the $period command, which only works
on module ports.

--
Gord Wait       S-MOS Systems Vancouver Design Centre
                (B.C. Canada eh!)



Mon, 07 Oct 1996 02:49:02 GMT  
 triggering off of CMOS pads problem

Quote:

>The Verilog problem is this:  the $period system task uses the negedge
>code of Verilog, which views transitions from 1->HiZ and HiZ->0 as a
>negative edge, therefore it thinks the clock period is 1.5nS or something,
>instead of 150nS!  Has anyone seen this 'real world' problem before?
>Any solutions?

>I saw the problem earlier in my behavi{*filter*}code:

>  // No time delay code
>  //
>end

>Thanks,


>ADG, Tektronix, Inc.                (503) 627-2140
>Beaverton, OR

You could use the technique that is frequently used in VHDL: detect
a negative edge and then qualify that the sclk level is 0 (or
store the latest sclk_was1 time and compare that time to the time
when sclk===1'b0, and verify that the transition from 1->0 falls
within your defined transition limits.

I have seen similar problems simulating differential signals with
backannotated etch delays. The differential models had to check for
an acceptable L->H & H->L transition window between the differential
pair.

The easier (working) example is shown below.

Regards - Cliff

============================================================================
=  Cliff Cummings - Principal Engineer
=                   Verilog/Xilinx/LMC Training, Consulting & Contracting
=  Qualis Design Corporation

=  15455 N.W. Greenbrier Parkway          Voice:  (503) 531-0377
=  BEAVERTON OR 97006                     FAX:    (503) 629-5525
============================================================================

===== Paul.v =======================================================

module Paul;
reg sclk;
integer a;

  initial begin
    a = 0;
    sclk = 1'b0;
    forever begin
      #49 sclk = 1'bz; #1  sclk = 1'b1; // pseudo rising edge
      #49 sclk = 1'bz; #1  sclk = 1'b0; // pseudo falling edge
    end
  end


    if (sclk === 1'b0) begin
      a = a + 1;
      if (a == 6) $finish;
    end
  end

  initial $monitor($stime,": sclk = %b    a = %d", sclk, a);
endmodule



Thu, 10 Oct 1996 09:55:50 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Trigger-On/Trigger-Off Data Acquisition?

2. waiting on scope to trigger, or aborting before trigger

3. analog level triggering of storage with trigger output

4. I want to change my trigger a for the trigger b in my labview window

5. Decimal point key on the keyboard number pad problem

6. File Padding Problem in Novell 3.75

7. padding problems with nasm

8. Number Pad problems

9. Question for DAQ expert: hardware trigger problem with AT-MIO-16X

10. problem with analog triggering

11. trigger problems

12. Verilog coding problem -- about Edge Trigger

 

 
Powered by phpBB® Forum Software