Timing error for EDK project using a DCM?

Hello, hello,

I'm trying to use a DCM on my Microblaze (EDK 11.2) project so that I
can multiply the 200MHz output clock of the project-generated
clock_generator IP (the CLKOUT2 output) by a factor of two (for 400MHz
total that I want to drive a custom peripheral with). The
clock_generator also generates the 100MHz clock that drives the
Microblaze. I require the generated 400MHz clock to be in phase with
the 100MHz clock.

The following ports are set up:

- 200MHz signal from the clock_generator IP is fed to the CLKIN port
of the DCM IP
- DCM's CLK0 (buffered) to the CLKFB port
- feed the CLK2X (buffered) signal into the IP that I want to drive at
400MHz

When I try to generate the bitstream I get the following error:

Analyzing implementation/system.par
********************************************************************************
ERROR: 3 constraints not met.

PAR could not meet all timing constraints. A bitstream will not be
generated.

To disable the PAR timing check:

1> Disable the "Treat timing closure failure as error" option from the
Project Options dialog in XPS.

OR

2> Type following at the XPS prompt:
XPS% xset enable_par_timing_error 0
********************************************************************************
********************************************************************************
ERROR: 3 constraints not met.

PAR could not meet all timing constraints. A bitstream will not be
generated.

To disable the PAR timing check:

1> Disable the "Treat timing closure failure as error" option from the
Project Options dialog in XPS.

OR

2> Type following at the XPS prompt:
XPS% xset enable_par_timing_error 0
********************************************************************************
make: *** [implementation/system.bit] Error 2


It is my understanding that bypassing timing errors is a good way to
get the project to fail in a strange way, has anyone dealt with this
problem before? Is there a better way to multiply the clock that
doesn't involve using a DCM?

Thanks in advance,

Sean.

Sean

What fpga are you using? Have you checked the datasheet to confirm that it
can run at the frequency you want? If ISE is giving timing errors then you
should be able to see what it is complaining about.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Sun, 31 Oct 2010 19:15:11 -0700 (PDT), Griffin <captain.griffin@gmail.com>
wrote:

>Hello, hello,
>
>I'm trying to use a DCM on my Microblaze (EDK 11.2) project so that I
>can multiply the 200MHz output clock of the project-generated
>clock_generator IP (the CLKOUT2 output) by a factor of two (for 400MHz
>total that I want to drive a custom peripheral with). The
>clock_generator also generates the 100MHz clock that drives the
>Microblaze. I require the generated 400MHz clock to be in phase with
>the 100MHz clock.

DCM IS the right way to do this.

If the 

>PAR could not meet all timing constraints. A bitstream will not be
>generated.

>1> Disable the "Treat timing closure failure as error" option from the
>Project Options dialog in XPS.

This looks like the tools have put you in a double-bind: 
you need to analyze timing on the bitfile to see where the errors are:
but the tool won't create a bitfile.

Turn off the error as per the instructions, and generate a bitfile, simply to
see the timing analysis report. 

You may need to pipeline your peripheral more deeply, to meet 400MHz timings,
especially at the interface between it and the Microblaze local bus.

- Brian

On Nov 1, 4:10=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sun, 31 Oct 2010 19:15:11 -0700 (PDT), Griffin <captain.grif...@gmail.=
com>
> wrote:
>
> >Hello, hello,
>
> >I'm trying to use a DCM on my Microblaze (EDK 11.2) project so that I
> >can multiply the 200MHz output clock of the project-generated
> >clock_generator IP (the CLKOUT2 output) by a factor of two (for 400MHz
> >total that I want to drive a custom peripheral with). The
> >clock_generator also generates the 100MHz clock that drives the
> >Microblaze. I require the generated 400MHz clock to be in phase with
> >the 100MHz clock.
>
> DCM IS the right way to do this.
>
> If the
>
> >PAR could not meet all timing constraints. A bitstream will not be
> >generated.
> >1> Disable the "Treat timing closure failure as error" option from the
> >Project Options dialog in XPS.
>
> This looks like the tools have put you in a double-bind:
> you need to analyze timing on the bitfile to see where the errors are:
> but the tool won't create a bitfile.
>
> Turn off the error as per the instructions, and generate a bitfile, simpl=
y to
> see the timing analysis report.
>
> You may need to pipeline your peripheral more deeply, to meet 400MHz timi=
ngs,
> especially at the interface between it and the Microblaze local bus.
>
> - Brian

> you need to analyze timing on the bitfile

This isn't correct, the timing analysis will be done on the design
netlist at the various stages of implementation.  The only thing that
the bitfile is used for is programming the device.

The OP indicated that PAR reported 3 timing constraint errors.
Looking at the PAR report file or running the Timing Analyzer (aka
trce) on the placed and routed NCD file from PAR will indicate which
paths failed timing.

BTW, 400 MHz is pretty fast so there is a good chance that the design
doesn't meet timing unless careful consideration has been made to the
design construction.

Ed McGettigan
--
Xilinx Inc.

@Jon and Ed: I am using the Virtex-4 SX (ML402 devellopment board). I
compiled the peripheral using ISE and the compiler told me that the
fastest I can clock it at is ~430MHz. 400MHz is well below that, so I
don't think it's an issue with the design of the peripheral itself.

For a better idea as to what I'm doing, I have a peripheral connected
via FSL to the microblaze. My code inside the peripheral essentially
counts the number of pulses it receives from the outside world and
then maps that value to the registers of the peripheral so I can read
them out to the microblaze.

I tried to do this asynchronously, but encountered readout errors
where (what we think happened) the counters were being read out while
the bits were rolling over mid-count, creating an output that was
nonsense. So, I switched to a counter that is synchronous with the
readout clock (ie, every clock cycle I check to see if the input is
high, then I see if the input is high, if so, and I haven't already
counted that high pulse, I increment the counter). I want to multiply
the clock speed so I can probe the input faster to make sure that I'm
not missing any counts, but still work in phase with the readout clock
(ie, the FSL bus clock, 100MHz).

This is a little oversimplified, but that's the jist of it.

On Nov 1, 3:46=A0pm, Griffin <captain.grif...@gmail.com> wrote:
> @Jon and Ed: I am using the Virtex-4 SX (ML402 devellopment board). I
> compiled the peripheral using ISE and the compiler told me that the
> fastest I can clock it at is ~430MHz. 400MHz is well below that, so I
> don't think it's an issue with the design of the peripheral itself.
>
> For a better idea as to what I'm doing, I have a peripheral connected
> via FSL to the microblaze. My code inside the peripheral essentially
> counts the number of pulses it receives from the outside world and
> then maps that value to the registers of the peripheral so I can read
> them out to the microblaze.
>
> I tried to do this asynchronously, but encountered readout errors
> where (what we think happened) the counters were being read out while
> the bits were rolling over mid-count, creating an output that was
> nonsense. So, I switched to a counter that is synchronous with the
> readout clock (ie, every clock cycle I check to see if the input is
> high, then I see if the input is high, if so, and I haven't already
> counted that high pulse, I increment the counter). I want to multiply
> the clock speed so I can probe the input faster to make sure that I'm
> not missing any counts, but still work in phase with the readout clock
> (ie, the FSL bus clock, 100MHz).
>
> This is a little oversimplified, but that's the jist of it.

What the synthesis tools report for timing is just an estimate. If can
be off by quite bit, either high or low.

If you are trying to read the counter from a clock domain that is
different than the one it is in, then you need to synchronize it. A
simple way to do this is to use a Gray code counter, and convert it
back to binary either in the clock domain you are reading it into, or
just do it in software.

There is an example of how to code a Gray code counter in Project
Navigator in the language templates library. The language templates
library is under the edit menu, or just click the light bulb icon.

Regards,

John McCaskill
www.FasterTechnology.com

On Mon, 1 Nov 2010 08:21:01 -0700 (PDT), Ed McGettigan
<ed.mcgettigan@xilinx.com> wrote:

>On Nov 1, 4:10&#4294967295;am, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> On Sun, 31 Oct 2010 19:15:11 -0700 (PDT), Griffin <captain.grif...@gmail.com>
>> wrote:

>> This looks like the tools have put you in a double-bind:
>> you need to analyze timing on the bitfile to see where the errors are:
>> but the tool won't create a bitfile.

>This isn't correct, the timing analysis will be done on the design
>netlist at the various stages of implementation.  The only thing that
>the bitfile is used for is programming the device.

oops, not enough coffee this morning, obviously!
 I was under the impression that PAR was not writing its output.
Of course it is; however  the subsequent "bitgen" process is not running.

Static timing requires the PAR output, which the original poster will have.
The rest of my message still stands; he will have to get the actual problem from
timing analysis and fix it.

- Brian

On Mon, 1 Nov 2010 13:46:26 -0700 (PDT), Griffin <captain.griffin@gmail.com>
wrote:

>@Jon and Ed: I am using the Virtex-4 SX (ML402 devellopment board). I
>compiled the peripheral using ISE and the compiler told me that the
>fastest I can clock it at is ~430MHz. 400MHz is well below that, so I
>don't think it's an issue with the design of the peripheral itself.

If "the compiler" is the synthesis tool, then be aware that its reported timing
is merely an estimate. It is often within 10% of the final speed, so you cannot
rule out a design issue yet.

One "fiddle" worth trying when you are close to meeting timing, is to re-run MAP
and PAR with another placement seed. You will get different results from a
different seed, sometimes by 5% or so, and that might be enough to meet timing.

Otherwise, be guided by the errors listed in the timing report (file.twx or
.twr).

- Brian

On Nov 1, 1:46=A0pm, Griffin <captain.grif...@gmail.com> wrote:
> @Jon and Ed: I am using the Virtex-4 SX (ML402 devellopment board). I
> compiled the peripheral using ISE and the compiler told me that the
> fastest I can clock it at is ~430MHz. 400MHz is well below that, so I
> don't think it's an issue with the design of the peripheral itself.
>
> For a better idea as to what I'm doing, I have a peripheral connected
> via FSL to the microblaze. My code inside the peripheral essentially
> counts the number of pulses it receives from the outside world and
> then maps that value to the registers of the peripheral so I can read
> them out to the microblaze.
>
> I tried to do this asynchronously, but encountered readout errors
> where (what we think happened) the counters were being read out while
> the bits were rolling over mid-count, creating an output that was
> nonsense. So, I switched to a counter that is synchronous with the
> readout clock (ie, every clock cycle I check to see if the input is
> high, then I see if the input is high, if so, and I haven't already
> counted that high pulse, I increment the counter). I want to multiply
> the clock speed so I can probe the input faster to make sure that I'm
> not missing any counts, but still work in phase with the readout clock
> (ie, the FSL bus clock, 100MHz).
>
> This is a little oversimplified, but that's the jist of it.

430 MHz =3D 2326 pS
400 MHz =3D 2500 pS

The difference here is 174pS between the two rates.  This is well
below the margin of error of a synthesized timing estimate as John and
Brian have pointed out.

Have you been able to determine the failing paths yet?

Ed McGettigan
--
Xilinx Inc.

Sean

Looing at the V4 datasheet the max freq of the CLK2X is 400MHz, so you
might have a problem with timing. Maybe if you had a better speed grade
device things might be a bit easier. But all you can do is look at the
failing paths and see if you can get them to time.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com