Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

CPLD acting strangely

Hello.

I designed an interface between an FPGA and a CPLD (MAXII) which is not entirely synchronous. The interface consists of 3 lines: Data, Clock and Enable. Each command transfered is 32 bits long, starting with a '0' on the Enable, followed by 32 clocks and ending with a rising edge on the Enable line (the clock is active only when Enable is low). The logic inside the CPLD shifts in the data bits each Clock cycle (while Enable is low), and the command is registered on the rising edge of Enable.

The problem I'm facing is this: Each command is doing what it should, but is also affecting the previous commands sent (as if the data is overwritten). Timing simulation (of the CPLD) in Quartus shows that everything is working properly. I probed the inputs with a logic analyzer and everything is looking ok as well.

Is it possible that the timing simulation is not showing problems inside the CPLD, although they exist?

Since this interface is not entirely synchronous, is it possible that the MAXII series (or Quartus) have problems synthesizing/instantiating this kind of code?

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    Is it possible that the timing simulation is not showing problems inside the CPLD, although they exist?

    --- Quote End ---

    Sounds like a design fault. It's not necessarily shown in timing simulation, because it hardly reproduces the exact input signal and device internal timing.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Since there are very little inputs, I was able to see with a scope that they are exactly those that I simulated in the timing simulation (so I can guess that we can rule out wrong inputs to the simulation). In addition, the design was suppoused to work at 20MHz, and we reduced the working frequency to about 1MHz, still to have this problem. I guess that the timing simulation might not be simulating correctly what happens in the internal logic (as you suggested).

    Is there a way to make a more accurate simulation than the timing simulation in Quartus? If not, is it possible to find the bug by looking at the RTL or something of that sort?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Did you set the timing constraints including the delays from the input lines to the first registers?

    Maybe these delays are very different and your design doesn't work since the input data are synchronized from the wrong input clock.