Prev: bit vs std_logic (was Re: Simulation of VHDL code for a vending machine)
Next: spam this guy, please
From: rickman on 21 Jan 2010 15:11
I am using Synplify Pro that came with Lattice ispLever and I am
getting the following warning message...

Initial value is not supported on state machine TTSuperCnt

It points to the line starting the async reset section in the process
defining the above signal. There is nothing wrong with the code I've
written... at least nothing I haven't seen in any number of years
using boiler plate case statement code for a signal like this
(unsigned (2 downto 0)). Synplify says that this signal is a state
machine of 3 states and I am trying to initialize it to one of the
states it has detected.

I'm wondering if Synplify, on deciding this is a state machine, treats
the state assignments as it's "property" and does not want me to
assign it at startup. But that makes no sense. I guess since it is a
warning, perhaps it is ok to ignore, but I'm not sure if it is
assigning an initial value or not??? It gives the same warning for
several signals in several modules.

Is anyone more familiar with this warning?

Rick
From: rickman on 21 Jan 2010 15:28
On Jan 21, 3:11 pm, rickman <gnu...(a)gmail.com> wrote:
> I am using Synplify Pro that came with Lattice ispLever and I am
> getting the following warning message...
>
> Initial value is not supported on state machine TTSuperCnt
>
> It points to the line starting the async reset section in the process
> defining the above signal.  There is nothing wrong with the code I've
> written... at least nothing I haven't seen in any number of years
> using boiler plate case statement code for a signal like this
> (unsigned (2 downto 0)).  Synplify says that this signal is a state
> machine of 3 states and I am trying to initialize it to one of the
> states it has detected.
>
> I'm wondering if Synplify, on deciding this is a state machine, treats
> the state assignments as it's "property" and does not want me to
> assign it at startup.  But that makes no sense.  I guess since it is a
> warning, perhaps it is ok to ignore, but I'm not sure if it is
> assigning an initial value or not???  It gives the same warning for
> several signals in several modules.
>
> Is anyone more familiar with this warning?
>
> Rick

Here is a clue... A similar signal that is defined as an enumerated
type is also detected as a state machine, but does not get the
initialization warning. It is being initialized to one of the
enumerated values. So perhaps any state machine it detects is treated
as an enumerated type and the tool is not bright enough to translate
the initialization value to one of the enumerated states. But if you
define it as an enumerated type, the initial value doesn't give
heartburn.

Rick
From: rickman on 21 Jan 2010 16:52
I guess I never looked to closely at how Synplify handles state
machines. I found another one that is just a three bit counter that
is controlling a sine wave table lookup. I set it up in a case
statement to count 0 up to 3 then 7 down to 4. This lets me look at
just the two lsbs for the table index since the table is used twice
for one cycle of the sine wave. But Synplify has "optimized" the
counter to a 1-hot counter of 8 bits!

Hmmm... I guess as I think about it a bit, a given state of a 1-hot
counter is deocded by looking at one bit. Since each value from the
table is used in two positions of the cycle, it still only depends on
two input bits. Since the 1-hot register uses no LUTs, perhaps this
is a slightly more efficient implementation. I wouldn't have thought
of that on my own. Have we reached the point where HDL tools are
smarter than the designers??? It would explain a lot of the seemingly
dumb stuff I see come out of the tools. It would mean I am just not
smart enough to understand the impact of the code I am writing and the
tool is producing the best it can given my lousy code! Geeze, I hope
that's not the case!!! If it is, I think I need to retire.

Rick
From: John_H on 21 Jan 2010 22:43
On Jan 21, 4:52 pm, rickman <gnu...(a)gmail.com> wrote:
> I guess I never looked to closely at how Synplify handles state
> machines.  I found another one that is just a three bit counter that
> is controlling a sine wave table lookup.  I set it up in a case
> statement to count 0 up to 3 then 7 down to 4.  This lets me look at
> just the two lsbs for the table index since the table is used twice
> for one cycle of the sine wave.  But Synplify has "optimized" the
> counter to a 1-hot counter of 8 bits!
>
> Hmmm... I guess as I think about it a bit, a given state of a 1-hot
> counter is deocded by looking at one bit.  Since each value from the
> table is used in two positions of the cycle, it still only depends on
> two input bits.  Since the 1-hot register uses no LUTs, perhaps this
> is a slightly more efficient implementation.  I wouldn't have thought
> of that on my own.  Have we reached the point where HDL tools are
> smarter than the designers???  It would explain a lot of the seemingly
> dumb stuff I see come out of the tools.  It would mean I am just not
> smart enough to understand the impact of the code I am writing and the
> tool is producing the best it can given my lousy code!  Geeze, I hope
> that's not the case!!!  If it is, I think I need to retire.
>
> Rick

There are a few things the synthesizer will try to do to keep the
designer from having to be too smart. State machines are a biggie but
you'll also find memory inferences and removal of replicated logic
never seem to follow with the original design intention.

There's almost as much time spent keeping the compiler from doing
things as there is trying to cajole the tool into producing the output
that's *obvious* to the designer!

When the synthesizer is designed to produce good results for even the
poorest code, the better code sometimes suffers. If the compiler
didn't try to do things different than you expect, that would indicate
you write poor code. You don't so it does. At least until you learn
how to push the rope more easily.

The tools shouldn't present a challenge when compared to the
algorithms and implementation. But they do. Know you're not alone.

- John_H
From: Martin Thompson on 22 Jan 2010 05:21

Hi John,

John_H <newsgroup(a)johnhandwork.com> writes:

> When the synthesizer is designed to produce good results for even the
> poorest code, the better code sometimes suffers. If the compiler
> didn't try to do things different than you expect, that would indicate
> you write poor code. You don't so it does. At least until you learn
> how to push the rope more easily.

For what definition of "poor" - do you mean code that would have been
sub-optimal in terms of frequency or LUT usage *in the past*?

"Poor" and "Better" (in my book) are about readability,
maintainability and debuggability. Usually that is in direct
opposition to clever synthesis tricks. So if I can write readable
code and the synthesiser does a good job on my "poor" code, then I
regard that as a win!

Or did I misunderstand your comment?

>
> The tools shouldn't present a challenge when compared to the
> algorithms and implementation. But they do. Know you're not alone.
>

Personally, I'm impressed that I can write a simple description of my
logic and get a complicated near-optimal synthesis result out in a
large number of cases - I wonder if I'm alone? :)

Cheers,
Martin

--
martin.j.thompson(a)trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
 |  Next  |  Last
Pages: 1 2
Prev: bit vs std_logic (was Re: Simulation of VHDL code for a vending machine)
Next: spam this guy, please