FPGA oddness - Page 1
Forum section: electronics / projects

author: TmaxElectronics
author_rank: Regular Contributor
timestamp: November 28, 2019, 02:12:03 pm
content: 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 happeningand 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?

author: mfro
author_rank: Regular Contributor
timestamp: November 28, 2019, 02:38:23 pm
content: Quote from: TmaxElectronics on November 28, 2019, 02:12:03 pmFPGA 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.

author: TmaxElectronics
author_rank: Regular Contributor
timestamp: November 28, 2019, 02:45:24 pm
content: Ok thanks i will try that

author: Giaime
author_rank: Regular Contributor
timestamp: November 28, 2019, 02:46:11 pm
content: Quote from: mfro on November 28, 2019, 02:38:23 pmYep, 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: November 28, 2019, 03:10:10 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 28, 2019, 03:25:41 pm
content: 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?

author: emece67
author_rank: Frequent Contributor
timestamp: November 28, 2019, 06:06:38 pm
content: .

author: TimCambridge
author_rank: Regular Contributor
timestamp: November 28, 2019, 06:25:21 pm
content: Quote from: TmaxElectronics on November 28, 2019, 02:12:03 pmIf 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.

author: TmaxElectronics
author_rank: Regular Contributor
timestamp: November 29, 2019, 11:01:25 am
content: Thanks for the help guysso 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.QuoteAre 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

author: AndyC_772
author_rank: Super Contributor
timestamp: November 29, 2019, 11:23:06 am
content: Just think of them as "warning: your design won't work because..."

author: donmr
author_rank: Regular Contributor
timestamp: November 29, 2019, 07:19:36 pm
content: 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.