Forum Discussion

Armando1989's avatar
Armando1989
Icon for Occasional Contributor rankOccasional Contributor
1 year ago
Solved

MAXII CPLD ADDRESS GENERATION GLITCHES

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!

Fpga Devkit
  • FvM's avatar
    FvM
    1 year ago

    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.

8 Replies

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    1 year ago

    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's avatar
      Armando1989
      Icon for Occasional Contributor rankOccasional Contributor
      1 year ago

      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's avatar
        FvM
        Icon for Super Contributor rankSuper Contributor
        1 year ago

        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.

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    1 year ago

    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's avatar
      Armando1989
      Icon for Occasional Contributor rankOccasional Contributor
      1 year ago

      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's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    1 year ago

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

    ?{ADDRESS_BUS_WIDE{1'bz}}:

    or simply

    ?{1'bz}:

    • Armando1989's avatar
      Armando1989
      Icon for Occasional Contributor rankOccasional Contributor
      1 year ago

      ?{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