07-26-2021 02:15 PM
I am inputting an 8 MHz clock. What is the rise time and fall time required between transitions of the clock signal?
Is there a part of the datasheet that points to this information?
07-26-2021 06:51 PM
07-29-2021 10:54 AM
Thanks for linking that. Yes I have seen this, however what do they mean by rise/time? 10% to 90%? VIL to VIH?
Can you clarify the TWLH GCK pulse width (High or Low)? Should I use this to gauge my rise time or should I use the 10ns stated in the post? Preferably I would want to use a metric that is in the data sheet.
07-29-2021 11:05 AM
You are over thinking this
Assume a "TTL" type of driver for the clock,
then you are going to have a few ns rise / fall time
That is perfectly acceptable for the old XC95288
Can I ask the background please
Are you trying to write a test specification,
or design a new system, which seems strange as its such an old part.
My other thought is are you trying to debug a design you have
in which case, my first question would be where did you get the parts.
These are such old part,
that they were originally supported by paper documents in books,
well before the web had everything,
so information might well have been lost over the decades.
07-29-2021 01:52 PM
Thanks for your reply. I am trying to debug a design that is using this CPLD. It is a new design that uses this old part. We purchased from Digikey, so I would assume these would not be illegitimate parts.
The CPLD was programmed to divide and propagate a 2.048 MHz clock signal. Unfortunately, I found that the propagated clocks sometimes had pulses with a smaller period (attached). I found that the input clock had a slew rate (10% - 90%) of ~24 ns. I'm trying to figure out whether that was too slow and if it was causing the shorter clock.
To note, only some of the CPLDs are showing this behaviour.
07-30-2021 01:58 AM
possible cause, could well be that clock,
how do you get such a slow rise time !
Check the clock in for glitches as well,
without knowing your code, its not possible to give much more info
I have seen similar when people use asynchronous counters, or the clock to gate a signal,
the other clasic is a latch , in a CPLD is a bunch of nand gates.
Digikey are good,
but note its still a part that is in its twilight years,
For my own personal interest, what is the data code on the parts you have ?
07-30-2021 07:09 AM
Whats strange is that only some of the CPLDs (4/20) showed this behaviour with the same clock.
The code gates the clock to create the propagated clocks.
I decreased the rise time to ~13ns and I did not have the issue again. We had a series termination resistor that was slowing the slew rate.
This goes back to my original question if there is some kind of metric of the XC95288XL data sheet to base the rise/fall time off of?
Date Code on the CPLD is AWN2033D6218312A
Thanks again for the help!
07-30-2021 08:51 AM
You have th edat asheets,
if its not in there what you want, its not around any more, if it ever was.
and it wont be added now.
Gating a clock is NEVER going to be good,
and the clock having such a slow rise / fall time,
its going to be spending a long time between Vi Low and Vin High,
who knows how one gate in the chip responds to this middle ground compared to another,
your design has to account for this, which with a gated clock is "impossible"
07-30-2021 09:52 AM
Can you share the code ( assuming its RTL )
what do you mean by propagate the clock , is this your divided clock ?
08-05-2021 01:35 PM
I made a mistake. It actually is latched. Unfortunately I cannot share the code but the code uses the same concept as shown here: https://startingelectronics.org/software/VHDL-CPLD-course/tut6-clock-divider/
Propagated clock pins are mapped to bit 1 of CLK_DIV so the propagated clocks are 1/4 of the source clock.
08-06-2021 01:11 AM
without seeing a snippet of the code,
cant say much
BTW: The design you shared is registered, not latched.
In "C" type code, it does not matter
but in hardware design , they are very different things,