Re: delays in XC95144XL CPLD

On Apr 2, 6:01 am, David Fejes <fej...@xxxxxxxxx> wrote:
running parallel 165mhz datapaths via XC95 doesnt sound like a good
idea
but maybe i am wrong, has happened b4

There is a similar application note at the Xilinx webpage in the
xapp944.pdf  It is true that the maximum frequency of the signals is
only 27Mhz in this design and it uses CoolRunnerII instead of XC95,
but there is a interesting sentence at the end of the document:

,,All similar signals travel through the same path in the CPLD, so
they will emerge from the other side with negligible skew, because of
to the deterministic nature of the timing model and architecture."

I think it should be true at higher frequencies too, didn't?

On Apr 2, 10:18 am, "Antti.Luk...@xxxxxxxxxxxxxx"

<Antti.Luk...@xxxxxxxxxxxxxx> wrote:
On Apr 2, 11:12 am, David Fejes <fej...@xxxxxxxxx> wrote:

Hello,

I want to use the XC95144XL CPLD to switching paralell video buses up
to 165Mhz frequency. The logic has only combinatorial parts and there
are no feedbacks from the macrocells output to the FastConnectII
inputs.
It's very important that the signals must have the same delays but I'm
a bit confused with the delays and the timing modells.

I don't use registers or any feedback in my configuration, so I'm
pretty sure that Fsystem is irrelevant to me. The combinatorial delays
are given as Tpdi for different speed grades, but I'm not sure wether
this delay is uniform or not. My Pterms have the same configurations
in all FBs due to the symmetrical topology.

Will it work with a 10 (lowest) speed grade CPLD or not? Shall I use a
faster (and a much more expensive) version or not? What will be the
order of jitters between the paralell signals?

Thank you for the answers
David

PS: timings are available athttp://www.xilinx.com/support/documentation/data_sheets/ds056.pdf
p5-p6

have you looked the CPLD output signals at 165MHz with a good DSO?
I have. For a project where it was important to generate 120mhz phase
shifted
clocks with an CPLD. as much as i recall i did not like the cpld
output
waveforms what i observed.

running parallel 165mhz datapaths via XC95 doesnt sound like a good
idea
but maybe i am wrong, has happened b4

Antti



You may find that the skew is not your problem, but the switching
capability of the output drivers in the XC9500 series. Fmax is
not just because of clocks, slow output drivers may have reduced
output swing and unacceptable rise and fall times at 165 MHz.
.

Relevant Pages

  • Re: delays in XC95144XL CPLD
    ... xapp944.pdf It is true that the maximum frequency of the signals is ... It's very important that the signals must have the same delays but I'm ... The combinatorial delays ... have you looked the CPLD output signals at 165MHz with a good DSO? ...
    (comp.arch.fpga)
  • Re: Curve fitting/interpolation
    ... Often (e.g., especially in process control apps), there are big ... Apologies, in advance, for delays in my replies as I am ... signals to build a 'model' which was used to 'auto-correlate' any ... The system even had an arming feature and a 'window' ...
    (comp.arch.embedded)
  • Re: will C# be perfomant enough for the next problem (HW programming)???
    ... "The interface is basically a signal router that can redirect the signals ... between the memory chips and 303's internal cpu and the signals between the ... will I be able to do it without delays ??? ... Memory: 64 measures x 7 TRACKS. ...
    (microsoft.public.dotnet.languages.csharp)
  • Best way to write to LUT based CPLD from slow CPU?
    ... I am inexperienced in CPLD design. ... I am using a slow CPU (PC ISA ... I am facing two choices of implementing the register writing signals. ... The WRITE\ signal as a secondary global clock. ...
    (comp.arch.fpga)
  • delays in XC95144XL CPLD
    ... I want to use the XC95144XL CPLD to switching paralell video buses up ... are no feedbacks from the macrocells output to the FastConnectII ... It's very important that the signals must have the same delays but I'm ... Will it work with a 10 speed grade CPLD or not? ...
    (comp.arch.fpga)