MAXII CPLD ADDRESS GENERATION GLITCHES

[Armando1989]

Hi There

Im working on VGA module with EPM240T100C4, all seems fine except adress bus outputs.

Im facing glitches, which not present on questaSim gate analisys

but are present on logic analyzer real capture. Below is adress bus A

As u see below, higher ourder bits on counter start suffering glitches, i bet because gate delay is too big.

Address is incremented each 25MHz/16. Is it any bottleneck with this actual model that is unable to avoid those glitches abobe stated frequency and up to this counter value?.

Attached sources.

Thanks in advance!

[FvM]

Hi,
addressbus outputs are registered, it doesn't look like a classical glitch. More likely wrong/unexpected output is appearing for full clock cycles. Need to see higher resolution output. The time range shown in simulator output (address 19194-19199) has no "glitches" in real hardware either.

MAX II should be fast enough for 50 MHz clock. But your .sdc is empty, timing analysis doesn't check design timing. vsync_reg is probably causing timing violations and improper swap signal edges. This should be fixed, but I don't expect it to cause problems far away from swap edges.

We can't check the simulation because rgb_encoder source is missing.

[Armando1989]

Hi FyM!

Thanks for your comment in advance.

1-sdc file includes just clk and clk_virt ive not included output delays. If u have any concern on this let me know

create_clock -name {clk} -period 20.000 -waveform { 0.000 10.000 } [get_ports {clk}]
create_clock -name {clk_virt} -period 20.000 -waveform { 0.000 10.000 }

2-Sorry, attached rgb encoder output Attached on .rar

3-Ive tried another project just using IP library lpm_counter for 15 bits, just to count up to 19200 using same clock source of 50MHz/32. Guess what... i still find also what looks as u say, spikes of 50Mhz clock wide (10ns), sometimes other wides..., see below:

As u can see above image, the highest significant bits are also prone to this stuff, and u can notice how the decoded count value is corrupted of course.

on VGA im using just my own sync counter and have simillar issue on real hw as i have with lpm_counter IP library, timing analisys both cases PASS always, as said ive not constraint all paths but clocks.

Let me see your views.

Thanks!!!

BR

[FvM · Accepted solution]

Thanks,
I overlooked clk definition in .sdc file which is basically o.k. and should be sufficient to report timing violations in internal logic. Reported Fmax is about 140 MHz, suggesting much of timing margin. I don't see how the glitches can be brought up in address counter and mux logic. I rather guess it's an logic analyzer artifact due to insufficient ground connection or unsuitable level threshold setting. I presume that address lines are not externally driven during glitch period.

[Armando1989]

Hi FvM, thanks for your answer!

Indeed, it was a darn ground issue... After fiting the shield on  lines to GND the artifacts gone... Just cpld aliexpress dev board lacks on sufficient gnd plugs for each channel, which is bad practice but cost and pcb space won the battle..

For vsync and adress buss mux, still experience glitches during vsync bus switchover, as per below image. 

Of course, i would need constraint vsync as a clock, since is driving the "swap" signalling

however seems i cannot do generated clock which is that high division ratio, vsync is 60Hz... For those cases, is worth declaring as false path? have u any concern on this?

Thanks!

[FvM]

Hi,
"glitches" during floating address lines are just expectable because logic level is undefined.

I already mentioned that using vsync_rec as clock is bad design practice. 

Better use synchronous edge detection

always @(posedge clk)begin
  vsync_reg<=vsync;
  vsync_reg1 <= vsync_reg;
  if  (!vsync_reg & vsync_reg1)
    swap <= !swap;
end

[Armando1989]

Hi FvM

Yes, ive already solved by retiming vsync, however i applied your solution better so no clk domain cross, problem is solved, no further artifacts nor glitches:

Just one more "notation question", could below statement be modified so it updates when bus wide changes instead of manually add by hand according to bus wide changes?. Im not quite concern on this regard indeed...

Thanks so much for your help!

[FvM]

Hi,
I'm not so familiar with Verilog but this should work

?{ADDRESS_BUS_WIDE{1'bz}}:

or simply

?{1'bz}:

[Armando1989]

?{ADDRESS_BUS_WIDE{1'bz}}:  that one did the work, ?{1'bz}: this would just float first bit but not the whole.

Thanks FvM!

BR