trying to understand timings of 74LS74

[Clunixchit]

Hello there,
While
* trying to learn vhdl by myself and
* at the same time trying to master the differences and the
limitations of vsim (modelsim) and ghdl,
i decided to write the vhdl code of 74LS74 of motorolla so that the
simulations take into consideration the time delays.

It is quite confusing to implement those time delays on the DFF.

Normally on every rising edge of the clock the contents of data_in
will be transferred to q_out of the DFF.
My main problem is that how should I write the vhdl code so that it
knows when to apply
* t_phl or
* t_plh with respect to data_in ?

http://www.ortodoxism.ro/datasheets/motorola/SN74LS74N.pdf

regards,
Chitlesh

 

[Jonathan Bromley]

On Sun, 03 Jun 2007 18:30:30 -0000, Clunixchit <chitlesh@gmail.com>
wrote:

Hello there,
While
* trying to learn vhdl by myself and
* at the same time trying to master the differences and the
limitations of vsim (modelsim) and ghdl,
i decided to write the vhdl code of 74LS74 of motorolla so that the
simulations take into consideration the time delays.

It is quite confusing to implement those time delays on the DFF.

Normally on every rising edge of the clock the contents of data_in
will be transferred to q_out of the DFF.
My main problem is that how should I write the vhdl code so that it
knows when to apply
* t_phl or
* t_plh with respect to data_in ?

http://www.ortodoxism.ro/datasheets/motorola/SN74LS74N.pdf

Tplh and Tphl are NOT with respect to data_in, they are with
respect to the clock (and set and reset) signals.

You can easily model this kind of delay in VHDL. I'll give you
the answer for a flip-flop with no set or reset, and leave it
to you to add the set and reset inputs...

First let's do a FF with zero delay.

process (clock)
begin
if rising_edge(clock) then
q_out <= data_in;
end if;
end process;

Now let's add a clock-to-output delay that is the same
for rising and falling edges. For flexibility we create
a named constant for the delay.

architecture .....
constant Tcq: time := 25 ns;
begin
process (clock)
begin
if rising_edge(clock) then
q_out <= data_in after Tcq;
end if;
end process;
end

Now let's get a bit more sophisticated. The output will remain
stable for a short time after the clock. Your data sheet doesn't
specify this time, but it's clear that it must be at least 5ns
(if it were less than 5ns, then you could not connect the output
of one of these FFs to the input of the next, because it would
violate the input hold time spec!). So we make the modelling
more realistic by making the output temporarily go to X.

architecture .....
constant Tcq: time := 25 ns; -- clock-to-output delay (max)
constant Tqh: time := 7 ns; -- output hold time (min)
begin
process (clock)
begin
if rising_edge(clock) then
q_out <= 'X' after Tqh, data_in after Tcq;
end if;
end process;
end

Oh, can you see what's wrong? If the output "changes" from '0'
to '0', or from '1' to '1', then we do NOT want an X to appear!
The output should remain stable! So let's get even more clever:
If there is no output change, we DON'T put a new value on q_out.

architecture .....
constant Tcq: time := 25 ns; -- clock-to-output delay (max)
constant Tqh: time := 7 ns; -- output hold time (min)
begin
process (clock)
begin
if rising_edge(clock) then
if q_out /= data_in then
-- we need to change the output
q_out <= 'X' after Tqh, data_in after Tcq;
end if;
end if;
end process;
end

Nearly there! Now let's add just one more sophistication:
different delays for rising and falling edges of the output.

architecture .....
constant Tphl: time := 40 ns; -- falling output delay (max)
constant Tplh: time := 25 ns; -- rising output delay (max)
constant Tqh: time := 7 ns; -- output hold time (min)
begin
process (clock)
begin
if rising_edge(clock) then
if q_out /= data_in then
-- we need to change the output
if data_in = '0' then
-- falling output, use Tphl
q_out <= 'X' after Tqh, '0' after Tphl;
elsif data_in = '1' then
-- rising output, use Tplh
q_out <= 'X' after Tqh, '1' after Tplh;
else
-- output becoming unknown
q_out <= 'X' after Tqh;
end if;
end if;
end if;
end process;
end

Hope this helps a little.

NOTE to VHDL experts: Yes, I know that this model is far from
perfect - in particular, the data_in input value should be
collapsed to one of X/0/1. But I thought the poster probably
has at least enough to worry about already, without adding
that extra complication...

NOTE to everyone: I think that Motorola data sheet is WRONG!
Surely, surely, the Tphl should be SHORTER than Tplh, for TTL
technology???
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.