Strange FPGA issue

[MattHollands]

Hi,

I am using an FPGA to drive a display. There are three outputs VGA_RED_O, VGA_BLUE_O, VGA_GREEN_O which are 4-bit outputs, defined as so:

Code: [Select]

output wire[3:0] VGA_RED_O,VGA_BLUE_O,VGA_GREEN_O;
I also have a 4-bit wire called TX_VGA_VIDEO which is the output of a submodule.

Using these lines, the output is as expected - the video looks correct.

Code: [Select]

    assign VGA_RED_O = TX_VGA_VIDEO;
    assign VGA_GREEN_O = TX_VGA_VIDEO;
    assign VGA_BLUE_O = TX_VGA_VIDEO;
Using these lines, the output is also as expected - the colours are weird but that's intentional:

Code: [Select]

    assign VGA_RED_O = (TX_VGA_VIDEO[3] ? 4'b1111 : 4'b0000);
    assign VGA_GREEN_O = (TX_VGA_VIDEO[2] ?  4'b1111 : 4'b0000);
    assign VGA_BLUE_O = ((TX_VGA_VIDEO[1] | TX_VGA_VIDEO[0]) ? 4'b1111 : 4'b0000);
However, if I combine the two using a switch input to switch between them:

Code: [Select]

    assign VGA_RED_O = (SW[13] ? (TX_VGA_VIDEO[3] ? 4'b1111 : 4'b0000) : TX_VGA_VIDEO);
    assign VGA_GREEN_O = (SW[13] ? (TX_VGA_VIDEO[2] ?  4'b1111 : 4'b0000) : TX_VGA_VIDEO);
    assign VGA_BLUE_O = (SW[13] ? ((TX_VGA_VIDEO[1] | TX_VGA_VIDEO[0]) ? 4'b1111 : 4'b0000) : TX_VGA_VIDEO);
The video signal is always black! in fact, other things are messed up too, like other outputs appearing strange.

However, I can fix the situation by adding the line:

Code: [Select]

assign LED[4] = SW[13];Where LED is an output.

Both SW and LED are asynchronous.

What could be causing my code to break!? I would simulate it, but this code is in my main module and therefore to simulate it would require simulating a lot of other things.

The only thing I can think of is that I have a clock input to the FPGA that is not going through a proper clock input pin of the FPGA (layout oversight) and therefore vivado complains a lot about the routing being bad, could this be causing the issue? Even though it's such a small change...

[iMo]

Look into the reports, it could be the SW[13] has been optimized out (missing or wrong SW13 pin assignment/location/type in pins constraints for example), thus everything related to it is optimized out too..
The

Code: [Select]

assign LED[4] = SW[13]; returns it back into the game..

[MattHollands]

Nice idea. I can see SW[13] in the schematic.

An example of the other weird things that happen: I have basically a passthrough from some inputs called G[9:6] which goes straight to an output called JC (see attached image)... This is the schematic apparently, but the output is always low. I can measure a signal on G[9] but I can't see any signal on the corresponding signals on JC. If I add the LED[4] = SW[13]  line, it gets fixed!

[rstofer]

Signals that don't appear on the top level PORT or create/use those signals, will be optimized away.  There's no point in synthesizing logic that doesn't do anything.

Regardless of what the code does, it ultimately has to take inputs and deliver outputs.  Any signals that don't get involved one of these two things won't be synthesized.

[MattHollands]

Signals that don't appear on the top level PORT or create/use those signals, will be optimized away.  There's no point in synthesizing logic that doesn't do anything.

Regardless of what the code does, it ultimately has to take inputs and deliver outputs.  Any signals that don't get involved one of these two things won't be synthesized.

Well VGA_RED_O are direct outputs. So they won't be optimised away. SW[13] is a direct input and modifies VGA_RED_O so shouldn't be optimised away.

I have bodged my clock input to use a proper clock input pin on the FPGA and this *seems* to have gotten rid of the issue. I'm hesitant to say it has gotten rid of the underlying issue. Is it possible that using a clock on a non-optimal route could be causing this bug? Seems odd that such a small change breaks it.

[ataradov]

Whether things can be optimized may depend on how those pins were declared in the constraints file, or equivalent for that FPGA.

Generally things like this will be noted in the reports.

[NorthGuy]

Is it possible that using a clock on a non-optimal route could be causing this bug?

You mean clock on non-CC capable pin? This shouldn't cause anything dramatic. The only difference is that, instead of a straight wire to the buffer, the clock takes (possibly long) route through the FPGA fabric. This increases clock jitter, worsens temperature stability, may be even can affect the ability of MMCM/PLL to lock.

But none of this should affect the straight wire through FPGA as you showed in your example, unless your FPGA doesn't get configured at all. Does the DONE pin ever go high?

[Sparker]

Do you have the timing constraints set up in your project? Usually weirdest things happen if you don't. Like what appeared to be working right might break because you changed something and now fitter places the logic differently.