1. Home
  2. Field-Programmable Gate Arrays
  3. Synthesis / PAR options mess up design functionality

Synthesis / PAR options mess up design functionality

Hi,

I'm running into a problem with a memory controller design (mid-range FPGA, 76% utilization) and am wondering if anyone out there has seen synthesis / place-n-route options causing a design to fail when programmed onto a boar d?

Functional simulation passes all tests, and the RTL has been frozen for a w hile, and I am experimenting with different synthesis and place-&-route opt ions to see if I can get better area and speed results. My steps are: I cha nge a few options, re-compile, program the board and do a few functional te sts.

What happens is if I use non-default options for synthesis and/or place-&-r oute, the functional hardware read/write tests fail in an erratic way. I've narrowed it down to (not 100% sure) possibly synthesis options involving s tate-machine encoding, but am wondering if there are flaws in my RTL, const raints or design that are causing these.

Here are some questions that I'm trying to get a handle on:

  1. Could these problems be due to bugs in my synthesis / place-&-route tool ? (Am omitting the vendors here to avoid debates on whose tools are bette r but both the synthesis and par tool are versions that are older than the latest versions by a couple of software generations).

  1. If you have experienced such problems, were they more due to synthesis o ptions or to place-&-route ones? In the sense that, if the synthesis tool i s causing problems, maybe I can just fiddle with par options instead.

  2. Will formal verification or some sort of pre-/post-synthesis or par equi valence checking help resolve such problems?

If anyone has seen such issues before, I'd appreciate it if you can share s ome of your experiences (and solutions!).

Much appreciated, Harnhua

Reply to
harnhua
Loading thread data ...

Hi,

Am Mittwoch, 30. April 2014 09:19:04 UTC+2 schrieb snipped-for-privacy@plunify.com:

A, 76% utilization) and am wondering if anyone out there has seen synthesis / place-n-route options causing a design to fail when programmed onto a bo ard?

At least 95% of such problems are due to wrong handling of clock-domain-cro ssing (CDC), which I would check first.

Usually if a design is proper constraint and static timing analysis is succ essful, there is no problem in synthesis but in your code. There are a sma ll number of bugs in synthesis/par/fpga which will affect usually no standa rd design, assume the affected designs due to tool bugs beeing in small ppm .

Equivalence checking helps in identifying real bugs of synthesis and par to ols, but more likely will help you identifying that code that synthesis is allowed to interpret other than you expect.

There are several possibilities to write code that simulates well (under c ertain circumstances) but is not describing the HW you intended to get.

When it comes to wrong constraint code (like multicycle constraint or false

-path constraint on critical paths) or wrong handled CDC, you will have no benefit using equivalence check.

regards Thomas

Reply to
Thomas Stanka

If it seems that FSM encoding changes the behavior, it's likely that you have a CDC within your state logic, i.e. an asynchronous input to the state machine. Some encodings, especially binary with complete use of all possible states, can survive an event while other encodings, especially one-hot, can end up in a stuck state, like zero-hot, from an event. Changes in placement and routing can cause these problems to show up or get masked, depending on the relative routing delay to multiple loads of the same async signal.

--
Gabor
Reply to
GaborSzakacs

Thank you very much for the pointers, Thomas and Gabor. I'll look into the interfaces and areas where CDC might cause problems. There is already some FIFO circuitry to address clock domain crossing in so me modules but judging by your comments, I should do an in-depth check.

Regards, Harnhua

FPGA, 76% utilization) and am wondering if anyone out there has seen synthe sis / place-n-route options causing a design to fail when programmed onto a board?

-crossing (CDC), which I would check first.

successful, there is no problem in synthesis but in your code. There are a small number of bugs in synthesis/par/fpga which will affect usually no st andard design, assume the affected designs due to tool bugs beeing in small ppm.

r tools, but more likely will help you identifying that code that synthesis is allowed to interpret other than you expect.

er certain circumstances) but is not describing the HW you intended to get.

alse-path constraint on critical paths) or wrong handled CDC, you will have no benefit using equivalence check.

Reply to
harnhua

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.