Going mad trying to solve PLL setup/hold timing violation issues in Quartus
Philip Pemberton
I'm trying to generate a clock signal that can be switched between
16MHz, 8MHz and 4MHz, and have a 50% duty cycle (for a data separator/
slicer). Just to make this difficult, I only have a 40MHz master clock to
work from... which only has an even integer factor for 4MHz (divide-by-
ten). Divide-by-five gets 8MHz, but doesn't give a 50:50 ratio. 16MHz
isn't even possible (nearest I can get is 20MHz with a divide-by-two).
This is on an Altera Cyclone II 2C20, FBGA484 package, on a Terasic DE1
(actually Altera Cyclone II Starter Board, but the Terasic board is
essentially identical) development board. Software is Quartus 9.0.
Originally, this seemed like a simple problem to solve -- create a PLL
to generate a new set of clocks that were phase-locked to the original
40MHz master clock. Problem is, while I can get the PLL to generate a
16MHz clock, it won't go any lower -- 8MHz and 4MHz produce an alert to
the effect of "division ratio not possible."
So I figured I'd go about this a different way -- generate a 16MHz
clock with the PLL, then divide it down to 8MHz and 4MHz with a pair of
DQ flip-flops wired to toggle (or a binary counter, whatever worked).
This worked fine when I tied the outputs of the clock divider straight to
the clock input on the data separator.
This is what I have now:
// Instantiate a PLL to convert from 40MHz to 32MHz
wire CLK_PLL16MHZ;
DatasepClockGen dscg(CLK40MHZ, CLK_PLL16MHZ);
// Divide down the 16MHz reference to get 8MHz and 4MHz
reg CLK_PLL8MHZ;
always @(posedge CLK_PLL16MHZ) CLK_PLL8MHZ = ~CLK_PLL8MHZ;
reg CLK_PLL4MHZ;
always @(posedge CLK_PLL8MHZ) CLK_PLL4MHZ = ~CLK_PLL4MHZ;
wire DATASEP_MASTER_CLK;
assign DATASEP_MASTER_CLK = CLK_PLL4MHZ;
// Data separator
wire SHAPED_DATA, DWIN;
DataSeparator _datasep(DATASEP_MASTER_CLK, FD_RDDATA_IN,
SHAPED_DATA, DWIN);
// For debugging -- REMOVEME!
assign debug[3:0] = { DATASEP_MASTER_CLK, FD_RDDATA_IN,
SHAPED_DATA, DWIN };
debug[3:0] is a set of output pins, CLK40MHZ is the master clock,
CLK_PLL16MHZ is the output from the PLL. I can post the data separator
logic as well, but it's basically a Verilog implementation of the circuit
shown here:
<http://www.analog-innovations.com/SED/FloppyDataExtractor.pdf>
And this works fine on its own. I'm aware that there are issues with
glitches if I just use a straight multiplexer to switch between clock
sources, so I'm using the parameterised "clock_mux" module from the
Quartus manuals
(<http://www.altera.com/literature/hb/qts/qts_qii51007.pdf>, chapter 6,
page 48-50). I added it to my code like this (replacing the
DATASEP_MASTER_CLK assignments in the code above):
// Mux the clock
wire DATASEP_MASTER_CLK;
// Clock multiplexer
wire [3:0] datasep_clock_selects = {
(ACQCON_MFM_CLKSEL == 2'b00),
(ACQCON_MFM_CLKSEL == 2'b01),
(ACQCON_MFM_CLKSEL == 2'b10),
(ACQCON_MFM_CLKSEL == 2'b11) };
wire [3:0] datasep_clocks = {
(CLK_PLL16MHZ), // 3.5in ED (1Mbps)
(CLK_PLL8MHZ), // 3.5in HD (500kbps)
(CLK_PLL4MHZ), // 3.5in DD (250kbps)
(CLK_PLL4MHZ) }; // Dummy entry for SEL=0b11
clock_mux #(.num_clocks(4)) _datasep_clock_mux(
datasep_clocks,
datasep_clock_selects,
DATASEP_MASTER_CLK
);
This results in a ton of timing violation warnings from the timing
analyser, the most notable being these two:
Warning: Can't achieve minimum setup and hold requirement
DatasepClockGen:dscg|altpll:altpll_component|_clk0 along 9 path(s). See
Report window for details.
Critical Warning: Timing requirements for slow timing model timing
analysis were not met. See Report window for details.
Obviously the setup/hold violation is not a "Good Thing (tm)" and it
needs resolving ASAP (assuming the design works at all as it is). The
question is, how should I go about doing this?
I can replace the clock multiplexer with a straight AND/OR multiplexer,
which seems to resolve the timing issue (or it did last time I tried it),
but this risks causing glitching issues (although the Datasep should
reset within about 64 clock cycles).
Can anyone suggest a possible solution? This is driving me nuts...
probably because the errors from Quartus are about as clear as a pool of
mud, and it seems the Quartus "help" file is only serving to make the mud
thicker...
Thanks,
--
Phil.
usen...@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.
Michael S
1. clk_40Mhz => PLL => clk_32Mhz
2. clk_32Mhz => binary counter => (clk_4Mhz, clk_8Mhz, clk_16Mhz)
3. (clk_4Mhz, clk_8Mhz, clk_16Mhz) => regular mux (do not use
clock_mux!) => clk_temp
4. clk_temp => DFF with clk=clk_32Mhz => clk_out
Nial Stewart
> clock with the PLL, then divide it down to 8MHz and 4MHz with a pair of
> DQ flip-flops wired to toggle (or a binary counter, whatever worked).
Noooooooo.
Generate your 16 MHz clock then use this to drive everything with enable
signals to give 8 and 4 MHz.
You're then just selecting the active enable signal to get the clock you want.
All nice and synchronous, don't generate ripple clocks etc.
Nial.
Philip Pemberton
That works about as well as my original code...
// Instantiate a PLL to convert from 40MHz to 32MHz
wire CLK_PLL32MHZ;
DatasepClockGen dscg(CLK40MHZ, CLK_PLL32MHZ);
// Divide down the 32MHz reference to get 16MHz, 8MHz and 4MHz
reg [2:0] DatasepClkDiv;
always @(posedge CLK_PLL32MHZ) DatasepClkDiv <= DatasepClkDiv + 1;
// Clock multiplexer
reg DATASEP_CLK_pre;
always @(ACQCON_MFM_CLKSEL or DatasepClkDiv) begin
case (ACQCON_MFM_CLKSEL)
2'b00: DATASEP_CLK_pre = DatasepClkDiv
[0];
2'b01: DATASEP_CLK_pre = DatasepClkDiv
[1];
2'b10: DATASEP_CLK_pre = DatasepClkDiv
[2];
default: DATASEP_CLK_pre = DatasepClkDiv
[0];
endcase
end
// Sync clock against 32MHz master clock to remove glitches
reg DATASEP_MASTER_CLK;
always @(posedge CLK_PLL32MHZ) DATASEP_MASTER_CLK <=
DATASEP_CLK_pre;
produces:
Warning: Can't achieve minimum setup and hold requirement
DatasepClockGen:dscg|altpll:altpll_component|_clk0 along 1 path(s). See
Report window for details.
Critical Warning: Timing requirements for slow timing model timing
analysis were not met. See Report window for details.
So the same problem as before, basically...
Philip Pemberton
I found this article a few hours ago:
<http://www.fpga-site.com/kiss.html>
... and just got around to reading it. That got me thinking... maybe it's
the data-separator that's upsetting the timing analyser, not the clock
divider.
So I started looking for gated clocks in the separator -- turns out the
Data Window flip-flop is wired to toggle (i.e. divide its clock by two;
not-Q wired to D), and is clocked from the most significant bit of the
DPLL shift register...
module DataSeparator(MASTER_CLK, FD_RDDATA_IN, SHAPED_DATA, DWIN);
input
MASTER_CLK; // Master Clock -- Data rate * 16
input FD_RDDATA_IN; // L->H
on flux transition
output SHAPED_DATA; //
Reshaped data pulses
output
DWIN; // Data Window
/////////////////////////////////////////////////////////////////////////////
// "Phase-jerked loop" data separator
// Designed by James Thompson, Analog Innovations, Phoenix AZ.
// Verilog implementation by Phil Pemberton
// Declare flipflops
reg u2a, u2b;
// U2A -- first synchroniser.
wire u2a_nPreset = u2b;
always @(posedge FD_RDDATA_IN or negedge u2a_nPreset) begin
if (!u2a_nPreset) begin
u2a <= 1'b1;
end else begin
u2a <= 1'b0;
end
end
// U2B -- second synchroniser
wire u2b_clk = !MASTER_CLK;
always @(posedge u2b_clk) begin
u2b <= u2a;
end
// U4A -- provides SHAPED_DATA
reg SHAPED_DATA;
always @(posedge u2b_clk or negedge u2b) begin
if (!u2b) begin // clear
SHAPED_DATA <= 1'b0;
end else begin
SHAPED_DATA <= u2b; // clock; D=u2b's
output
end
end
// PJL shift register
reg [7:0] pjl_shifter;
always @(posedge MASTER_CLK or negedge u2b) begin
if (!u2b) begin
// Asynchronous CLEAR
pjl_shifter <= 8'b0000_0000;
end else begin
// Clock
pjl_shifter <= {pjl_shifter[6:0], !pjl_shifter
[7]};
end
end
// PJL output register
reg DWIN;
always @(posedge pjl_shifter[7]) begin
DWIN <= ~DWIN;
end
endmodule
A closer look in the timing report showed the path... clk0 output of the
PLL to the MSB of the shifter. Hm.
I've rewritten the last block like this:
// Latch the state of the SR output
reg srout;
always @(posedge MASTER_CLK) begin
srout <= pjl_shifter[7];
end
// PJL output register
reg DWIN;
always @(posedge srout) begin
DWIN <= ~DWIN;
end
So now the output is clocked from the master clock, thus making most of
the data separator synchronous (the only exception I can see is the first
input synchronisation FF, U2A), and eliminating the timing issue.
But now I'm wondering if there's a better way to do this... I've got a
design for a state machine based data separator from a Western Digital
application note[1], but it suffers from a similar issue -- a DQ f/f
wired to toggle, clocked from the MSB output of the state machine PROM.
Making sense of the logic behind either the Analog Innovations "shift
register DPLL" isn't too hard once you start stepping it through, but the
WD one is an utter beast... And they very helpfully didn't bother
documenting it beyond saying "figure 12 shows a data separator built
around a state machine" and providing a ROM dump :-/
[1] "FD179x Application Notes". Western Digital, June 1980; p. 12,
"Figure 12: 179x Data Separator." <http://www.bitsavers.org/pdf/
westernDigital/FD179X_Application_Notes_Jun80.pdf>
KJ
> Sorted it...
>
> So I started looking for gated clocks in the separator -- turns out the
> Data Window flip-flop is wired to toggle (i.e. divide its clock by two;
> not-Q wired to D), and is clocked from the most significant bit of the
> DPLL shift register...
>
You're going about this all wrong, internal generated clocks do not
(repeat that 50 times) in FPGA designs. There is an inherent clock
skew that you can not control and will eventually doom your design.
This skew is not unique to FPGAs, it happens if you design it with
discrete parts, the difference is that inside the FPGA there is
nothing you can do to compensate for it. Ias Nial suggested, the way
to do this is to use one (count them...one) clock and generate clock
enable signals. In your case, take the 40 MHz into a PLL to generate
80 MHz. The entire design runs off of the 80 MHz. One set of things
that will run off of the 80 MHz will be a set of clock enable
generators:
- Count 0 to 4 to generate 16 MHz clock enable
- Count 0 to 9 to generate 8 MHz clock enable
- Count 0 to 19 to generate 4 MHz clock enable
(Bonus points for noticing that a single counter from 0 to 19 can be
used to generate all three clock enables)
Your stated requirement of "..a 50% duty cycle (for a data separator/
slicer)." seem suspicious. All these timing errors that Quartus is
(validly) complaining about are for internal signals. Internal to the
device there will not be a requirement for any particular duty cycle.
If you data separator/slicer does have such a requirement, then it
needs to be redesigned to work in an FPGA environment.
>
> So now the output is clocked from the master clock, thus making most of
> the data separator synchronous (the only exception I can see is the first
> input synchronisation FF, U2A), and eliminating the timing issue.
>
See? Not that hard.
> But now I'm wondering if there's a better way to do this... I've got a
> design for a state machine based data separator from a Western Digital
> application note[1], but it suffers from a similar issue -- a DQ f/f
> wired to toggle, clocked from the MSB output of the state machine PROM.
>
There are all sorts of ASIC design technique that are not usable in
FPGAs. They are different environments with different design
constraints.
Kevin Jennings
Philip Pemberton
> Your stated requirement of "..a 50% duty cycle (for a data separator/
> slicer)." seem suspicious. All these timing errors that Quartus is
> (validly) complaining about are for internal signals. Internal to the
> device there will not be a requirement for any particular duty cycle. If
> you data separator/slicer does have such a requirement, then it needs to
> be redesigned to work in an FPGA environment.
OK, I think I need to do a bit more of an explanation, but you're going
to need the circuit diagram for the original version of the circuit for
it to make much sense. This is on http://www.analog-innovations.com/SED/
FloppyDataExtractor.pdf.
What the circuit does is take an MFM encoded stream from a floppy disc,
then produce a Data Window signal from that. If a READ_DATA pulse is
detected within the data window, a '1' is clocked into a 16-bit shift
register elsewhere in the circuit. If no transition is detected, then a
'0' is clocked in.
The goal is to have a signal that looks like this when a data pulse
occurs:
----+ +-----
DWIN |______|
-------++-------
DATA ||
The three flip-flops on the left synchronise the read-data signal against
the master clock and shape it -- SHAPED_DATA is READ_DATA, but processed
so that it's low for exactly two MASTER_CLK cycles.
Now back to the data separator. This consists of an 8-bit shift register
which is wired to count up and down in a sequence of n=16 (that is, 16
possible states) -- I can't remember the exact sequence off hand, but
running the SR+inverter for about 16 clock cycles with CLEAR wired
inactive should be sufficient to list them.
The sequence is basically a triangle-wave -- the SR outputs count up from
00 to FF, then down to 00 again. The Q7 (MSB) output from the SR is used
to clock a DQ flip-flop (which is wired to toggle) and change the state
of DWIN.
When a RD_DATA pulse is detected, the shift register is cleared back to
0. Depending on where the pulse occurs, the DWIN edge is advanced or
delayed by the value of the counter. This has the effect of compensating
for any shift in the input (RD_DATA) signal that is caused by the speed
of the disc drive motor varying over time.
I doubt the DWIN flip-flop won't be affected if it's wired "as
presented" (CLK=shiftreg[7], CLKE=1), but with the alterations
(CLKE=shiftreg[7], CLK=MASTERCLK) I'm not so sure...
Nial Stewart
> to need the circuit diagram for the original version of the circuit for
> it to make much sense. This is on http://www.analog-innovations.com/SED/
> FloppyDataExtractor.pdf.
Phil,
You need to forget the original circuit apart from working out what it does.
Then go and read up on synchronous FPGA design.
YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
The tools aren't designed to handle/analyse them.
Nial.
Muzaffer Kal
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:
>YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
This maybe true to some extent
>The tools aren't designed to handle/analyse them.
but this is simple not true in general, especially for the analyse
case. Here is what a timing report from Xilinx flow looks like:
=========================================
Timing constraint: TS_clkdiv2 = PERIOD TIMEGRP "clkdiv2" TS_clk / 2
HIGH 50%;
9 paths analyzed, 9 endpoints analyzed, 8 failing endpoints
8 timing errors detected. (8 setup errors, 0 hold errors, 0 component
switching limit errors)
Minimum period is 3.108ns.
--------------------------------------------------------------------------------
Slack (setup path): -0.608ns (requirement - (data path - clock
path skew + uncertainty))
Source: datar1_6 (FF)
Destination: dataout_6 (FF)
Requirement: 2.500ns
Data Path Delay: 0.971ns (Levels of Logic = 0)
Clock Path Skew: -2.102ns (1.205 - 3.307)
Source Clock: clk_BUFGP rising at 0.000ns
Destination Clock: clkdiv2 rising at 2.500ns
Clock Uncertainty: 0.035ns
...
So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so)
of timing the source and target clock delays and reporting a path
between the two clocks correctly. Whether you are interested/capable
of fixing this issue is another problem but I don't think it's
necessary to blame the tools, at least not anymore.
--
Muzaffer Kal
DSPIA INC.
ASIC/FPGA Design Services
Nial Stewart
> of timing the source and target clock delays and reporting a path
> between the two clocks correctly. Whether you are interested/capable
> of fixing this issue is another problem but I don't think it's
> necessary to blame the tools, at least not anymore.
Aye, that was badly worded, although I wouldn't fancy having to get a
design working with a multitude of ripple clocks driving between
clock domains!
Nial
KJ
> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> This maybe true to some extent
>
Yes...to the extent that you want to have a working, robust design in
the end...to that extent. If that's not where you're trying to get
to, then generate all of the clocks that you want.
> >The tools aren't designed to handle/analyse them.
>
> but this is simple not true in general, especially for the analyse
> case. Here is what a timing report from Xilinx flow looks like:
>
Nial wasn't quite correct about the analyze portion of his statement.
The tools certainly can analyze them, what he was getting at is that
you just shouldn't use them. The issue is that there will be a skew
between a flop that receives the master clock and a flop that receives
ANY generated clock (whether that clock is generated combinatorially,
or is the output of a flop like in a ripple counter) and there will be
nothing you can do from a design perspective to compensate for that
skew short of hand placement and routing and cross your fingers, hope
for the best.
> =========================================
> Timing constraint: TS_clkdiv2 = PERIOD TIMEGRP "clkdiv2" TS_clk / 2
> HIGH 50%;
> 9 paths analyzed, 9 endpoints analyzed, 8 failing endpoints
> 8 timing errors detected. (8 setup errors, 0 hold errors, 0 component
> switching limit errors)
> Minimum period is 3.108ns.
> --------------------------------------------------------------------------------
> Slack (setup path): -0.608ns (requirement - (data path - clock
> path skew + uncertainty))
> Source: datar1_6 (FF)
> Destination: dataout_6 (FF)
> Requirement: 2.500ns
> Data Path Delay: 0.971ns (Levels of Logic = 0)
> Clock Path Skew: -2.102ns (1.205 - 3.307)
> Source Clock: clk_BUFGP rising at 0.000ns
> Destination Clock: clkdiv2 rising at 2.500ns
> Clock Uncertainty: 0.035ns
> ...
>
> So TRCE is perfectly capable (I'm sure Quartus Timer is similarly so)
> of timing the source and target clock delays and reporting a path
> between the two clocks correctly. Whether you are interested/capable
> of fixing this issue is another problem but I don't think it's
> necessary to blame the tools, at least not anymore.
It's not apparent to me at least that the fast path was
analyzed...that's where the hold time problems will get fingered. The
tool can probably do it (Quartus does, you have to specify it since
it's not in the 'default' analysis).
Anyway, take your ripple counter and put a heat gun or cold spray on
it and watch it change from working to not working.
Kevin Jennings
Muzaffer Kal
<kkjen...@sbcglobal.net> wrote:
>On Nov 26, 5:09�pm, Muzaffer Kal <k...@dspia.com> wrote:
>> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>>
>> This maybe true to some extent
>>
>
>Yes...to the extent that you want to have a working, robust design in
>the end...to that extent. If that's not where you're trying to get
>to, then generate all of the clocks that you want.
>
No only to the extent of simple designs which don't require much from
the designer, this is certainly good advice. There are times when a
surgical knife is required and in good hands they're an indispensible
and irreplaceble tool.
>The tools certainly can analyze them, what he was getting at is that
>you just shouldn't use them.
I have no problem you or Nial not using them.
>there will be
>nothing you can do from a design perspective to compensate for that
>skew short of hand placement and routing and cross your fingers, hope
>for the best.
>
Again this maybe your experience base but it's certainly not true in
general.
>It's not apparent to me at least that the fast path was
>analyzed...that's where the hold time problems will get fingered. The
>tool can probably do it (Quartus does, you have to specify it since
>it's not in the 'default' analysis).
>
Why do you expect the tool to understand your design? It's your
responsibility to do so and specify the required timing constraints
and checks.
>Anyway, take your ripple counter and put a heat gun or cold spray on
>it and watch it change from working to not working.
I understand if that's your experience with some of your past designs
but please don't attribute it to others.
Muzaffer Kal
I don't think anyone would force you to do something which you're
uncomfortable doing. It's certainly easier to work with single
synchronous clock but it's possible to do with multiple generated ones
too.
KJ
> >On Nov 26, 5:09 pm, Muzaffer Kal <k...@dspia.com> wrote:
> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> >> This maybe true to some extent
>
> >Yes...to the extent that you want to have a working, robust design in
> >the end...to that extent. If that's not where you're trying to get
> >to, then generate all of the clocks that you want.
>
> No only to the extent of simple designs which don't require much from
> the designer, this is certainly good advice.
Hand placement and routing is the only other way to get there. That
was an effective and productive technique in the 80s and 90s when the
place and route tools weren't that good, not today.
You've also got it backwards since only the 'simple designs' or the
'cost is no concern' designs might be able to afford this kind of
additional effort. Neither of those scenarios is typical.
> There are times when a
> surgical knife is required and in good hands they're an indispensible
> and irreplaceble tool.
>
A ripple counter is not a 'surgical knife' nor an 'irreplaceble tool',
it is just a ripple counter. Trying to make it sound like something
only to be understood by the high priests is a load of you-know-what,
stick to actual specifics of the topic. What a ripple counter brings
along is
1. Generally less logic than a synchronous counter
2. Generally less power consumption than a synchronous counter
3. Generally can be clocked faster than a synchronous counter
4. Generally more propagation delay than a synchronous counter
5. Generally more timing uncertainty in when the outputs are valid
than a synchronous counter to the point that there may be no time when
it is even theoretically possible to sample the counter output
accurately.
While one can always contrive a problem where the benefits of #1, #2
and #3 outweigh the drawbacks of #4 and #5, when you're operating in
an FPGA environment, those opportunities are at best very rare,
possibly non-existent. The additional baggage of having to hand tweak
each design revision that adds some new feature makes for a fragile
design.
> >The tools certainly can analyze them, what he was getting at is that
> >you just shouldn't use them.
>
> I have no problem you or Nial not using them.
>
OK...not that either of us, or anyone else for that matter needs your
blessing.
> >there will be
> >nothing you can do from a design perspective to compensate for that
> >skew short of hand placement and routing and cross your fingers, hope
> >for the best.
>
> Again this maybe your experience base but it's certainly not true in
> general.
>
It has nothing to do with anyone's 'experience', it has only to do
with the absolute basics:
1. The output of any flip flop will not change until some delay after
the input clock has changed
2. It is quite possible for the delay from #1 plus the routing delay
to get to some other flop to use as a clock (even on an adjacent logic
block) may exceed the delay of some other logic signal to the 'D'
input of that other flop...that's a hold time violation. In an FPGA
environment, the ONLY mechanism to control this skew is hand placement
and routing.
3. Hand place/route is costly (designer time = money)
4. Free running counters that have no outside control are not of much
use.
5. Any control of counters comes from clock domains other than the
plethora of clock domains created by the ripple counter.
So, if you want to refute any of the above points, feel free to do so
rather than being fuzzy about 'experiences'.
> >It's not apparent to me at least that the fast path was
> >analyzed...that's where the hold time problems will get fingered. The
> >tool can probably do it (Quartus does, you have to specify it since
> >it's not in the 'default' analysis).
>
> Why do you expect the tool to understand your design? It's your
> responsibility to do so and specify the required timing constraints
> and checks.
>
1. Specifying timing constraints does not guarantee you a working
design. After the fact, it tells you when your design has a problem
because it is an *analysis* step.
2. Timing constraints can not change a setup or hold time problem on a
ripple counter into a working design. The only thing that can do that
is hand place and route or getting lucky.
3. As it relates to ripple counters, ANY design specific constraints
exist only to allow the timing analyzer to ignore what it would
ordinarily flag as an error.
4. No tool exists to validate that any timing constraints are actually
correct.
Again, feel free to refute any of the above.
> >Anyway, take your ripple counter and put a heat gun or cold spray on
> >it and watch it change from working to not working.
>
> I understand if that's your experience with some of your past designs
> but please don't attribute it to others.
Those are my experiences when working with other people's async
designs, I didn't attribute anything to anyone.
I simply suggested that if someone thinks that they have a working
FPGA design that uses asynchronous design techniques such as a ripple
counter, than they should try running that design over the full
temperature range of the part and verify whether or not the design is
still 'working'.
Kevin Jennings
Muzaffer Kal
<kkjen...@sbcglobal.net> wrote:
>On Nov 27, 4:37�pm, Muzaffer Kal <k...@dspia.com> wrote:
>> >On Nov 26, 5:09�pm, Muzaffer Kal <k...@dspia.com> wrote:
>> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>>
>> >> This maybe true to some extent
>>
>> >Yes...to the extent that you want to have a working, robust design in
>> >the end...to that extent. �If that's not where you're trying to get
>> >to, then generate all of the clocks that you want.
>>
>> No only to the extent of simple designs which don't require much from
>> the designer, this is certainly good advice.
>
>Hand placement and routing is the only other way to get there.
I think you should add the caveat "that you know of" at the end of
that statement. Your response might be "tell me what else" but I
already spent more time than it's worth here.
>> >there will be
>> >nothing you can do from a design perspective to compensate for that
>> >skew short of hand placement and routing and cross your fingers, hope
>> >for the best.
>>
>> Again this maybe your experience base but it's certainly not true in
>> general.
>>
>
>It has nothing to do with anyone's 'experience', it has only to do
>with the absolute basics:
>1. The output of any flip flop will not change until some delay after
>the input clock has changed
>2. It is quite possible for the delay from #1 plus the routing delay
>to get to some other flop to use as a clock (even on an adjacent logic
>block) may exceed the delay of some other logic signal to the 'D'
>input of that other flop...that's a hold time violation. In an FPGA
>environment, the ONLY mechanism to control this skew is hand placement
>and routing.
You seem to be under the impression that in today's FPGAs the clock
trees are absolutely perfect zero-skew and the FPGA PAR tools don't
have to do any hold fixes. I don't think that ever was the case but
today with 45nm processes and 10s if not hundreds of mmsq die sizes
that's definitely not true anymore. Open a timing report of any decent
size design and look at a certain path to see what the delays of the
clocks are. Also pay attention to what PAR is telling you in later
stages of the routing.
FPGA tools try to hide most of the complexity of digital design and
give the illusion of a simple environment but this is not true in
reality and certainly limits the amount of design capabilities one
has.
>4. No tool exists to validate that any timing constraints are actually
>correct.
>Again, feel free to refute any of the above.
I am not sure how we got from divided clocks to ripple counters so
I'll discount the other comments but this one is certainly wrong. You
don't seem to think so but making such strong and wrong statements is
an indication of one's experience. There are no real zero-skew clock
trees, FPGA flops are not zero-hold and FPGA routers do hold fixing
and yes there are tools which can analyze your design and verify your
constraints. The fact that you don't know about them doesn't make them
disappear.
HT-Lab
"KJ" <kkjen...@sbcglobal.net> wrote in message
news:7eb143ac-bc28-489b...@d21g2000yqn.googlegroups.com...
On Nov 27, 4:37 pm, Muzaffer Kal <k...@dspia.com> wrote:
> >On Nov 26, 5:09 pm, Muzaffer Kal <k...@dspia.com> wrote:
> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> the designer, this is certainly good advice.
>
>it is just a ripple counter. Trying to make it sound like something
>only to be understood by the high priests is a load of you-know-what,
>stick to actual specifics of the topic. What a ripple counter brings
>along is
>1. Generally less logic than a synchronous counter
>2. Generally less power consumption than a synchronous counter
>3. Generally can be clocked faster than a synchronous counter
Right and this is the reason why they are used in ASIC designs and why Muzaffer
is experienced with them. However, it might not be the best design style for an
FPGA and hence high-end synthesis tools like Precision automatically translates
rippled counters to their synchronous equivalent (part of their ASIC ->FPGA
prototyping conversion).
Hans.
www.ht-lab.com
KJ
> >> >> >YOU DO NOT WANT TO GENERATE AND USE RIPPLE CLOCKS IN AN FPGA.
>
> >> >> This maybe true to some extent
>
> >> >Yes...to the extent that you want to have a working, robust design in
> >> >the end...to that extent. If that's not where you're trying to get
> >> >to, then generate all of the clocks that you want.
>
> >> No only to the extent of simple designs which don't require much from
> >> the designer, this is certainly good advice.
>
> >Hand placement and routing is the only other way to get there.
>
> I think you should add the caveat "that you know of" at the end of
> that statement. Your response might be "tell me what else" but I
> already spent more time than it's worth here.
>
No need for any caveats. I covered the reasons in the list of points
starting with "The output of any flip flop will not change..." and
asked you to refute anything that is not accurate, you came up empty.
Apparently you'd like people here to believe that you know of
something that will guarantee proper operation of a ripple counter in
an FPGA that does not involve any form of hand place/route. Since you
haven't refuted any of my points and you haven't backed up your own
claim, I'll simply leave it at that as speaking quite clearly about
your claim.
> >It has nothing to do with anyone's 'experience', it has only to do
> >with the absolute basics:
> >1. The output of any flip flop will not change until some delay after
> >the input clock has changed
> >2. It is quite possible for the delay from #1 plus the routing delay
> >to get to some other flop to use as a clock (even on an adjacent logic
> >block) may exceed the delay of some other logic signal to the 'D'
> >input of that other flop...that's a hold time violation. In an FPGA
> >environment, the ONLY mechanism to control this skew is hand placement
> >and routing.
>
> You seem to be under the impression that in today's FPGAs the clock
> trees are absolutely perfect zero-skew and the FPGA PAR tools don't
> have to do any hold fixes.
No, I'm not under any of those impressions. This is basic stuff, the
signal that is being sampled will always have a setup and hold
requirement around the time of the sampling edge.
Rather than responding to what I actually post and instead responding
to your impressions about what *you* think I may or may not know, is a
sign of arrogance on your part.
> Open a timing report of any decent
> size design and look at a certain path to see what the delays of the
> clocks are. Also pay attention to what PAR is telling you in later
> stages of the routing.
As it relates to the ripple counter also pay attention to what static
timing analysis is telling you for the 'minimum' delay paths and hold
times.
>
> >4. No tool exists to validate that any timing constraints are actually
> >correct.
> >Again, feel free to refute any of the above.
>
> I am not sure how we got from divided clocks to ripple counters so
> I'll discount the other comments but this one is certainly wrong.
Maybe you should read the postings to see how we got on to ripple
counters. The originating comment has been there all along.
Discount my comments if you'd like. I asked you to refute them if you
can, your reply speaks volumes and again implies arrogance.
Place and route may take timing constraints into account to help it do
its job, but it does guarantee that it will meet them. If it did,
there would never be a failing timing path when it comes time to
performing static timing analysis.
> You
> don't seem to think so but making such strong and wrong statements is
> an indication of one's experience.
I'm accepting of when I've posted something incorrectly. In this
particular thread I've also explicitly invited you to correct
something that is incorrect. You've yet to refute any of my points
but seem to think that simply saying that I'm wrong is sufficient.
Good luck using that tact.
> and yes there are tools which can analyze your design and verify your
> constraints.
You've possibly misread or misinterpreted my statement which was "No
tool exists to validate that any timing constraints are actually
correct". I didn't say there were no tools that would take a design
and verify it meets the constraints, I said a tool that would verify
that the constraints themselves are correct.
> The fact that you don't know about them doesn't make them
> disappear.
The fact that you don't list them just makes your postings of low
information content.
> --
> Muzaffer Kal
>
> DSPIA INC.
> ASIC/FPGA Design Services
>
Hopefully you don't represent your company with these postings.
End of Jennings' input to the Kal/Jennings thread
Kevin Jennings
Muzaffer Kal
<kkjen...@sbcglobal.net> wrote:
>> and yes there are tools which can analyze your design and verify �your
>> constraints.
>
>You've possibly misread or misinterpreted my statement which was "No
>tool exists to validate that any timing constraints are actually
>correct". I didn't say there were no tools that would take a design
>and verify it meets the constraints, I said a tool that would verify
>that the constraints themselves are correct.
What was said was quite clear and there are such tools. Here is one
example: http://www.bluepearlsoftware.com/products/azure.html
>> The fact that you don't know about them doesn't make them
>> disappear.
>
>The fact that you don't list them just makes your postings of low
>information content.
The web is full of information. You should spend some time to acquire
some on your own.
--
Muzaffer Kal
DSPIA INC.
ASIC/FPGA Design Services
Nial Stewart
> uncomfortable doing.
Apart from the wife (and not in 'interesting' ways).
> It's certainly easier to work with single
> synchronous clock but it's possible to do with multiple generated ones
> too.
My only real experience of ripple & gated clocks was 8 years or
so ago when a client brought me in to 'tweak' an FPGA that was
'almost working'.
It had been created by a board designer who had approached the FPGA
design as if he was designing a PCB. There were bits in VHDL, AHDL and
schematics with ripple and gated clocks all over the place, far too
many to analyse and constrain to get working. They were getting
different performance and behaviour every build.
The tools reported an fmax of ~20MHz, they were clocking it at 50MHz!
I re-wrote it in about six weeks after which it just worked, every
build.
I know asynchronous design techniques can be used in FPGAs, but I'll
avoid it where possible, this is the message I was trying to give
the OP (who I think is a beginner).
Nial
Uolricus
"Philip Pemberton" <usen...@philpem.me.uk> wrote in message
news:00428082$0$2310$c3e...@news.astraweb.com...
Are you sure that the circuit described in
<http://www.analog-innovations.com/SED/FloppyDataExtractor.pdf>
works as you hope?
I've run it through a couple of simulators including one that simulates
the old "family logic" and find that it breaks down and doesn't maintain
lock, or even approach a steady timing relationship with the input signal.
Of course, it does work if the input timing and driver clock are both in
sync, but if the MFM input is 10% out of phase, the thing seems never to
acquire. Further, if it's 5% fast or slow, relative the center frequency,
then it loses or never achieves lock.
Uli