Pulse stretching

[Shannon]

Since everyone has been so helpful lately I thought I'd press my luck
with a nagging problem I keep running into.

Many times in a syncronous domain I end up with some "enable" pulse
that is exactly one clock wide. Let's say I want to use that enable
to start a counter for some reason. I want the counter to start
counting when enable is true but keep counting until it's done. Let's
say it's a down counter counting down to zero.

I guess my question seems simple: How do I "latch" this enable
pulse? It seems like anything I do is in danger of a race condition.
If everything is syncronous, I can't "act" on anything until the next
clock cycle after the front edge of "enable". But exactly at that
moment, enable is going away! Seems scary.

Mike Treseler once posted the following code to "stretch" a one-clock-
wide pulse to two clocks wide:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity stretch is
port (
clk : in std_logic;
reset : in std_logic;
trig : in std_logic;
pulse : out std_logic
);
end stretch;


architecture synth of stretch is
begin
process (reset, clk) is
variable last_trig : std_logic;
begin
if reset = '0' then
pulse <= '0';
elsif clk'event and clk = '1' then
pulse <= trig or last_trig; -- pulse for 10,11,or 01
last_trig := trig; -- save trig
end if;
end process;
end synth;


Doesn't this suffer the same problem? "last_trig" is changing state
right when "trig" is going away. Same for pulse: pulse wants to
change state right as last_trig is going away.

I'm sure the code works but it's the same problem I have. It just
seems scary.

Any ideas?

Shannon

 

[Shannon]

Since everyone has been so helpful lately I thought I'd press my luck
with a nagging problem I keep running into.

Many times in a syncronous domain I end up with some "enable" pulse
that is exactly one clock wide. Let's say I want to use that enable
to start a counter for some reason. I want the counter to start
counting when enable is true but keep counting until it's done. Let's
say it's a down counter counting down to zero.

I guess my question seems simple: How do I "latch" this enable
pulse? It seems like anything I do is in danger of a race condition.
If everything is syncronous, I can't "act" on anything until the next
clock cycle after the front edge of "enable". But exactly at that
moment, enable is going away! Seems scary.

Mike Treseler once posted the following code to "stretch" a one-clock-
wide pulse to two clocks wide:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity stretch is
port (
clk : in std_logic;
reset : in std_logic;
trig : in std_logic;
pulse : out std_logic
);
end stretch;

architecture synth of stretch is
begin
process (reset, clk) is
variable last_trig : std_logic;
begin
if reset = '0' then
pulse <= '0';
elsif clk'event and clk = '1' then
pulse <= trig or last_trig; -- pulse for 10,11,or 01
last_trig := trig; -- save trig
end if;
end process;
end synth;

Doesn't this suffer the same problem? "last_trig" is changing state
right when "trig" is going away. Same for pulse: pulse wants to
change state right as last_trig is going away.

I'm sure the code works but it's the same problem I have. It just
seems scary.

Any ideas?

Shannon

I forgot to say - the reason I think it's scary is that it seems to be
begging for a hold-time violation at the input to the flip-flops.

Shannon

 

[Dave Pollum]

Since everyone has been so helpful lately I thought I'd press my luck
with a nagging problem I keep running into.

Many times in a syncronous domain I end up with some "enable" pulse
that is exactly one clock wide. Let's say I want to use that enable
to start a counter for some reason. I want the counter to start
counting when enable is true but keep counting until it's done. Let's
say it's a down counter counting down to zero.

I guess my question seems simple: How do I "latch" this enable
pulse? It seems like anything I do is in danger of a race condition.
If everything is syncronous, I can't "act" on anything until the next
clock cycle after the front edge of "enable". But exactly at that
moment, enable is going away! Seems scary.

Mike Treseler once posted the following code to "stretch" a one-clock-
wide pulse to two clocks wide:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity stretch is
port (
clk : in std_logic;
reset : in std_logic;
trig : in std_logic;
pulse : out std_logic
);
end stretch;

architecture synth of stretch is
begin
process (reset, clk) is
variable last_trig : std_logic;
begin
if reset = '0' then
pulse <= '0';
elsif clk'event and clk = '1' then
pulse <= trig or last_trig; -- pulse for 10,11,or 01
last_trig := trig; -- save trig
end if;
end process;
end synth;

Doesn't this suffer the same problem? "last_trig" is changing state
right when "trig" is going away. Same for pulse: pulse wants to
change state right as last_trig is going away.

I'm sure the code works but it's the same problem I have. It just
seems scary.

Any ideas?

Shannon

Shannon said:
Many times in a syncronous domain I end up with some "enable" pulse
that is exactly one clock wide. Let's say I want to use that enable
to start a counter for some reason. I want the counter to start
counting when enable is true but keep counting until it's done. Let's
say it's a down counter counting down to zero.

So, create a "counter_enable" FF that is set to '1' by the enable
signal and is cleared when the counter reaches 0. Naturally,
"counter_enable" should be set to '0' by the reset signal.
HTH
-Dave Pollum

 

[Shannon]

Shannon said:
Many times in a syncronous domain I end up with some "enable" pulse
that is exactly one clock wide. Let's say I want to use that enable
to start a counter for some reason. I want the counter to start
counting when enable is true but keep counting until it's done. Let's
say it's a down counter counting down to zero.

So, create a "counter_enable" FF that is set to '1' by the enable
signal and is cleared when the counter reaches 0. Naturally,
"counter_enable" should be set to '0' by the reset signal.
HTH
-Dave Pollum- Hide quoted text -

- Show quoted text -

Yes, of course that is what is done. But look closely at the timing
with that solution.

A clock edge occurs.
A propagation delay later, enable goes true.
The input to your "counter_enable" is now true and waiting for a clock
edge.
One clock later two things happen:
1) "counter_enable" attempts to clock through it's input
2) A propagation delay after the clock edge, enable goes away!
All is fine as long as the propagation delay of enable is longer than
the hold time of the "counter enable" FF.

Doesn't that sound like dicey engineering?

Have a look at what happens on the next clock edge when the counter
counts for the first time. A lot happens on that next edge!

Shannon

 

[Mike Treseler]

Doesn't that sound like dicey engineering?

If a clock enable were in the clock path, that would be true.
It is actually a mux control that sends either the input or Q
to the D input.

-- Mike Treseler

 

[Ben Jones]

Hi,

I forgot to say - the reason I think it's scary is that it seems to be
begging for a hold-time violation at the input to the flip-flops.

Shannon

Just stop being scared of it and you'll be fine.

Synchronous design is an abstraction - there is no need to think about
physical issues such as clock skew, setup times, hold times, clock-to-out
times and so on, except insomuch as they affect the amount of work you can
reasonably expect to do in one clock cycle. The back-end implementation
tools take care of all these things for you.

Forget about edges and propagation delays. Your circuit consists of
registered elements that hold the current state and get updated each clock
cycle. You write some logic to decide what the new values held in these
registered elements should be, based on their current values and the values
of the inputs. That's all there is to it.

-Ben-

 

[Brian Drummond]

Yes, of course that is what is done. But look closely at the timing
with that solution.

One clock later two things happen:
1) "counter_enable" attempts to clock through it's input
2) A propagation delay after the clock edge, enable goes away!
All is fine as long as the propagation delay of enable is longer than
the hold time of the "counter enable" FF.

Doesn't that sound like dicey engineering?

Sounds like, but isn't.

It's VERY good that you are aware of the problem; because you will be on
guard for situations where the conditions required for safety are
missing or in doubt.

For example, the enable is generated on one chip, and used on another.
That can be made to work fine, but you must take care of various
conditions yourself, when normally the tools take care of them for you.

Consider your logic in an ideal FPGA, where the counter enable is
generated *from* the clock. It cannot happen *before* the clock, and the
generating logic has some finite propagation time; therefore (this being
an ideal FPGA) the enable is guaranteed stable through the next clock.

In a real FPGA, you design as if the above situation is true. Now
typically there is a "clock skew" whereby the clock reaches different
FFs at different times; and there is a propagation delay in the signal
path (composed of both clock-to-output delay in one FF, and wire delays
to another). Provided the propagation delay is *both* guaranteed longer
than the clock skew, AND shorter than the clock period (!) the real
world design is safe.

That guarantee is the job of the FPGA supplier, (a) controlling the
processes on his chip, (e.g. providing dedicated high speed routing for
clock signals) and (b) ensuring his "static timing analysis" tools
accurately predict the delays on the routed design, to give you
confidence the above conditions are met.

Now if you gate signals together to make a clock signal, the tools
cannot route that clock through the dedicated fast clock lines, and you
should expect interesting warnings from the tools about clock skew
problems. Ignore those warnings at your peril...

- Brian

 

[Shannon]

Sounds like, but isn't.

It's VERY good that you are aware of the problem; because you will be on
guard for situations where the conditions required for safety are
missing or in doubt.

For example, the enable is generated on one chip, and used on another.
That can be made to work fine, but you must take care of various
conditions yourself, when normally the tools take care of them for you.

Consider your logic in an ideal FPGA, where the counter enable is
generated *from* the clock. It cannot happen *before* the clock, and the
generating logic has some finite propagation time; therefore (this being
an ideal FPGA) the enable is guaranteed stable through the next clock.

In a real FPGA, you design as if the above situation is true. Now
typically there is a "clock skew" whereby the clock reaches different
FFs at different times; and there is a propagation delay in the signal
path (composed of both clock-to-output delay in one FF, and wire delays
to another). Provided the propagation delay is *both* guaranteed longer
than the clock skew, AND shorter than the clock period (!) the real
world design is safe.

That guarantee is the job of the FPGA supplier, (a) controlling the
processes on his chip, (e.g. providing dedicated high speed routing for
clock signals) and (b) ensuring his "static timing analysis" tools
accurately predict the delays on the routed design, to give you
confidence the above conditions are met.

Now if you gate signals together to make a clock signal, the tools
cannot route that clock through the dedicated fast clock lines, and you
should expect interesting warnings from the tools about clock skew
problems. Ignore those warnings at your peril...

- Brian

Ok, thanks for the replies. I'm going to keep an eye on things with
the timing analyzer but like I've said before, I'm a hardware guy and
all the time I'm thinking of the actual gates and FF and wires that
are getting synthisized by the compiler.

I don't know what planet you design on Ben, but you do have to worry
about clock skew, propagation delays and setup and hold times. At the
end of the day there are physical electrons and holes that have to get
from a to b. It's just life. Ignoring it won't make it go away.
Don't you ever wonder why the tool chain has all those tools for
looking at it?

Shannon

 

[Ben Jones]

I don't know what planet you design on Ben, but you do have to worry
about clock skew, propagation delays and setup and hold times. At the
end of the day there are physical electrons and holes that have to get
from a to b. It's just life. Ignoring it won't make it go away.

Abstraction.
Ab - strac - tion.

"the act of considering something as a general quality or characteristic,
apart from concrete realities, specific objects, or actual instances."

Cornerstone of the real world.

Don't you ever wonder why the tool chain has all those tools for
looking at it?

No, I don't "wonder", I use those tools every day. I know exactly what
impact all these timing parameters of the real-life circuitry have on my
higher-level design, and I worry about them as and when necessary. This is
not sloppiness, this is the way engineering works. If you sat down to design
a digital video processing system and the first thing you worry about is
electrons and holes, you will not get very far.

Cheers,

-Ben-

 

[Mike Treseler]

I don't know what planet you design on Ben, but you do have to worry
about clock skew, propagation delays and setup and hold times.

That was Brian, not Ben, and I also design on their planet.
For FPGAs, all of the issues you raise can be covered
by design rules, simulation and static timing.
I see no advantage to going back to analog Spice
simulations of individual MOS transistors and
transmission lines.

-- Mike Treseler

ps: check out http://en.wikipedia.org/wiki/Synchronous_circuit

 

[Shannon]

That was Brian, not Ben, and I also design on their planet.
For FPGAs, all of the issues you raise can be covered
by design rules, simulation and static timing.
I see no advantage to going back to analog Spice
simulations of individual MOS transistors and
transmission lines.

-- Mike Treseler

ps: check outhttp://en.wikipedia.org/wiki/Synchronous_circuit

I think you both take my comments to literally. What I was trying to
say is that you cannot ignore the concerns I had in the original
post. And both of you admit that you DO look at (and are concerned
with): delays, skew, and hold times. Yet at the same time (if you
want me to quote I will) you say "don't worry about it." Just let the
tools "make it all work out." I just happen to think (read: my
opinion is..) that relying on the tools blindly is asking for
trouble. No, you don't have to do MOS simulations but I think that is
a far cry from worrying about data disappearing from a FF just
slightly after the flip flop clocks!!!!

But this is a digretion that doesn't benifit anyone. Back to the
problem at hand. Mike and Ben you can ignore this discussion since
you don't pay attention to such things.

Brian said:

"Consider your logic in an ideal FPGA, where the counter enable is
generated *from* the clock. It cannot happen *before* the clock, and
the
generating logic has some finite propagation time; therefore (this
being
an ideal FPGA) the enable is guaranteed stable through the next
clock."

This is true but my concern is not with the NEXT clock but with the
CURRENT clock.
To restate the problem: enable is generated from the clock as you say
somewhere else in the code. In my example this means that enable will
go FALSE on the SAME clock edge as the counter enable FF is trying to
clock through the enable from the LAST clock edge. In ascii art:

CLOCK _____^^^^^_____^^^^^_____^^^^^_____^^^^^_____
ENABLE ______^^^^^^^^^^^_________________________
CNT_ENA ______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

_______________________|_________________________ edge of doom!

If you open your basic TTL cook book from back in the day, this would
be a huge NO-NO! The hold time of the "cnt_ena" FF would almost
certainly be violated. What I'm hearing loud and clear from all of
you is that I just shouldn't worry about it. "The tools will take
care of it." Pardon me for being stuck in my ways but wouldn't it be
keen if you had code that was GUARANTEED to not have a potential
timing problem? That's all I was asking.

I'll go back to closing my eyes and hoping for the best from the
tools...

Shannon

 

[Shannon]

I think you both take my comments to literally. What I was trying to
say is that you cannot ignore the concerns I had in the original
post. And both of you admit that you DO look at (and are concerned
with): delays, skew, and hold times. Yet at the same time (if you
want me to quote I will) you say "don't worry about it." Just let the
tools "make it all work out." I just happen to think (read: my
opinion is..) that relying on the tools blindly is asking for
trouble. No, you don't have to do MOS simulations but I think that is
a far cry from worrying about data disappearing from a FF just
slightly after the flip flop clocks!!!!

But this is a digretion that doesn't benifit anyone. Back to the
problem at hand. Mike and Ben you can ignore this discussion since
you don't pay attention to such things.

Brian said:

"Consider your logic in an ideal FPGA, where the counter enable is
generated *from* the clock. It cannot happen *before* the clock, and
the
generating logic has some finite propagation time; therefore (this
being
an ideal FPGA) the enable is guaranteed stable through the next
clock."

This is true but my concern is not with the NEXT clock but with the
CURRENT clock.
To restate the problem: enable is generated from the clock as you say
somewhere else in the code. In my example this means that enable will
go FALSE on the SAME clock edge as the counter enable FF is trying to
clock through the enable from the LAST clock edge. In ascii art:

CLOCK _____^^^^^_____^^^^^_____^^^^^_____^^^^^_____
ENABLE ______^^^^^^^^^^^_________________________
CNT_ENA ______________^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

_______________________|_________________________ edge of doom!

If you open your basic TTL cook book from back in the day, this would
be a huge NO-NO! The hold time of the "cnt_ena" FF would almost
certainly be violated. What I'm hearing loud and clear from all of
you is that I just shouldn't worry about it. "The tools will take
care of it." Pardon me for being stuck in my ways but wouldn't it be
keen if you had code that was GUARANTEED to not have a potential
timing problem? That's all I was asking.

I'll go back to closing my eyes and hoping for the best from the
tools...

Shannon

Ok, the ascii art didn't work out. CNT_ENA is supposed to be rising
on the same clock edge as ENABLE is falling.

 

[Ben Jones]

Then don't rely on the tools blindly - do it with your eyes open.

There are basically just two ways these low-level properties of the FF
circuits (which incidentally are a far cry from anything you'll find in a
TTL databook) manifest themselves at the "synchronous design" abstraction
level:

(1) A delay at the start of the clock cycle before the contents of a
register propagates out;

(2) A delay at the end of the clock cycle before which the new value to go
into a register must be ready.

The problems of skew and race conditions between clock and data are
mitigated down to negligible levels by the dedicated very-low-skew clock
distribution hardware in an FPGA. Effectively all clock edges happen
everywhere at the same time, to within a few ps (and the tools even know
precisely about those few ps and take them into account). With a single
clock in your circuit, all you have to concern yourself with is fitting all
your logic into the time available in the clock cycle.

So, say if you're designing a circuit to run at 200MHz, you have a 5ns clock
period, of which say 300ps is taken up by the clock-to-out of the source
register, 300ps by the setup time of the destination register, and the rest
is available for logic delays and routing delays. That's it.

Pardon me for being stuck in my ways but wouldn't it be
keen if you had code that was GUARANTEED to not have a potential
timing problem?

All circuits do! A circuit designed to run at 100MHz has a potential timing
problem in that if someone decides to run it at 200MHz, it won't work
because all the timing parameters of the synchronous elements it contains
will be violated. The synthesis, mapping, placing and routing tools from
FPGA/EDA vendors are all timing-aware, and the timing engines have margins
built into them to account for process and temperature variations. And if
you're really paranoid these can be de-rated further simply by speccing the
static timing for 110MHz when you know you're only going to run at 100MHz.

I don't think any of these assumptions are less reasonable than the
assumption you are making that the value of every node inside your circuit
is either a 0 or a 1. Do you worry that the signals in your circuit are
really analogue, and they might have ringing if they toggle too fast or they
might droop if the fanouts are too high and the driving transistors aren't
strong enough? I don't. That level of abstraction is taken care of by the
nice people who make the chips, so I don't have to worry about it.

Cheers,

-Ben-

 

[Brian Drummond]

To restate the problem: enable is generated from the clock as you say
somewhere else in the code. In my example this means that enable will
go FALSE on the SAME clock edge as the counter enable FF is trying to
clock through the enable from the LAST clock edge.

not ON; but AFTER the same clock edge. Some guaranteed time after, in
the common case. Some guaranteed time _greater_ than the clock skew.

If you open your basic TTL cook book from back in the day, this would
be a huge NO-NO! The hold time of the "cnt_ena" FF would almost
certainly be violated.

Depends on the MINIMUM clk-out time of the previous stage. Which
typically wasn't specified or guaranteed; therfore you couldn't
undertake the same analysis by hand, which the tools now do for you.

What I'm hearing loud and clear from all of
you is that I just shouldn't worry about it. "The tools will take
care of it."

Or warn you if they can't (e.g. gated clocks).

You DO have to pay attention at the I/O pins, which interface to other
devices. IO blocks usually have provision (such as IOBDELAY) to allow
meeting timings too.

- Brian

 

[Shannon]

not ON; but AFTER the same clock edge. Some guaranteed time after, in
the common case. Some guaranteed time _greater_ than the clock skew.


Depends on the MINIMUM clk-out time of the previous stage. Which
typically wasn't specified or guaranteed; therfore you couldn't
undertake the same analysis by hand, which the tools now do for you.


Or warn you if they can't (e.g. gated clocks).

You DO have to pay attention at the I/O pins, which interface to other
devices. IO blocks usually have provision (such as IOBDELAY) to allow
meeting timings too.

- Brian

Ok, I think I'm getting it now. Thanks Brian. I guess the key
sentence for me was "Some guaranteed time _greater_ than the clock
skew."

The key take-away for me is that the tool will do it's best to make it
happen and report it when it can't. I can't help but feel let down by
this however. When I solve engineering problems I like to find
solutions that -- by their nature -- solve the problem by eliminating
the source. It's nice when the tools I use can compensate for the
design error but I always feel better when I have solved something in
such a way as to not have to rely on the tools.

Put another way, say you design an amplifier. You can trust that
purchasing will buy 1% resistors for you so that your gain is what you
designed it to be. OR... you can design an amplifier that can handle
10% resistors and STILL provide the gain you wanted. I just hate to
"trust" purchasing in the same way I hate to "trust" Quartus. If I
had a way to make sure enable stuck around long enough to GUARANTEE it
was there long enough for the next FF. For example, clocking the next
FF with the falling edge of clock instead.

Shannon

 

[KJ]

Ok, I think I'm getting it now. Thanks Brian. I guess the key
sentence for me was "Some guaranteed time _greater_ than the clock
skew."

The key take-away for me is that the tool will do it's best to make it
happen and report it when it can't. I can't help but feel let down by
this however. When I solve engineering problems I like to find
solutions that -- by their nature -- solve the problem by eliminating
the source. It's nice when the tools I use can compensate for the
design error but I always feel better when I have solved something in
such a way as to not have to rely on the tools.

If you use a synchronous design method then it really has absolutely nothing
to do with 'the tools'. The real engineering went into the design of the
part itself....the flip flops, the clock distribution, etc. that is the
reason it all works and one usually doesn't have to think about it too hard.
It's not the tools, but the parts. The parts have things like global clock
distribution and they know exactly where the flops and memories and anything
else that 'could' be clocked are located and the engineering effort by the
FPGA suppliers went into guaranteeing that no matter where you are on the
device, any two clocked devices can reliably send a signal from any place to
any other place without violating setup/hold requirements.

What the tools really bring to the table is that they can quickly perform
the full static timing analysis for you and let you know where timing breaks
down because the logic path is too long for the given clock speed or I/O
setup to Tco specifications that you require can or can not be met.

Now when you start trying to implement things that deviate from the
synchronous style (like generating gated clocks and such) you're starting to
take on some design risk in many cases or making the design susceptible to
working/not working when you make 'simple' design changes. Here the
software tool is doing it's best and will still perform the timing analysis
for you and dutifully report violations but you're making things harder than
they generally need to be....either that or maybe an FPGA is not really the
proper thing to be implementing that particular design in since it doesn't
lend itself to synchronous methods for whatever reason.

Put another way, say you design an amplifier. You can trust that
purchasing will buy 1% resistors for you so that your gain is what you
designed it to be. OR... you can design an amplifier that can handle
10% resistors and STILL provide the gain you wanted. I just hate to
"trust" purchasing in the same way I hate to "trust" Quartus.

The only 'trust' is that they properly performed the timing analysis for
you.....along with the complete blind faith that one must have that they
translated your code into something that is functionally identical using
LUTs, flops and memories.

If I
had a way to make sure enable stuck around long enough to GUARANTEE it
was there long enough for the next FF. For example, clocking the next
FF with the falling edge of clock instead.

Ask yourself then how would you go about performing static timing analysis
inside the FPGA? You'd need to get all the info and assemble it and perform
what should be the same calculations that the tool performs....how would you
validate that you did it correctly?

Again, for a synchronous method, you're trusting the tool to perform the
analysis correctly more so than you are to implement it correctly. Correct
implementation is something that came more from the IC guys that designed
the gates, flops, etc. on the chip to begin with.

Kevin Jennings

 

[Brian Drummond]

If you use a synchronous design method then it really has absolutely nothing
to do with 'the tools'. The real engineering went into the design of the
part itself....

Agreed. The tools basically provide verification - including
verification that you are using the part in a way that doesn't violate
the constraints of that engineering (e.g. using pins that can't connect
to clock routing, for clock signals)

Now when you start trying to implement things that deviate from the
synchronous style (like generating gated clocks and such) you're starting to
take on some design risk in many cases or making the design susceptible to
working/not working when you make 'simple' design changes.

It's worth mentioning that the analysis is only as good as the
constraints you supply - e.g. if you incorrectly specify I/O signal
timings, the tool can only assure you those timings are met (or not!);
not that the design will work.

- Brian

 

[Brian Drummond]

The key take-away for me is that the tool will do it's best to make it
happen and report it when it can't. I can't help but feel let down by
this however. When I solve engineering problems I like to find
solutions that -- by their nature -- solve the problem by eliminating
the source.

It never happens (if you are talking in absolute terms).

Put another way, say you design an amplifier. You can trust that
purchasing will buy 1% resistors for you so that your gain is what you
designed it to be. OR... you can design an amplifier that can handle
10% resistors and STILL provide the gain you wanted.

Whether 1% or 10%, you still have to trust that the resistors are at
least as accurate as that coloured stripe promises. (Unless you are in
the medical or aerospace industries, when you may be obliged to test
100%; this merely transfers the problem of trust to your test equipment,
your calibration service, and ultimately the National Physical
Laboratory)

Of course you can establish a basis for that trust, by sampling a few
resistors from each batch, by ISO 9000 paperwork, and/or by measuring
the gain at test. If you find that trust misplaced, a good supplier will
work to repair the situation.

I don't think trusting the FPGA manufacturer's process and tools is any
different. They stand by their process, and their tools agreement with
it. This is an active process, especially with new devices - the tools
rely on "speed files" which are - maybe not perfect - but guaranteed by
the manufacturer. Often the first release of the speed files is
conservative, and subsequent updates are relaxed as the manufacturer
gains experience; or occasionally tightened if an unforeseen problem is
encountered. The same is true of any printed datasheet...

- Brian

 

[asicbaba]

Since everyone has been so helpful lately I thought I'd press my luck
with a nagging problem I keep running into.

Many times in a syncronous domain I end up with some "enable" pulse
that is exactly one clock wide. Let's say I want to use that enable
to start a counter for some reason. I want the counter to start
counting when enable is true but keep counting until it's done. Let's
say it's a down counter counting down to zero.

I guess my question seems simple: How do I "latch" this enable
pulse? It seems like anything I do is in danger of a race condition.
If everything is syncronous, I can't "act" on anything until the next
clock cycle after the front edge of "enable". But exactly at that
moment, enable is going away! Seems scary.

Mike Treseler once posted the following code to "stretch" a one-clock-
wide pulse to two clocks wide:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity stretch is
port (
clk : in std_logic;
reset : in std_logic;
trig : in std_logic;
pulse : out std_logic
);
end stretch;

architecture synth of stretch is
begin
process (reset, clk) is
variable last_trig : std_logic;
begin
if reset = '0' then
pulse <= '0';
elsif clk'event and clk = '1' then
pulse <= trig or last_trig; -- pulse for 10,11,or 01
last_trig := trig; -- save trig
end if;
end process;
end synth;

Doesn't this suffer the same problem? "last_trig" is changing state
right when "trig" is going away. Same for pulse: pulse wants to
change state right as last_trig is going away.

I'm sure the code works but it's the same problem I have. It just
seems scary.

Any ideas?

Shannon

thsi is what you are looking at

entity stretch is
port (
clk : in std_logic;

reset : in std_logic;
trig : in std_logic;
pulse : out std_logic
);
end stretch;

architecture synth of stretch is

signal count :std_logic_vector(3 downto 0);
signal state :std_logic

begin
process (reset, clk) is
variable last_trig : std_logic;
begin
if reset = '0' then
pulse <= '0';

state <= '0';
count <= "1111";

elsif clk'event and clk = '1' then

case state is
when 0 =>
if trig = '1'then
count <= count - '1';
state <= '1';
else
count <= "1111";
end if
pulse <= '0';
when 1 =>
if count = "0000" then
state <= '0';
pulse <= '1';
else
count <= count - '1';
end if;
end case