ISE 9.2.03i problem

[jtw]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com...

On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net
wrote:

On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:

But here's my worry: What if XST is actually right; and Quartus is one
step behind the pack in its optimisation technology (generating correct
but sub-optimal results)?


As always (and I'm assuming that Mark has already done this), you
always run the simulator first to make sure that the design is
functionally correct. Optimization that changes the observable
function is incorrect optimization.

OK, you're right. As long as the simulation test coverage is adequate, I
was spouting nonsense there.

- Brian

Just be aware that there are occasions where the simulation can be
incorrect; just the other day, I was modifying a [non-clocked] process, but
forgot to add a key signal to the sensitivity list. So, simulation was
'incorrect'--at least, undesired--and synthesis would have produced the
desired behavior. (In this case, it was in the test bench, so synthesis
would have been immaterial.)

I found and corrected it quickly, and there is a compiler option to warn
about synthesis mismatch, but still.... It is possible to have simulation
wrong and synthesis correct, as well as vice-versa.

JTW

 

On Nov 1, 11:13 pm, "jtw" <wrigh...@hotmail.invalid> wrote:

"Brian Drummond" <brian_drumm...@btconnect.com> wrote in message

news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com...



On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjenni...@sbcglobal.net
wrote:

On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:

But here's my worry: What if XST is actually right; and Quartus is one
step behind the pack in its optimisation technology (generating correct
but sub-optimal results)?

As always (and I'm assuming that Mark has already done this), you
always run the simulator first to make sure that the design is
functionally correct.  Optimization that changes the observable
function is incorrect optimization.

OK, you're right. As long as the simulation test coverage is adequate, I
was spouting nonsense there.

- Brian

Just be aware that there are occasions where the simulation can be
incorrect; just the other day, I was modifying a [non-clocked] process, but
forgot to add a key signal to the sensitivity list.  So, simulation was
'incorrect'--at least, undesired--and synthesis would have produced the
desired behavior.  (In this case, it was in the test bench, so synthesis
would have been immaterial.)

I found and corrected it quickly, and there is a compiler option to warn
about synthesis mismatch, but still....  It is possible to have simulation
wrong and synthesis correct, as well as vice-versa.

JTW

Two wrongs don't make a right. Wrong #1: describe the wrong logic
(according to well defined, intentioned language semantics) by
accidentally mis-typing the sensitivity list, then (wrong #2) claim
that the synthesis tool ought to be ignoring the semantics of the
language. While this would certainly not be the first time this has
occurred (and I've probably been bitten by it, too), it's not really
accurate to say "simulation is incorrect".

- Kenn

 

[Brian Drummond]

On Sat, 1 Nov 2008 20:13:33 -0700, "jtw" <wrightjt@hotmail.invalid>
wrote:

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:l2fng4dijrggr9mkr70mtllq94s1g5n1vl@4ax.com...
On Fri, 31 Oct 2008 08:06:50 -0700 (PDT), KJ <kkjennings@sbcglobal.net
wrote:

On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:

But here's my worry: What if XST is actually right; and Quartus is one
step behind the pack in its optimisation technology (generating correct
but sub-optimal results)?

As always (and I'm assuming that Mark has already done this), you
always run the simulator first to make sure that the design is
functionally correct. Optimization that changes the observable
function is incorrect optimization.

OK, you're right. As long as the simulation test coverage is adequate, I
was spouting nonsense there.

Just be aware that there are occasions where the simulation can be
incorrect; just the other day, I was modifying a [non-clocked] process, but
forgot to add a key signal to the sensitivity list.

That's a good example of what I meant by "inadequate" test coverage; the
simulator was accurately performing what you described; just not what
you meant to describe!

- Brian

 

[Mark McDougall]

Brian Drummond wrote:

I suspect something obscure in the logic you didn't post is causing it
to be simplified; therefore the other block appears redundant.

The code in question is a video controller, and the offending
variable/signal is simply a pipeline delay for one of the signals. In
fact, the controller has a number of pipeline delays and it would appear
that a *pair* of them were being (incorrectly) optimised out.

Anyway, I'm not going to defiantly claim there is definitely nothing wrong
with my code, so I'll endeavour to put together a small sample project and
see if I can't reproduce the problem.

And in answer to other threads, the code simulates correctly, and works
exactly as expected on Altera silicon. There's really nothing complicated
in this scenario, believe me - a couple of counters and some pipeline
shift registers.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

 

[Brian Drummond]

On Tue, 04 Nov 2008 10:38:36 +1100, Mark McDougall <markm@vl.com.au>
wrote:

Brian Drummond wrote:

I suspect something obscure in the logic you didn't post is causing it
to be simplified; therefore the other block appears redundant.

The code in question is a video controller, and the offending
variable/signal is simply a pipeline delay for one of the signals. In
fact, the controller has a number of pipeline delays and it would appear
that a *pair* of them were being (incorrectly) optimised out.

aaah...

Anyway, I'm not going to defiantly claim there is definitely nothing wrong
with my code, so I'll endeavour to put together a small sample project and
see if I can't reproduce the problem.

.... and I have seen *some* evidence that there *may* be a problem with
pipeline delays implemented as variables (actually a variable array, to
easily control the length); or the transition between signals and such
delays. About a year ago, on XST 7.1.

It manifested as a cycle difference between the length of the pipeline
in simulation, and the same pipeline in practice.

I didn't have time to dig down properly and locate the problem; it's
still on the ToDo list. Hence the cautious language; I regard it as most
probably something dumb on my part unless I can clearly point to XST (as
with signals in procedures obeying variable assignment scheduling).

So despite the Doubting Thomases (e.g. me), there's no need to question
your own sanity. You might be on to something worth reporting.

- Brian

 

[Brian Davis]

Brian Drummond wrote:

... and I have seen *some* evidence that there *may* be a problem with
pipeline delays implemented as variables (actually a variable array, to
easily control the length); or the transition between signals and such
delays. About a year ago, on XST 7.1.

It manifested as a cycle difference between the length of the pipeline
in simulation, and the same pipeline in practice.

I saw a similar bug in XST 9.1 (fixed in 9.2), that would

drop (add?) a pipeline stage on inferred memories under certain
conditions. I never boiled this down to a testcase, as the problem
went away in XST 9.2, and I ended up using Synplify on that job
anyhow due to other problems with XST.

XST attempts to push extra register stages into the BRAM by
enabling the output pipeline register; under certain conditions,
XST would lose track of what it was doing, and wire up the BRAM
incorrectly. I saw this on a pipelined inferred ROM, where the
synthesized circuit was off by one cycle from the simulation.

I forget the exact details, but XST would either push the BRAM
address register input back one stage without enabling the BRAM
data pipeline register; or, enable the register but connect one
BRAM address port to the original address, the other to the
earlier address stage, and then wire the data up to the wrong
output port. ( Whichever one it was showed up clearly as a weird
connection to the BRAM in the schematic viewer. )

Brian

 

[Brian Drummond]

On Mon, 3 Nov 2008 18:47:47 -0800 (PST), Brian Davis <brimdavis@aol.com>
wrote:

Brian Drummond wrote:

... and I have seen *some* evidence that there *may* be a problem with
pipeline delays implemented as variables (actually a variable array, to
easily control the length); or the transition between signals and such
delays. About a year ago, on XST 7.1.

I saw a similar bug in XST 9.1 (fixed in 9.2), that would
drop (add?) a pipeline stage on inferred memories under certain
conditions.
XST attempts to push extra register stages into the BRAM by
enabling the output pipeline register; under certain conditions,
XST would lose track of what it was doing, and wire up the BRAM
incorrectly.

Interesting... possibly related, but not the exact same bug. BRAMS are
far too precious in this app for this purpose. But it may make a related
mistake with SRL16s.

- Brian

 

[Brian Drummond]

On Tue, 04 Nov 2008 01:42:02 +0000, Brian Drummond
<brian_drummond@btconnect.com> wrote:

... and I have seen *some* evidence that there *may* be a problem with
pipeline delays implemented as variables (actually a variable array, to
easily control the length); or the transition between signals and such
delays. About a year ago, on XST 7.1.

It manifested as a cycle difference between the length of the pipeline
in simulation, and the same pipeline in practice.

I didn't have time to dig down properly and locate the problem; it's
still on the ToDo list. Hence the cautious language; I regard it as most
probably something dumb on my part unless I can clearly point to XST (as
with signals in procedures obeying variable assignment scheduling).

Followup: the same code (fiddled to work on ISE 7.1) gave incorrect
results on 10.1. Undoing the fiddle (i.e. restoring to code which gave
correct results under simulation), 10.1 synthesis also gave correct
results.

My conclusion: it does look like incorrect synthesis from 7.1 (and
possibly other old XST versions) but it has clearly been fixed in 10.1,
so I believe any further effort on this case is a waste of time.

- Brian

 

[Mark McDougall]

Brian Drummond wrote:

My conclusion: it does look like incorrect synthesis from 7.1 (and
possibly other old XST versions) but it has clearly been fixed in 10.1,
so I believe any further effort on this case is a waste of time.

Interesting, thanks for the follow-up!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

 

[Brian Drummond]

On Thu, 13 Nov 2008 10:40:04 +1100, Mark McDougall <markm@vl.com.au>
wrote:

Brian Drummond wrote:

My conclusion: it does look like incorrect synthesis from 7.1 (and
possibly other old XST versions) but it has clearly been fixed in 10.1,
so I believe any further effort on this case is a waste of time.

Interesting, thanks for the follow-up!

Any further developments on your odd results?
For example, have you had a chance to try on 10.1, even Webpack?

- Brian

 

[Mark McDougall]

Brian Drummond wrote:

Any further developments on your odd results?
For example, have you had a chance to try on 10.1, even Webpack?

Not yet, no. I'm wholly involved in Altera development at work atm, so any
Xilinx stuff is "extra curricular activities". Yet to install v10...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266