Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Pulse stretching

Reply
Thread Tools

Pulse stretching

 
 
Shannon
Guest
Posts: n/a
 
      02-07-2007
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

 
Reply With Quote
 
 
 
 
Shannon
Guest
Posts: n/a
 
      02-07-2007
On Feb 7, 9:46 am, "Shannon" <(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
 
 
 
Dave Pollum
Guest
Posts: n/a
 
      02-07-2007
On Feb 7, 12:46 pm, "Shannon" <(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      02-07-2007
On Feb 7, 10:01 am, "Dave Pollum" <(E-Mail Removed)> wrote:
> On Feb 7, 12:46 pm, "Shannon" <(E-Mail Removed)> wrote:
>
>
>
>
>
> > 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- 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

 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      02-08-2007
Shannon wrote:

> 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
 
Reply With Quote
 
Ben Jones
Guest
Posts: n/a
 
      02-08-2007
Hi,

"Shannon" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> On Feb 7, 9:46 am, "Shannon" <(E-Mail Removed)> wrote:
>> 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.


>> .... <some code> ....


>> 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.

>
> 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-


 
Reply With Quote
 
Brian Drummond
Guest
Posts: n/a
 
      02-08-2007
On 7 Feb 2007 11:56:17 -0800, "Shannon" <(E-Mail Removed)> wrote:

>On Feb 7, 10:01 am, "Dave Pollum" <(E-Mail Removed)> wrote:
>> On Feb 7, 12:46 pm, "Shannon" <(E-Mail Removed)> wrote:
>>


>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


 
Reply With Quote
 
Shannon
Guest
Posts: n/a
 
      02-08-2007
On Feb 8, 3:51 am, Brian Drummond <(E-Mail Removed)>
wrote:
> On 7 Feb 2007 11:56:17 -0800, "Shannon" <(E-Mail Removed)> wrote:
>
> >On Feb 7, 10:01 am, "Dave Pollum" <(E-Mail Removed)> wrote:
> >> On Feb 7, 12:46 pm, "Shannon" <(E-Mail Removed)> wrote:

>
> >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


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

 
Reply With Quote
 
Ben Jones
Guest
Posts: n/a
 
      02-08-2007

"Shannon" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...

> 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-


 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      02-08-2007
Shannon wrote:

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Table stretching excessively in IE Arthur Dent ASP .Net 4 03-07-2006 03:27 PM
stretching the background image instead of tiling =?Utf-8?B?U3JpZGhhcg==?= ASP .Net 3 11-30-2005 11:32 AM
auto-stretching in IE Evert | Collab HTML 20 07-21-2005 01:15 PM
I2C slave clock stretching praveen.kantharajapura@gmail.com VHDL 1 06-14-2005 09:02 AM
Image Stretching Lee Harris HTML 1 10-27-2003 02:18 PM



Advertisments