Author Topic: FPGA oddness  (Read 1221 times)

0 Members and 1 Guest are viewing this topic.

Offline TmaxElectronicsTopic starter

  • Regular Contributor
  • *
  • Posts: 55
  • Country: de
    • My random (and very empty) electronics blog
FPGA oddness
« on: November 28, 2019, 02:12:03 pm »
I have just made my first design using an FPGA (until now i have always used dev boards) and am having some issues with it.
I am using the MachXO3-9600C-6BG256C FPGA from lattice to drive an LED panel with data stored in external RAM.
So far i have got the thing to output test data to the panel but am stuck making it read the ram.

The problem is now, that changing some things that should not affect anything else (like outputting a signal to another pin for debugging) will make the entire thing stop working. (it is honestly quite hard to explain :-// )
For example: there was an issue with an internally divided clock (just a bit from a counter), which only ran at ~100Hz instead of the 30MHz intended. But once i assigned it to a debug led output  (LED <= clk30;) it just worked again.
Or changing a divider ratio (in an entirely different module!) caused an addition not to execute (sig <= sig + '1') or a bit to not be set sometimes (litterally randomly as the thing was running).
Or a memory address calculation (currPixAddress <= ram_currColor + (nextLine+ram_currLine * x"20") * x"180" + (ram_currPix * x"3")) worked until i assigned it to the address input of an internal ram IP, then it just stayed at zero.

Unfortunately my head has now given up trying to understand what is happening  |O and i have no idea where i can even start debugging (i have already tried to decrease the master clock speed from 200MHz to 100MHz and 50MHz)
I am also pretty much a noob when it comes to FPGAs so i dont really know what this could come from or how to properly explain the issues i am having (if it doesn't make sense what i wrote please ask and i will try to explain it better).

are there any standard debugging procedures i can follow?
 

Offline mfro

  • Regular Contributor
  • *
  • Posts: 224
  • Country: de
Re: FPGA oddness
« Reply #1 on: November 28, 2019, 02:38:23 pm »
are there any standard debugging procedures i can follow?

FPGA debugging <=> HDL simulation (for the most part, at least).

Run your code in the HDL simulator and observe relevant signals for correctness. Only once you get the results you are expecting, start to attack the hardware part of it.

Then you only have to deal with the (much smaller) superset of problems where the hardware refuses to reflect logic that has already been fully debugged and proven.
Beethoven wrote his first symphony in C.
 

Offline TmaxElectronicsTopic starter

  • Regular Contributor
  • *
  • Posts: 55
  • Country: de
    • My random (and very empty) electronics blog
Re: FPGA oddness
« Reply #2 on: November 28, 2019, 02:45:24 pm »
Ok thanks i will try that :D
 

Offline Giaime

  • Regular Contributor
  • *
  • Posts: 72
  • Country: it
Re: FPGA oddness
« Reply #3 on: November 28, 2019, 02:46:11 pm »
are there any standard debugging procedures i can follow?

FPGA debugging <=> HDL simulation (for the most part, at least).

Yep, sounds like a timing issue. First verify in simulation that everything works as expected (write a testbench for it).
Then start doing some online trainings (check the vendor website, they're free usually) for timing analysis.
You'll need to learn how to constrain your design (writing a .sdc file) and then check timings.
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 4315
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: FPGA oddness
« Reply #4 on: November 28, 2019, 03:10:10 pm »
This sort of behaviour is exactly typical of a design which has not been created with timing requirements, and most especially metastability, in mind.

For example, your memory address calculation is quite complex, and might not be achievable in a single clock cycle.

It's quite possible that your design sometimes gets fitted in a way which produces internal hold time violations. You should get warnings or errors from the fitter in this case, and if you do get them, it's virtually guaranteed that your design will be flaky at best.

FPGAs are very robust and reliable devices, but they require a design approach that takes a deep understanding of timing requirements into consideration at every level.
 
The following users thanked this post: Someone

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15797
  • Country: fr
Re: FPGA oddness
« Reply #5 on: November 28, 2019, 03:25:41 pm »
A couple things to check: 1/ does your design yield any timing violation once implemented? You can't usually ignore them; and 2/ is there any asynchronous signal, or otherwise any clock domain crossing that is not handled properly?
 

Offline emece67

  • Frequent Contributor
  • **
  • !
  • Posts: 614
  • Country: 00
Re: FPGA oddness
« Reply #6 on: November 28, 2019, 06:06:38 pm »
.
« Last Edit: August 19, 2022, 02:40:29 pm by emece67 »
 

Offline TimCambridge

  • Regular Contributor
  • *
  • Posts: 98
  • Country: gb
Re: FPGA oddness
« Reply #7 on: November 28, 2019, 06:25:21 pm »
I have just made my first design using an FPGA (until now i have always used dev boards) and am having some issues with it.
I am using the MachXO3-9600C-6BG256C FPGA from lattice to drive an LED panel with data stored in external RAM.

<snip>

are there any standard debugging procedures i can follow?

If the simulation looks OK, hook up an external debugger and use Reveal, part of the free Lattice software. Lattice sell debuggers but the clones on ebay work fine, as do the cheap FT2232H boards. FT2232H boards from CJMCU seem to cost approx $10.

I understand that the cheap FT232H boards work as well. Clones come with cables, for FTxxxx boards you have to make your own.
 

Offline TmaxElectronicsTopic starter

  • Regular Contributor
  • *
  • Posts: 55
  • Country: de
    • My random (and very empty) electronics blog
Re: FPGA oddness
« Reply #8 on: November 29, 2019, 11:01:25 am »
Thanks for the help guys :D
so far i was just naive enough to ignore the timing violation warnings, as i expected them to be kind of like compiler warnings and also didn't know how exactly to find where the issue was.
It will take me a while to get to grips with the simulator but it will definitely help.

Quote
If the simulation looks OK, hook up an external debugger and use Reveal, part of the free Lattice software. Lattice sell debuggers but the clones on ebay work fine, as do the cheap FT2232H boards. FT2232H boards from CJMCU seem to cost approx $10.
Are those just the normal JTAG-usb adapters or are there more connections required? I have already got a FT2232 on the board for USB-UART conversion and have used the second channel of it for JTAG
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 4315
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: FPGA oddness
« Reply #9 on: November 29, 2019, 11:23:06 am »
Just think of them as "warning: your design won't work because..."

Offline donmr

  • Regular Contributor
  • *
  • Posts: 155
  • Country: us
  • W7DMR
Re: FPGA oddness
« Reply #10 on: November 29, 2019, 07:19:36 pm »
They are warnings in the sense that the part may work at some voltages, temps, and clock speeds, and not at others.

Setup time warnings mean the design may not work at maximum clock speed, max temp, min voltage, but may work under other conditions.  You can often slow down the clock to get around these initially.

Hold time violations are not affected by the clock speed and are harder to work around even for debugging.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf