??? 04/14/07 16:42 Read: times |
#137263 - consider this ... Responding to: ???'s previous message |
The reason I've had trouble with the DLL-based method is that the DLL's in XILINX FPGA's are designed for one thing and I'm trying to see whether, instead, they can be used for something otherwise useful instead. They don't really want to do that.
I have several very old tried-and-true DPLL's that can easily be implemented in CPLD/FPGA logic, but which the ModelSim doesn't simulate correctly because it doesn't know what to do with "undefined" (particularly metastabile) events. Physical implementation has these failing, in the sense that they go metastabile, about every 30 hours of run time. In the simulator, they break down within 10-20 iterations. That's one of the problems with interacting asynchronous processes. With the DLL's, it's really difficult to make it work. With a DPLL, it's not so tricky. With the DLL, the crux is to minimize the input jitter by first recovering missing pulses. With the DPLL, the crux is simply to minimize the output jitter. That's defined in the one-clock correction. There are, in fact, ways to make it shift only half a driver clock at a time. For me, the challenge is to make the XILINX DLL work as part of a PLL. For Mahmood Elnasser, the challenge is to comprehend and construct an all-digital phase-locked loop. There are lots of ways in which to do this, but, in HDL, the trick is to drive two asynchronous events, that interact, from within two different processes. I find it much easier to describe as a schematic, but I suppose that's because I've been using this DPLL logic for 20+ years. Note, also, that I didn't put a size limit on the logic. It can be done with very simple logic. Slightly more logic makes it "quieter" though. RE |