UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer chanyeoh
Observer
2,992 Views
Registered: ‎03-11-2016

Simulated Results different from Implemented Results

Jump to solution

Hello all,

I have recently ran into some troubles in a big design for vivado simulation. I am doing some image processing techniques with some cores that I have built myself, including the test pattern generator and the VGA output and HDMI output core. 

 

It all seem to work fine, until I had to build my own convolution core. Some of the test pattern generator appears to have the same output, while others appear to have other outputs. Hence, I cam across this thread:

https://forums.xilinx.com/t5/Synthesis/How-to-avoid-signal-optimizing-in-synthesis/td-p/76056/page/3

 

In the last post it mentions that the person uses and or statement to ensure that the signals are working. I have done that it indeed works, however, when I start building up various cores, then various test patterns generates different results, some doesn't appear to have a pattern, while some produce the right result, and some produces a different output. 

 

At this point, I do not know if it is a failure in my logic block ,or if it is a failure in the synthesis tool. It seems very implausible to write an if condition in every statement just to ensure that the logic works. Would using keep and don't touch help? Or is there some failure in my core's logic. 

 

I am having a hard time to determine whether it is a failure in my logic, or if it is a failure in the synthesis tool. I would like some advices to debug this issue.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
5,519 Views
Registered: ‎01-23-2009

Re: Simulated Results different from Implemented Results

Jump to solution

I can't help you with the specifics of your problem, but maybe I can rule out a couple of things...

 

99.999% of the time it is not a bug in the tools. While bugs do occasionally happen in the tools, they are very rare... You also do not need to prevent the tools from removing something with KEEP or DONT_TOUCH - the bugs that people often claim these "fix" are usually really just RTL bugs.

 

Most of the time, the problems come from a couple of sources:

  - errors in the RTL - this is the most common

  - errors in your constraints (this assumes the design "meets timing")

  - clock crossing problems (which are generally a combination of the above two)

 

For the first one, you simply have to debug it. Use simulation, ILAs, add extra test conditions - do "classical" debugging.

 

For clock crossing circuits, make sure that all paths between domains that do not originate from the same MMCM/PLL have proper clock domain crossing circuits. Make sure that these have the ASYNC_REG property set properly. Verify the results of the report_cdc command.

 

For constraints, first of all, make sure that your design meets timing! Assuming it does, make sure your constraints are "pristine". Follow the Design Methodology Guidelines for creating your constraints, but

   - create clocks for all clock ports

     - clocks should all have the proper frequency and jitter set on them

   - have proper input and output constraints

     - the constraints should be derived from the specifications of the devices connected to the board

   - have proper constraints (exceptions) on all paths that go between clocks that do not originate in the same MMCM/PLL

      - make sure the constraints are appropriate for the clock domain crossing circuit being used

        - do not use the set_clock_groups command or set_false_paths between clock domains unless you really really really know this is the correct thing to do (almost never)

      - make sure you have not missed accidental paths between clocks

        - study the clock interaction report carefully

     - if you have any multicycle paths...

        - get rid of them if you can (pipelining is usually better than using multicycle paths)

        - make sure your set_multicycle_path commands don't affect paths that are not actually multicycle

    - make sure that all paths are covered

        - check the results of the "Check Timing" report

 

Good luck!

 

Avrum

5 Replies
Highlighted
Historian
Historian
5,520 Views
Registered: ‎01-23-2009

Re: Simulated Results different from Implemented Results

Jump to solution

I can't help you with the specifics of your problem, but maybe I can rule out a couple of things...

 

99.999% of the time it is not a bug in the tools. While bugs do occasionally happen in the tools, they are very rare... You also do not need to prevent the tools from removing something with KEEP or DONT_TOUCH - the bugs that people often claim these "fix" are usually really just RTL bugs.

 

Most of the time, the problems come from a couple of sources:

  - errors in the RTL - this is the most common

  - errors in your constraints (this assumes the design "meets timing")

  - clock crossing problems (which are generally a combination of the above two)

 

For the first one, you simply have to debug it. Use simulation, ILAs, add extra test conditions - do "classical" debugging.

 

For clock crossing circuits, make sure that all paths between domains that do not originate from the same MMCM/PLL have proper clock domain crossing circuits. Make sure that these have the ASYNC_REG property set properly. Verify the results of the report_cdc command.

 

For constraints, first of all, make sure that your design meets timing! Assuming it does, make sure your constraints are "pristine". Follow the Design Methodology Guidelines for creating your constraints, but

   - create clocks for all clock ports

     - clocks should all have the proper frequency and jitter set on them

   - have proper input and output constraints

     - the constraints should be derived from the specifications of the devices connected to the board

   - have proper constraints (exceptions) on all paths that go between clocks that do not originate in the same MMCM/PLL

      - make sure the constraints are appropriate for the clock domain crossing circuit being used

        - do not use the set_clock_groups command or set_false_paths between clock domains unless you really really really know this is the correct thing to do (almost never)

      - make sure you have not missed accidental paths between clocks

        - study the clock interaction report carefully

     - if you have any multicycle paths...

        - get rid of them if you can (pipelining is usually better than using multicycle paths)

        - make sure your set_multicycle_path commands don't affect paths that are not actually multicycle

    - make sure that all paths are covered

        - check the results of the "Check Timing" report

 

Good luck!

 

Avrum

Observer chanyeoh
Observer
2,938 Views
Registered: ‎03-11-2016

Re: Simulated Results different from Implemented Results

Jump to solution

Hi,

So I noticed that while synthesizing, the program is removing some of my essential signals. I suspect that this is an RTL bug. I suspect that I have to redesign my hardware, but do you mind explaining more of what an RTL bug is?

 

As in, how does the KEEP or DONT_TOUCH help to "fix" the RTL bugs. This is the part, which I am not so clear about. Your post did help me in finding errors in my design. Thanks!

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
2,925 Views
Registered: ‎10-24-2013

Re: Simulated Results different from Implemented Results

Jump to solution

Hi @chanyeoh

 

These attributes prevent logic optimization of either signals or hierarchical blocks and forward annotate the netlist to place and route.

Refer to the below document (Chapter-2) for more details on these attributes.

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug901-vivado-synthesis.pdf

Thanks,Vijay
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Historian
Historian
2,916 Views
Registered: ‎01-23-2009

Re: Simulated Results different from Implemented Results

Jump to solution

So I noticed that while synthesizing, the program is removing some of my essential signals. I suspect that this is an RTL bug. I suspect that I have to redesign my hardware, but do you mind explaining more of what an RTL bug is?

 

Sorry - I was being imprecise. RTL (Register Transfer Language) is the coding style that we use to implement digital designs using an HDL (Verilog, SystemVerilog, VHDL...). Saying "RTL" used to be synonymous with "your design". But now, with IP and IP integrator, a design may have little or no actual RTL.

 

So when I said an RTL bug, I meant a design bug - something about the design you described (via RTL or IP integrator) is incorrect. If the synthesis tool is removing logic, it is because there is something wrong with it - the tool has identified that the logic is useless. This can be because

  - an input is tied to a constant or left floating that prevents the design from doing anything

  - the output of the design doesn't "do anything" - it does not go anywhere (is left unconnected) or has no effect on any logic it is driving (for example the block it is driving is held in reset)

  - there is a logical error that prevents the design from doing anything useful

 

The best way to find these is to simulate your design before synthesis - these types of error tend to be pretty obvious during simulation - large sections of the design have signals that do not change value or go to the unknown state.

 

Trying to get the synthesis tool to keep logic using KEEP or DONT_TOUCH commands is a waste of time - even if you do manage to get the tool to keep the logic, it will still be useless (otherwise the tools wouldn't have removed them in the first place). You must find the logical bug and fix it. To be clear, KEEP and DONT_TOUCH to not fix bugs.

 

Avrum

0 Kudos
Scholar drjohnsmith
Scholar
2,900 Views
Registered: ‎07-09-2009

Re: Simulated Results different from Implemented Results

Jump to solution

agree with avrumw, keep and dont touch are NOT ways to fix bugs. 

 

If you know parts are being removed the tools think they are not needed,

 your either not driving the block or the outputs are not connected, and logic is being removed as it can not be toggled.

 

Differences like this used to be because of things like sensitivity lists being in error and you had not simulated the condition to see this.

 

0 Kudos