hi，everyone， does someone know whether there is a specs for the PLL in caravel?

I can answer questions about the PLL, since I designed it. It is not actually a PLL; it is an all-digital freqeuncy-locked loop. It uses a ring oscillator with individual stages that can be added or removed. So the resolution is coarse compared to a PLL, and as a consequence it has very high cycle-to-cycle jitter. Its maximum frequency is somewhere between 150 and 200 MHz and can be divided down by a factor of 1 to 8. It can be frequency locked to the input clock, or it can be free-running as a DCO and manually tuned.

thanks a lot, it would be nice if there is a documentation to describe the PLL, say, how to get a wanted output clock, the restrictions of current PLL,etc, I can find some existing materials, if can be put together is more convenient.🙂

there is a cool python script here: https://github.com/kbeckmann/caravel-pll-calculator

👍

I'm waiting for MPW-two silicon to arrive on my desk so that I can characterize it properly with measurements. I should have something to test next week.

@Tim Edwards I have a question about 26 bits DCO trim. Documentation says: "each bit provides an additional (approximately) 250ps delay (on top of a fixed delay of 4.67ns)". So the value 0 has 0 bits set and delay is 4,670ps (214MHz). On the other hand the value 0x03ff_ffff has 26 bits set and delay is 4,670+26*250=11170ps (90MHz). My question is about the default value, which is 0x3ff_efff. It has 25 bits set so delay is 4,670+25*250=10920ps (92MHz). If correct, what would be the difference between DCO trim values 0x3ff_efff and 0x1ff_ffff both having 25 bits set? Please let me know if I misunderstood.

@roman3017: For whatever reason I only just saw this post, because I was testing the DLL on the most recent silicon and was searching the channels to see what I had already said about it in the past. The answer to your question is: (1) For each set of 3 stages, two are programmable, and of those two, one shadows the other. In other words, if the first stage is turned on then it bypasses the second stage, so then it doesn't make any difference at all whether or not the second stage is turned on or not. So there are two groups of bits, and the bits in one group must be turned on before the corresponding bits in the other group. Otherwise, (2) in theory, there is no difference in frequency between any sets of trim bits with the same number of ones and zeros. In practice, grouping the same path through the same multiplexers all on one side of the ring oscillator could cause larger or smaller than expected delays steps between certain trim points, so I designed my encoding to balance the multiplexing around the ring oscillator as much as possible. Having just measured the DLL for the first time running correctly, I get a measured jitter of 1.3ns. The numbers I cited in the documentation are what you would get if the ring oscillator were hand-optimized. Instead, we just ran the thing through standard place and route with the usual low core utilization, so there are significant parasitic wire delays. At 1.8V the DCO reaches 118MHz; by upping the vccd voltage to 2.0V it can it 150MHz. Consequently, though, at standard 1.8V the delays are about double the ideal value. The 1.3ns RMS jitter number is quite tolerable, though, considering that it is done completely through standard digital synthesis.

Thank you very much for explanation. My understanding is that the original formula: "delay_ps = 4670 + (bits * 250)" may need to be modified to reflect the delay in actual implementation. There are 2 sets of trim bits in 26 bits and default value 0x3ff_effff has all 13 bits set in the first group, which needs to be set first, but only 12 bits set in the other group.

@Nelson Salvador @Francisca Donoso FYI