I have migrated an existing project from a cyclone 1 FPGA to a MAX10 FPGA.
I had no constraints, I have added just master clock that is a 32MHz clock. External signal can be asynchronous (from identical boards connected by wire and physical 485 Transceiver), and runs at 4MHz or less.
I solved some issues, related to:
- uncorrect sampling of asynchronous signals (followed intel design guidelines and added a couple of flip flop to prevent metastability)
- Used safe state machines compiler option to prevent that state machine get into an unknown state (observed in some case via GPIO and/or Signal Tap)
In this way I solved some strange behaviour. Notice that, before this fix, I get communication problems in some condition, ad just moving a pin, shorting a cable, inserting signal tap seemed to solved the issues, except that just touching something else and the issues get back again.
Last fix to increase stability is to set compiler option to have gray code for machine state.
What else can I do? I have looked at intel design guidelines and everything seems ok about clock and reset management. What else to look for? How gray code for machine states can improve stability?
Thank you, regards, roberto
Have you look at the Quartus Design optimization? This could help you to meets the design goals while reducing area, critical path delay, power consumption, and runtime.
Thank you Syafieq
- Is the reported behaviour a common issue in analogous situation? Never heard before?
- could gray code for machines state improove stability? Or it is just a lucky happening that this work?
- any other Quartus suggested optimization setting to mitigate described behaviour?
- any other VHDL code design aspect to pay attention for?
Thank you a lot,
Missing any other answer, I’ll try to define some points to check, in the hope that could helps any other user with similar issues.
Object: Migrating from old design (Cyclone 1) to new one (MAX10)
Problem: strange behaviours, unstability, FPGA do the same thing but whit random errors and blocking issues.
- Migrate library components, as FIFO
- Check any new or modified pins and set for most conservative approach (High Z input explicitly set)
- Check Intel Design Guidelines (Eg: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-qpp-design-recommenda... ) and apply what is missing:
- Clock schemes
- Latching of external asynch signals
- Reset management
- Optimize for safe state machine, grey coding of states, optimize for stability
Migrating this way, my old design finally passed a quite severe testing procedure, involving also thermal testing at -30 and +64°C
I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.