Author Topic: Strange FPGA issue  (Read 692 times)

0 Members and 1 Guest are viewing this topic.

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 271
  • Country: gb
    • Matt's Projects
Strange FPGA issue
« on: May 14, 2018, 06:16:03 am »
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...
Read about my stuff at: projects.matthollands.com
 

Online imo

  • Frequent Contributor
  • **
  • Posts: 370
  • Country: 00
Re: Strange FPGA issue
« Reply #1 on: May 14, 2018, 07:28:29 am »
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..
« Last Edit: May 14, 2018, 07:35:02 am by imo »
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 271
  • Country: gb
    • Matt's Projects
Re: Strange FPGA issue
« Reply #2 on: May 14, 2018, 08:30:24 am »
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!

Read about my stuff at: projects.matthollands.com
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 4467
  • Country: us
Re: Strange FPGA issue
« Reply #3 on: May 15, 2018, 02:15:19 am »
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.
 

Offline MattHollands

  • Frequent Contributor
  • **
  • Posts: 271
  • Country: gb
    • Matt's Projects
Re: Strange FPGA issue
« Reply #4 on: May 15, 2018, 08:52:34 am »
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.
Read about my stuff at: projects.matthollands.com
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 4544
  • Country: us
    • Personal site
Re: Strange FPGA issue
« Reply #5 on: May 15, 2018, 09:07:51 am »
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.
Alex
 

Offline NorthGuy

  • Frequent Contributor
  • **
  • Posts: 913
  • Country: ca
Re: Strange FPGA issue
« Reply #6 on: May 15, 2018, 10:13:31 am »
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?

 

Offline Sparker

  • Contributor
  • Posts: 40
  • Country: ru
Re: Strange FPGA issue
« Reply #7 on: May 17, 2018, 08:37:22 am »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf