ISE 9.2.03i problem

M

Mark McDougall

Guest
Hi Xilinx gurus,


I've got some code which I've been running on Altera silcon for several
weeks now, used in a number of different projects, synthesized with
Quartus v8.

It's a simple shift register implemented using a variable in a clocked
process...

process (reset, clk, clk_ena)
variable hactive_v_r : std_logic_vector(3 downto 0) := (others => '0');
begin
if reset = '1' then
hactive_v_r := (others => '0');
elsif rising_edge(clk) and clk_ena = '1' then
...
hactive_v_r := hactive_v_r(hactive_v_r'left-1 downto 0) & hactive_s;
end if;
end process;

BTW 'h_active_s' is a signal declared in the containing entity, and is
definitely not optimised out.

However, when building the project for Xilix under ISE 9.2.03i, I get the
following warnings during synthesis:

WARNING:Xst:653 - Signal <hactive_v_r<3>> is used but never assigned. Tied
to value 0.
WARNING:Xst:1780 - Signal <hactive_v_r<2:0>> is never used or assigned.

As a result, the code doesn't work - the results suggest that this shift
register has indeed been removed from the design.

As I said, this module is used - exactly as-is, in its entirety, in
several Altera modules.

Any idea what my problem is???

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
 
Mark McDougall wrote:

Interesting - if I change the variables to signals, it works!

Bug?

--
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
 
On Oct 29, 10:45 am, Mark McDougall <ma...@vl.com.au> wrote:
Mark McDougall wrote:

Interesting - if I change the variables to signals, it works!

Bug?

--
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
Click to expand...
My understanding from VHDL point of view is that VARIABLES are visible
only inside process and since not assigned to signal it is optimised.
Is variable "hactive_v_r" being read some where else in code and are
you able to compile it? You should get compilation
error.
Sandeep
 
On Oct 29, 10:45 am, Mark McDougall <ma...@vl.com.au> wrote:
Mark McDougall wrote:

Interesting - if I change the variables to signals, it works!

Bug?

--
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
Click to expand...
My understanding is that VARIABLES are visible only inside the process
and hence getting optimised. Is the variable
"hactive_v_r" read/used in other part of code and are you able to
compile the code? You should get compilation error too.
--Sandeep
 
On Wed, 29 Oct 2008 13:24:46 +1100, Mark McDougall <markm@vl.com.au>
wrote:

Hi Xilinx gurus,


I've got some code which I've been running on Altera silcon for several
weeks now, used in a number of different projects, synthesized with
Quartus v8.

It's a simple shift register implemented using a variable in a clocked
process...

process (reset, clk, clk_ena)
variable hactive_v_r : std_logic_vector(3 downto 0) := (others => '0');
begin
if reset = '1' then
hactive_v_r := (others => '0');
elsif rising_edge(clk) and clk_ena = '1' then
...
hactive_v_r := hactive_v_r(hactive_v_r'left-1 downto 0) & hactive_s;
end if;
end process;

As I said, this module is used - exactly as-is, in its entirety, in
several Altera modules.

Any idea what my problem is???
Click to expand...
As written here, XST appears to be correct.

hactive_v_r is a variable, assigned as the last line of the process, and
not used anywhere in the process (except in assignment to itself). As a
variable local to the process, it has no visibility outside the process,
so XST may optimise it out.

There is something else going on, that you haven't shown us.

- Brian
 
Brian Drummond wrote:

There is something else going on, that you haven't shown us.
Click to expand...
Yeah, sorry, it is used elsewhere in the process in an 'if' statement, to
assign the value of a signal.

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
 
I've little experience with ISE & its idiosyncrasies, but I've since been
told that this type of problem isn't uncommon. Apparently it's a little
too aggressive with its optimisation where duplicate logic is removed...

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
 
Mark McDougall wrote:
I've little experience with ISE & its idiosyncrasies, but I've since been
told that this type of problem isn't uncommon. Apparently it's a little
too aggressive with its optimisation where duplicate logic is removed...
Click to expand...
Not sure who told you that, but I do that sort of thing all the time
with variables in ISE 9.2, and have never had a bit of trouble. If you
want to see a program that is extremely aggressive about finding and
removing duplicate logic, try out Synplify sometime. But removing
duplicate logic is a good thing, not bad.

About the only difference in the way I code things is that I always put
the clock enable within the clocked part of the process, and never in
the sensitivity list (a clock enable should not be put there anyway).
 
process (reset, clk, clk_ena)
  variable hactive_v_r  : std_logic_vector(3 downto 0) := (others => '0');
begin
  if reset = '1' then
    hactive_v_r := (others => '0');
  elsif rising_edge(clk) and clk_ena = '1' then
    ...
    hactive_v_r := hactive_v_r(hactive_v_r'left-1 downto 0) & hactive_s;
  end if;
end process;

BTW 'h_active_s' is a signal declared in the containing entity, and is
definitely not optimised out.

However, when building the project for Xilix under ISE 9.2.03i, I get the
following warnings during synthesis:

WARNING:Xst:653 - Signal <hactive_v_r<3>> is used but never assigned. Tied
to value 0.
WARNING:Xst:1780 - Signal <hactive_v_r<2:0>> is never used or assigned.
Click to expand...
Could it be that you have a signal declared which has the same name as
the variable? Does anyone know if XST still warns that a signal is
being removed, even if it's actually a variable?

If there were a signal by the same name which is being optimized away,
maybe XST gets confused and gets rid of both.

Dave
 
Duane Clark wrote:

But removing
duplicate logic is a good thing, not bad.
Click to expand...
Agreed, but I've been told that the problem lies with duplicate logic and
further optimisation that reveals that *one* of the "duplicated" logic
blocks turns out to be ultimately unused - the optimiser then removes the
"duplicated" logic and the *other* block, which *is* required, gets lost...

Not speaking from and ISE experience myself, I'd guess that the order of
optimisations gets a little screwed... or at least side effects aren't
properly analysed.

In any case, I'm assured that turning *OFF* all optimisations results in
correctly-functioning code.

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
 
kennheinrich@sympatico.ca wrote:

Without the full details of the rest of your code, I took an educated
guess and made up some logic (foo). I tried out the following design
in ISE 9.1.02i and it created some nontrivial logic for hactive_v_r(3
downto 0), after synthesis (only, into the default xcv5vlx50 device)
and a glance at the RTL viewer.
Click to expand...
I suspect that the problem requires more of my code to be included - the
process itself is rather larger than my snippet in the posting...

Try as I might, I can't see anything wrong with it myself, and the fact
that (1) changing to signals works and (2) quartus works (with the
original code) I still cling to my belief that it's an ISE bug...

(1) why do you have clk_ena in the sensitivity list? Here in the
Castle Anthrax there's only one punishment for random, desparate-
looking sensitivity lists :)
Click to expand...
Noted! I probably picked up that habit long ago when first starting out
and never gave it a second thought... you've just made a difference to
someone - take the rest of the day off! :)

(2) the question has often arisen here, as to why std_logic_arith and
std_logic_unsigned keep rearing their ugly heads in otherwise well-
intentioned code. One answer appeared when I (despite my better
instincts, and due to sheer laziness) used that damn-fool Xilinx
design entry wizard to create the top level shown below. "If Xilinx
does it, it must be right!", right?
Click to expand...
Coincidently, I've just spent a few days going through my entire code base
and removing all references to std_logic_arith. The most painful by far
was my copious use of EXT(), which is now replaced with a much more
cumbersome and less-flexible use of RESIZE(). :( It's something I've been
putting off but every time I read a post on the subject I felt another
pang of guilt! ;)

Thanks for your comments!

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
 
On Oct 29, 7:35 pm, Mark McDougall <ma...@vl.com.au> wrote:
I've little experience with ISE & its idiosyncrasies, but I've since been
told that this type of problem isn't uncommon. Apparently it's a little
too aggressive with its optimisation where duplicate logic is removed...

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
Click to expand...
I would also expect this to create flops, exactly as you seem to want.
Without the full details of the rest of your code, I took an educated
guess and made up some logic (foo). I tried out the following design
in ISE 9.1.02i and it created some nontrivial logic for hactive_v_r(3
downto 0), after synthesis (only, into the default xcv5vlx50 device)
and a glance at the RTL viewer.

Two other tangential thoughts crossed my mind as well:

(1) why do you have clk_ena in the sensitivity list? Here in the
Castle Anthrax there's only one punishment for random, desparate-
looking sensitivity lists :)

(2) the question has often arisen here, as to why std_logic_arith and
std_logic_unsigned keep rearing their ugly heads in otherwise well-
intentioned code. One answer appeared when I (despite my better
instincts, and due to sheer laziness) used that damn-fool Xilinx
design entry wizard to create the top level shown below. "If Xilinx
does it, it must be right!", right?

Cheers, new Bruce.

- Kenn

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity fidget is
Port ( reset : in STD_LOGIC;
clk : in STD_LOGIC;
clk_ena : in STD_LOGIC;
hactive_input : in STD_LOGIC;
foo_output : out STD_LOGIC);
end fidget;

architecture Behavioral of fidget is
signal foo : std_logic;
signal hactive_s : std_logic;
begin
hactive_s <= hactive_input;
foo_output <= foo;

process (reset, clk, clk_ena)
variable hactive_v_r : std_logic_vector(3 downto 0) := (others =>
'0');
begin
if reset = '1' then
hactive_v_r := (others => '0');
elsif rising_edge(clk) and clk_ena = '1' then
if hactive_v_r = "0000" then
foo <= not foo;
end if;

hactive_v_r := hactive_v_r(hactive_v_r'left-1 downto 0) &
hactive_s;
end if;
end process;

end Behavioral;
 
Dave wrote:

Could it be that you have a signal declared which has the same name as
the variable?
Click to expand...
No, sorry.

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
 
"Mark McDougall" <markm@vl.com.au> wrote in message
news:490a52fa$1@dnews.tpgi.com.au...
kennheinrich@sympatico.ca wrote:

Try as I might, I can't see anything wrong with it myself, and the fact
that (1) changing to signals works and (2) quartus works (with the
original code) I still cling to my belief that it's an ISE bug...
Click to expand...
You've submitted this as a bug to the good folks at Xilinx, correct? It
doesn't help you with the tool this time around, but eventually it gets
fixed (if the submitters persist) or you move on to other tools, other
suppliers.

KJ
 
On Fri, 31 Oct 2008 11:26:32 +1100, Mark McDougall <markm@vl.com.au>
wrote:

Duane Clark wrote:

But removing
duplicate logic is a good thing, not bad.
Click to expand...
Usually...

One case where removing duplicate logic IS harmful: when a registered
signal is used internally, and also presented on output pins. XST will
try to share the register, while you want to duplicate it to push
registers into the output blocks for better I/O timing.

You can turn "equivalent-register-removal" off globally with a flag, or
for individual signals by attaching an attribute. Or you can "keep"
signals which would otherwise be optimised away, with a "keep" atribute.
Use sparingly; they will probably be harmlessly ignored by other tools,
but don't really help portability.

Agreed, but I've been told that the problem lies with duplicate logic and
further optimisation that reveals that *one* of the "duplicated" logic
blocks turns out to be ultimately unused - the optimiser then removes the
"duplicated" logic and the *other* block, which *is* required, gets lost...
Click to expand...
If the other block really was required (as in, it was connected to an
output or other logic (crucially; other logic which cannot itself be
deleted!) it would have been kept.

Though I have flamed XST , it is actually quite difficult to catch it
out in real synthesis bugs and I don't believe you have here. (The one
time I caught it creating incorrect logic, it got variables right, but
not signals, when signals were modified within a procedure. In-lining
the procedure calls in the main process gave correct results. Xilinx
have acknowledged this bug and a change request has been filed. They
really do want it to work right!)

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

In any case, I'm assured that turning *OFF* all optimisations results in
correctly-functioning code.
Click to expand...
This may be expedient, but feels like glossing over the problem, which
can re-appear later when something else changes.

It may be worth simplifying the failing case to post here.

Either you will see the problem in the process; or someone here may see
it. Or, if you really have caught XST out, then you have a test case to
attach to a Webcase reporting the bug.

- Brian
 
On Fri, 31 Oct 2008 11:36:05 +1100, Mark McDougall <markm@vl.com.au>
wrote:

Try as I might, I can't see anything wrong with it myself, and the fact
that (1) changing to signals works and (2) quartus works (with the
original code) I still cling to my belief that it's an ISE bug...
Click to expand...
(Note: I haven't used Quartus; I may be doing it an injustice here)

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

And the next revision of Quartus improves its optimisation algorithms...

- Brian
 
On Oct 30, 9:47 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
"Mark McDougall" <ma...@vl.com.au> wrote in message

news:490a52fa$1@dnews.tpgi.com.au...

kennheinr...@sympatico.ca wrote:

Try as I might, I can't see anything wrong with it myself, and the fact
that (1) changing to signals works and (2) quartus works (with the
original code) I still cling to my belief that it's an ISE bug...

You've submitted this as a bug to the good folks at Xilinx, correct?  It
doesn't help you with the tool this time around, but eventually it gets
fixed (if the submitters persist) or you move on to other tools, other
suppliers.

KJ
Click to expand...
I think there might be a mis-attribution here: it was Mark, not I, who
clings to his belief.

But more topically, Brian Drummond suggested in another post that
there could be other stuff happening in other logic that causes the
optimization to occur. If the code can be simplified to the point
where it can be posted here and still show the bug, I will be happy to
try it out on my version of ISE (and if motivated, even try out
another synthesizer). If there's a real tool bug lurking here, let's
kick it back the the vendor.

- Kenn
 
On Oct 31, 10:00 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
On Fri, 31 Oct 2008 11:36:05 +1100, Mark McDougall <ma...@vl.com.au
wrote:

Try as I might, I can't see anything wrong with it myself, and the fact
that (1) changing to signals works and (2) quartus works (with the
original code) I still cling to my belief that it's an ISE bug...

(Note: I haven't used Quartus; I may be doing it an injustice here)

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)?
Click to expand...
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.

Kevin Jennings
 
KJ wrote:

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.
Click to expand...
Yes. It is not the job of synthesis to guess
the cases where I don't want register sharing or duplication.
If the netlist sims correctly, synthesis is correct.

To get a register to duplicate or not share as
I wish, I have to describe the requirement
as a device constraint, or change my logical description
to rule out the unwanted register usage.

For example, if I want to avoid sharing of the
second register in a synchronizer, I could
either make an explicit device-specific constraint,
or add a third flop to the synchronizer.

-- Mike
 
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.
Click to expand...
OK, you're right. As long as the simulation test coverage is adequate, I
was spouting nonsense there.

- Brian
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top