New Contributor
Super ContributorHi,
I don't feel that my previous questions have been answered.
Anyhow, let me ask additional questions related to your latest published clock-module.4.v.
1. Are you aware that in synthesizable Verilog the module clock iCLK_ff can't be internally generated but must be provided through module interface? What's the intended clock frequency?
2. What are the expected waveforms of iLatch1 and iLatch2?
[Addendum]
Here's the RTL schematic of clock-module.4.v
And so the "clock" appears in post-mapping schematic
I'm a bit surprized that Quartus does accept it at all. Interestingly it's not listed as clock in timing analyzer.
New Contributor1) "must be provided through module interface" I not convinced - while I understand I was generating a overly fast clock, as long as it's slow enough I'm sure I could use an internal clock, since the iCLK=!iCLK timer worked to increment the counter several times; but I guess I introduced a bunch of inferred latches between when it almost worked and when it didn't work at all. (The following was tested after the rest of the message was written) The following synthetic clock works from 1 to 5, 0 has a lot of jitter, but 1 triggers the counter about every 0.5-0.7ns; 2 triggers it every 3.7 to 3.8ns; 3 is about 7ns, 4 is about 15ns, then there's a big jump and 5 triggers the counter every 47ns, and 6 is about 60ns. (though this is brittle; I remove all the other code, and it stopped working entirely - I've put it back now, but only get 5ns for synthclock[1] and 10ns for synthclock[2])
reg [6:0] rSynthClock = 0; always begin #1 rSynthClock[0] = !rSynthClock[0]; end always @(posedge rSynthClock[0] ) rSynthClock[1] = !rSynthClock[1]; always @(posedge rSynthClock[1] ) rSynthClock[2] = !rSynthClock[2]; always @(posedge rSynthClock[2] ) rSynthClock[3] = !rSynthClock[3]; always @(posedge rSynthClock[3] ) rSynthClock[4] = !rSynthClock[4]; always @(posedge rSynthClock[4] ) rSynthClock[5] = !rSynthClock[5]; always @(posedge rSynthClock[5] ) rSynthClock[6] = !rSynthClock[6];
2)The latch signal waveform is slow - 1ms on with an off time of about 1 second. which is forever by any of the clocks.
I brought in the iCLK_MAIN that is given to the design from the _top file. It's only a 120mhz clock.
I then implemented a phase shift on that clock https://stackoverflow.com/a/50172237/4619267
but that actually makes a lot of latches which make the phases pretty slow. The phase offset is only about 1ns, I get basically 8 phases on the 120Mhz clock which gets me to 960Mhz effectively.
The phase shifter is a long list of these... up to [25].
always @(posedge globalClock ) iCLK_ff_p[0] = !(iCLK_ff_n[0]); always @(negedge globalClock) iCLK_ff_n[0] = (iCLK_ff_p[0]); always begin #5 iCLK_ff[0] = iCLK_ff_p[0] ^ iCLK_ff_n[0]; end always @(posedge iCLK_ff[0] ) iCLK_ff_p[1] = !(iCLK_ff_n[1]); always @(negedge iCLK_ff[0]) iCLK_ff_n[1] = (iCLK_ff_p[1]); always begin #5 iCLK_ff[1] = iCLK_ff_p[1] ^ iCLK_ff_n[1]; end
I could wish for a less latch intensive solution. Now nothing changes faster than the main clock now, I just get 25 waveforms that are the same as the main clock offset by an amount. (which since there's only 8 phases that actually tracks about 3 clock pulses 4 on bits and 4 off bits... basically like this screenshot...
iCLK is the main clock (at the top) and iClk_ff[n] are phase shifted version - they composite into the top value of like 0000111100001111000011110, 0001111000011110000111100, etc.
400 MHz would help, but not really because then I'd only get a couple phases on top of that.
The internal gates seem to be about 200ps, so I don't see it as entirely out of the ball park... (other than it seems to take at least 5 gates to form the phase shifted latches... ) but I can't think of a better way to do the phase shifting.
This node has quite a few things in 'Equation' to make it... which is part of the phase shift logic
