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 board?

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

What happens is if I use non-default options for synthesis and/or place-&-route, the functional hardware read/write tests fail in an erratic way. I've narrowed it down to (not 100% sure) possibly synthesis options involving state-machine encoding, but am wondering if there are flaws in my RTL, constraints 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 better but both the synthesis and par tool are versions that are older than the latest versions by a couple of software generations).

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

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


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


Much appreciated,
Harnhua

 

[Thomas Stanka]

Hi,

Am Mittwoch, 30. April 2014 09:19:04 UTC+2 schrieb har...@plunify.com:
> 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 board?

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

Usually if a design is proper constraint and static timing analysis is 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 standard design, assume the affected designs due to tool bugs beeing in small ppm..

Equivalence checking helps in identifying real bugs of synthesis and par tools, 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 certain 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

 

[GaborSzakacs]

Thomas Stanka wrote:

Hi,

Am Mittwoch, 30. April 2014 09:19:04 UTC+2 schrieb har...@plunify.com:
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 board?

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

Usually if a design is proper constraint and static timing analysis is 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 standard design, assume the affected designs due to tool bugs beeing in small ppm.

Equivalence checking helps in identifying real bugs of synthesis and par tools, 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 certain 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

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

 

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 some modules but judging by your comments, I should do an in-depth check.

Regards,
Harnhua

On Wednesday, 30 April 2014 21:42:40 UTC+8, Gabor wrote:

Thomas Stanka wrote:

Hi,



Am Mittwoch, 30. April 2014 09:19:04 UTC+2 schrieb har...@plunify.com:

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 board?



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



Usually if a design is proper constraint and static timing analysis is 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 standard design, assume the affected designs due to tool bugs beeing in small ppm.



Equivalence checking helps in identifying real bugs of synthesis and par tools, 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 certain 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



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