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: 
Visitor mbk
Visitor
9,680 Views
Registered: ‎02-12-2011

[ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Hi,

 

1. What are the possible reasons that a post-route simulation may not match a beehvioural simulation?

I am using clock from dcm.

2. Is it sufficient to use timeperiod constraint on the board clock and have two constraints, generated automatically by the dcm, on the generated clock?

3. Does the timeperiod constraint cover register to register or all-synchronous aspects of the design? My design is synchronous, with synchronous reset, using only one clock edge in sensitivity list.

 

I have already posted the problem, I thought it was due to other issues, which has been addressed. However, the original problem still remains. I am re-posting with the actual problem, under the relevant title now.

 

Project archive is attached. The values of ledout[6:4] are different in post-route and behavioural. I've tried lowering the clock to 25MHz from DCM. But the issue is still there.

 

0 Kudos
23 Replies
Moderator
Moderator
9,629 Views
Registered: ‎02-16-2010

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

2. Is it sufficient to use timeperiod constraint on the board clock and have two constraints, generated automatically by the dcm, on the generated clock?
Yes.

3. Does the timeperiod constraint cover register to register or all-synchronous aspects of the design? My design is synchronous, with synchronous reset, using only one clock edge in sensitivity list.

time period constraint will cover register to register paths. What do you mean by all synchronous aspects of the design.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Professor
Professor
9,612 Views
Registered: ‎08-14-2007

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

1.  There are a lot of reasons why behavioral sim may not match post-route sim.  Have you checked if post translate sim matches behavioral?  If not, there could be issues in the source code descriptions, for example incomplete sensitivity lists.  If post-translate works OK, then the real difference will only be timing.

 

3.  Take a look at this post, and its simple diagram.  Period constraints do not cover paths going into or out of the device, so for example the clock to output time on an output signal could exceed the clock period without throwing a timing error.

-- Gabor
0 Kudos
Visitor mbk
Visitor
9,592 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

1. Post-translate also does not match behavioural. It matches post-route though. So yes, it has problem too.

 

2. Which constraint covers the in and out timings then?

0 Kudos
Visitor mbk
Visitor
9,590 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

If the LEDs are not outputing the correct value, shouldn't they do it in the next clock, if the value takes more delay than the period?

Also, shouldn't the value in the internal register be correct atleast? If its LEDed value is incorrect, its actual value should be correct, but it seems its not, as indicated by certain if-conditions.
0 Kudos
Professor
Professor
9,584 Views
Registered: ‎08-14-2007

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

1. Post-translate also does not match behavioural. It matches post-route though. So yes, it has problem too.

 

This seems to point to a coding problem which may have nothing to do with timing.  Post-translate simulation does not take timing into account, with the exception of some Xilinx primitives like DCMs PLLs and MMCMs.  There are also some Xilinx primitives that have small unit delays built into the simulation model.  It may even point to a testbench issue, if you have inputs changing simultaneously with the clock.

 

2. Which constraint covers the in and out timings then?

 

Input timing is covered by OFFSET IN BEFORE constraints, and output timing is covered by OFFSET OUT AFTER constraints.  You can easily build these constraints using the "Create Timing Constraints" wizard from the ISE GUI.

 

 

-- Gabor
Create_Timing_Constraints.PNG
0 Kudos
Visitor mbk
Visitor
9,548 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

1. My code does not really take any inputs. Its an output generating code. The addresses are generated internally to populate DDR. However, right now, its not even DDR part issue as I have stripped it out.

Is it wrong to have multiple registers act as "X" in: taskbuffer[X][valueB:valueA], so we have taskbuffer[taskcounter][96:94], taskbuffer[taskdispatchcounter][96:94], taskbuffer[taskiocounter][96:94], taskbuffer[taskrwcounter][99:97], taskbuffer[taskcounter][63:0] etc etc?

Could that be causing conflict? I think it shouldn't though.... or behavioural simulation should point out, else whats the use?

2. As far as incomplete sensitivity list is concerned. I always try to use (@posedge clk) (and sometimes (@negedge clk) alongwith). Moreover, my reset is synchronous to clock. Plus, all my statements are non-blocking. I design the state machine keeping one cycle delay into account where necessary.
0 Kudos
Visitor mbk
Visitor
9,514 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

I am coming from Mixed-signal background and working towards verifying IP on FPGA and moving to ASIC. Is it an FPGA specific issue that I am facing?

0 Kudos
Professor
Professor
9,509 Views
Registered: ‎08-14-2007

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch


@mbk wrote:

I am coming from Mixed-signal background and working towards verifying IP on FPGA and moving to ASIC. Is it an FPGA specific issue that I am facing?


It is possible.  One thing you get in Xilinx FPGAs is automatic initialization of all registers and memory cells during configuration.  In the simulation models, there is a "buried" signal called GSR (global set/reset) that asserts a secondary reset to the FPGA register and memory primitives for the first 100 ns of simulation time.  If you are trying to provide stimulus to the design before 100 ns have elapsed, then you will see differences in post-translate simulation where these models are used, vs. behavioral where the code does exactly what you coded.

 

I tried to run the simulation you posted in the first post of this thread, but ISIM crashes after several minutes:

 

WARNING: File "C:/Projects/junkola/delta_test1/testbench.v" Line 67.  For instance testbench/ddr_sim/, width 8 of formal port O_Blue is not equal to width 1 of actual signal O_DISP.
Time resolution is 1 ps
Simulator is doing circuit initialization process.
gf
 
36588^done,status="running",now="0"
(isim-gdb)
The simulator has terminated in an unexpected manner.  Please review the ISim log (isim.log) for details.

The simulation has terminated.
ISim>

 

The warning seems to indicate that your positional module port connections do not line up correctly.  For anything much bigger than gates I would not generally use positional port connection, just because it is not easy to keep track of.

-- Gabor
0 Kudos
Visitor mbk
Visitor
9,496 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Please run testbench1.v for Post-route and testbench.v for Behavioural simulation. Both are same, the port order was different in generated netlist(?) so I had to re-order the I/Os in testbench.

0 Kudos
Visitor mbk
Visitor
9,480 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

For global reset issue, it is unlikely, since FPGA implementation on hardware results in post-route simulation match. So if it were reset issue, it should've showed up in hardware. This is new, thank you for the information. I never experienced this issue. Does it mean, I should force the reset signal for 100ns+? But then, how? if my clock asserts reset, as its synchronous.
0 Kudos
Moderator
Moderator
9,474 Views
Registered: ‎07-01-2015

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Hi @mbk,

 

Please go through following link to get information regarding glbl
http://www.xilinx.com/support/answers/6537.html

 

Thanks,
Arpan

Thanks,
Arpan
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
Visitor mbk
Visitor
9,473 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

*I meant, it shouldn't have showed up in hardware, as hardware reset could be asserted for quite a while. One is global reset (main_rst) for PLL clock etc (main.v wrapper module), the other is rst signal (ddr_reset) used to reset module ddr2.v which contains all logic. So we can assert second reset whenever we want, and I tried it on hardware.
0 Kudos
Professor
Professor
9,455 Views
Registered: ‎08-14-2007

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch


@mbk wrote:

Please run testbench1.v for Post-route and testbench.v for Behavioural simulation. Both are same, the port order was different in generated netlist(?) so I had to re-order the I/Os in testbench.


This is yet another reason to use named ports.

 

I was running testbench.v in Behavioral mode when I got the issues I posted.

-- Gabor
0 Kudos
Visitor mbk
Visitor
9,447 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Yes, this bugged me the other day as well and I was planning to use ".()" notation. I ll re-write the ports part and post it again. Thank you for helping.

0 Kudos
Visitor mbk
Visitor
9,285 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Hello @gszakacs,

I was out of town and couldn't post back.

 

Here is the fixed code using named ports. Thank you once again for your time. I really appreciate.

0 Kudos
Visitor mbk
Visitor
9,155 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Guys, please help with this...

0 Kudos
Professor
Professor
9,150 Views
Registered: ‎08-14-2007

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

It seems there are still issues with the project you posted the second time.  I tried to run the behavioral sim, but ISIM just sat at time 0 and ran up to about 1 GB of memory usage, then wound down to about 108K and gave this error pop-up.

-- Gabor
Simulation_Terminated.PNG
0 Kudos
Visitor mbk
Visitor
9,127 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Thank you so much for following up @gszakacs.

Please close ISIM and retry. Sometimes it happens to me too. Perhaps memory runs out or some issue comes up. I just close ISIM, and reclick "Simulate" etc in ISE.

I rechecked, its working at my end.

0 Kudos
Professor
Professor
9,097 Views
Registered: ‎08-14-2007

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

I tried several times, but the behavioral sim crashed consistently.  I was able to run post-translate (with the other test bench), but without having a reference point, I don't know what might be different between the two runs.  Perhaps you can post some screen shots from each simulation showing the signals that don't behave the same after synthesis.

-- Gabor
0 Kudos
Visitor mbk
Visitor
7,895 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Does the log say anything? (I doubt that).

I am using ISE 14.7 (nt64).

ISIM 14.7 (nt64)

I am using the "lights" output for debugging. Please see the difference in values. See the case block on line 990 in ddr2.v. "lights" are known as "ledout" in ddr2.v

 

isim1.pngisim2.png

 

0 Kudos
Visitor mbk
Visitor
7,893 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

Picture 1 is Behavioural, other is post-route. Post-translate yields same result as post-route.

I was thinking of using another Verilog compiler. Not sure if its an FPGA-specific issue or something else, but its weird.
0 Kudos
Visitor mbk
Visitor
7,838 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

*sigh*

0 Kudos
Visitor mbk
Visitor
7,829 Views
Registered: ‎02-12-2011

Re: [ISE14.7 - Xilinx Spartan-6] Behavioural vs Post-route mismatch

This is the relevant portion. ledout[6:4] are supposed to light in both behavioural and post-translate+, but they only do so in behavioural.

 

Old code:

			4'b0001 : begin
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////************************** Code-C begins *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
						if (taskcounter == 4'b0000) begin
							ledout[3] <= 1;
							taskbuffer[taskcounter][96:94] <= 3'b111;
							taskcounter <= taskcounter + 1;
						end
						if (taskcounter == 1) begin
							ledout[2] <= 1;
							ledout[6:4] <= taskbuffer[0][96:94];
							taskcounter <= 2;
						end
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////**************************  Code-C ends  *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
						end

I changed some code. Turns out, if I comment out the line

//taskbuffer[taskcounter][98] <= 1;

then it seems to work in both behavioural and post-translate+. However, it does not work if I use "taskbuffer[taskcounter][99:98] <= 2'b11; (or 3'b111 as in old code). Also, it fails if I assign values to [99] and [98] in two non-blocking statements. (I had to comment out one statement for it to work).

 

New code:

			4'b0001 : begin
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////************************** Code-C begins *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
						if (taskcounter == 0) begin
							ledout[3] <= 1;
							taskbuffer[taskcounter][99] <= 1;
							//taskbuffer[taskcounter][98] <= 1;
							taskcounter <= taskcounter + 1;
						end
						if (taskcounter == 1) begin
							ledout[2] <= 1;
							ledout[6] <= taskbuffer[0][99];
							taskcounter <= 2;
						end
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////**************************  Code-C ends  *****************************\\\\\\\\\\\\\\\\\\\\\
/////////////////////////************************** ------------- *****************************\\\\\\\\\\\\\\\\\\\\\
                        end

Why is that????

 

0 Kudos