open-source-silicon.dev

I find the core Clk or wishbone clk and user clk2 has some differences. Has anyone used two blocks in their digital design?  Using theses two clocks can cause timing issues in same design . I probed mproj io 14,15 for these results respt.

<@U016EM8L91B> might be able to comment on whether this observation is normal. <@U053UFMPKDW>, for reference, is the top waveform from GPIO[14] and bottom is GPIO[15], and what are your HKSPI register values for this test (i.e. output from caravel_hkdebug)?

Oh, I also notice you're sampling at 100MS/s. Can you do higher?

yes top is gpio 14 and below is userclk2 gpio 15

hkspi regs:
reg 0x0 = b'00'
reg 0x1 = b'04'
reg 0x2 = b'56'
reg 0x3 = b'11'
reg 0x4 = b'1d'
reg 0x5 = b'd6'
reg 0x6 = b'88'
reg 0x7 = b'c4'
reg 0x8 = b'02'
reg 0x9 = b'01'
reg 0xa = b'00'
reg 0xb = b'00'
reg 0xc = b'00'
reg 0xd = b'ff'
reg 0xe = b'ef'
reg 0xf = b'ff'
reg 0x10 = b'03'
reg 0x11 = b'12'
reg 0x12 = b'04'
reg 0x1a = b'0f'
reg 0x1b = b'06'

<@U06H50VMDPU>, <@U053UFMPKDW>:  The "user clk2" is intended to be an independent clock source;   if you take it directly from the DLL it is 90 degrees out of phase with the core clock.  If both are taken from the external clock, they are the same clock, but since they were intended to be independent, I don't think the digital design team put any constraints on the timing between the two, so none can be inferred.

Thanks <@U016EM8L91B> :slightly_smiling_face: So <@U053UFMPKDW>, you have `reg 0x09 = b'01'` which means both clocks are driven "directly" by the external source -- though as Tim pointed out there is a potential skew between the two as they likely have different paths, buffers, loading etc. and I recall from the SDC file that the input delay of user_clock2 is a little less than that of wb_clk_i, so maybe this is what you're seeing. You're measuring a 10MHz signal at 100MS/s (100MHz) -- that small leading edge you're seeing on user_clock2 is in the margin of error at this sample rate, i.e. you can see that it is _sampled_ as 1/10th of the core clock's period. If your logic analyzer can do more than 100MS/s, this discrepancy might reduce.

<@U053UFMPKDW> to back up what I was saying about your sampling rate... I've measured a chip on my scope and found that in "bypass mode" (which is what you have activated by `reg 0x09 = b'01'`), the GPIO 14 output (wb_clk_i) is slightly behind GPIO 15 (user_clock2) -- somewhere on the order of about 4-8nS. This is normal, due to those slightly different clock paths, and it's in the region where your 100MS/s sampling rate could measure it to be +/- 1 whole sample (10nS), which probably explains why it appears to rise 10nS early, but fall at the same time -- as I said, within the margin of error. If you could sample at 200MS/s or more, you _might_ be able to see both edges being different, rather than just the rising edge.

I will be called a nit-picking grammarian, but "nS" is nanosiemens.  "ns" is nanoseconds.

<@U016EM8L91B> Oh, good to know! I've been making that mistake a long time.