LTspice gate parameters

[Wimberleytech]

What gives?  I seldom use logic gates in LTSpice.  If I need one, I generally just make it out of MOSFETs. 

Today I thought I would build a logic circuit using the digitallib. 

LTSpice seems to ignore the dynamic parameters (e.g., td).

What am I doing wrong  .

* F:\Documents\LTspiceXVII\nonOverlap.asc
XU1 N001 N005 N002 NAND_2 Trise=50n Tfall=50n td=50n
XU2 N004 N008 N006 NAND_2 Trise=50n Tfall=50n td=50n
XU3 N001 N001 N008 NAND_2 Trise=50n Tfall=50n td=50n
V1 N001 0 PULSE(0 5 0 .1u .1u 50u 100u 100)
XU4 N002 N002 N003 NAND_2 Trise=50n Tfall=50n td=50n
XU5 N006 N006 N007 NAND_2 Trise=50n Tfall=50n td=50n
XU6 N003 N003 N004 NAND_2 Trise=50n Tfall=50n td=50n
XU7 N007 N007 N005 NAND_2 Trise=50n Tfall=50n td=50n
.tran 200u
.lib DigitalLogic.lib
.backanno
.end

[Ian.M]

The gates and Schmitt trigger devices supply no timestep information to the simulation engine by default. That is, they don't look when they are about to change state and make sure there's a timestep close to either side of the state change. The instance parameter tripdt can be set to stipulate a maximum timestep size the simulator takes across state changes.

You *MUST* force a timestep an order of magnitude smaller than the rise/fall times or propagation delay during transitions by setting tripdt accordingly for each gate instance, otherwise LTspice simply interpolates between the digital output levels at the nearest timesteps caused by other parts of the sim, loosing propagation delays and rise/fall times that lie in between them.

[Wimberleytech]

The gates and Schmitt trigger devices supply no timestep information to the simulation engine by default. That is, they don't look when they are about to change state and make sure there's a timestep close to either side of the state change. The instance parameter tripdt can be set to stipulate a maximum timestep size the simulator takes across state changes.

You *MUST* force a timestep an order of magnitude smaller than the rise/fall times or propagation delay during transitions by setting tripdt accordingly for each gate instance, otherwise LTspice simply interpolates between the digital output levels at the nearest timesteps caused by other parts of the sim, loosing propagation delays and rise/fall times that lie in between them.

Like this?:
XU7 N001 N001 N008 NAND_2 td=100n tripdt=10n

[Ian.M]

Yes that should work, provided the time between consecutive input transitions is greater than td as the min. input hold time is also set by td.

N.B you may observe an A type gate working correctly without the tripdt parameter if some other part of the sim forces small enough time steps, either explicitly in the .tran command or by a high enough frequency signal.  However that typically results in a very slow sim as unlike per-instance tripdt  it cant skip over periods where the gate inputs are steady state.

Edit: thanks eblc1388 for pointing out a bad typo - see spelling of 'tripdt' in the quote below!

[Wimberleytech]

Yes that should work, provided the time between consecutive input transitions is greater than td as the min. input hold time is also set by td.

N.B you may observe an A type gate working correctly without the tripdt parameter if some other part of the sim forces small enough time steps, either explicitly in the .tran command or by a high enough frequency signal.  However that typically results in a very slow sim as unlike per-instance triptd  it cant skip over periods where the gate inputs are steady state.

OK, I think I get it.  Thanks. 
In the future, if it is important, I will just build my own logic subcircuits and pay the penalty in time.  This was not really important...was just thinking about an easy way to construct a non-overlapping clock generator rather than constructing it with pulse or pwl.   Here is the transistor-level version...but it is overkill.

* F:\Documents\LTspiceXVII\nonOverlap.asc
V1 N001 0 PULSE(0 5 0 .1u .1u 50u 100u 100)
M1 N003 N001 N006 N006 CMOSN w=10u l=.5u
M2 N003 N002 VDD VDD CMOSP w=20u l=.5u
M3 N003 N001 VDD VDD CMOSP w=20u l=.5u
M4 N006 N002 0 0 CMOSN w=10u l=.5u
V3 VDD 0 5
M5 N008 N007 N010 N010 CMOSN w=10u l=.5u
M6 N008 N005 VDD VDD CMOSP w=20u l=.5u
M7 N008 N007 VDD VDD CMOSP w=20u l=.5u
M8 N010 N005 0 0 CMOSN w=10u l=.5u
M10 N004 N003 VDD VDD CMOSP w=20u l=.5u
M12 N004 N003 0 0 CMOSN w=10u l=.5u
M9 N005 N004 VDD VDD CMOSP w=20u l=.5u
M11 N005 N004 0 0 CMOSN w=10u l=.5u
M13 N009 N008 VDD VDD CMOSP w=20u l=.5u
M14 N009 N008 0 0 CMOSN w=10u l=.5u
M15 N002 N009 VDD VDD CMOSP w=20u l=.5u
M16 N002 N009 0 0 CMOSN w=10u l=.5u
M17 N007 N001 VDD VDD CMOSP w=20u l=.5u
M18 N007 N001 0 0 CMOSN w=10u l=.5u
.model NMOS NMOS
.model PMOS PMOS
.lib F:\Documents\LTspiceXVII\lib\cmp\standard.mos
.tran 0 200u
.include model.txt
.backanno
.end

Thanks again...

[SiliconWizard]

Of course, using LTSPice's logic gates will get you much faster simulation times than using hand-crafted, analog versions of them. LTSpice basically does mixed-signal simulation when using its embedded logic gates.

The latter approach will give you something more realistic.
I suggest building your own library of gates with subcircuits. Once you've done that, you can reuse them just as easily as using the provided logic gates. But yes, simulation times will be much longer.

Note that for using custom voltage sources like this, LTSpice allows you to use PWL data from a file instead of typing in the values (which is error prone and very tedious.) You can then generate this file either by hand or automatically from some script with your favorite language. A time saver.