Electronics > Projects, Designs, and Technical Stuff
FPGA oddness
TmaxElectronics:
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?
mfro:
--- Quote from: TmaxElectronics on November 28, 2019, 02:12:03 pm ---are there any standard debugging procedures i can follow?
--- End quote ---
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.
TmaxElectronics:
Ok thanks i will try that :D
Giaime:
--- Quote from: mfro on November 28, 2019, 02:38:23 pm ---
--- Quote from: TmaxElectronics on November 28, 2019, 02:12:03 pm ---are there any standard debugging procedures i can follow?
--- End quote ---
FPGA debugging <=> HDL simulation (for the most part, at least).
--- End quote ---
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.
AndyC_772:
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.
Navigation
[0] Message Index
[#] Next page
Go to full version