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

On Jan 21, 3:11=A0pm, rickman
<gnu...@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. =A0There 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)). =A0Synplify 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. =A0But that makes no sense. =A0I 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??? =A0It 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

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

On Jan 21, 4:52=A0pm, rickman
<gnu...@gmail.com> wrote:
> I guess I never looked to closely at how Synplify handles state
> machines. =A0I found another one that is just a three bit counter that
> is controlling a sine wave table lookup. =A0I set it up in a case
> statement to count 0 up to 3 then 7 down to 4. =A0This 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. =A0But 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. =A0Since each value from the
> table is used in two positions of the cycle, it still only depends on
> two input bits. =A0Since the 1-hot register uses no LUTs, perhaps this
> is a slightly more efficient implementation. =A0I wouldn't have thought
> of that on my own. =A0Have we reached the point where HDL tools are
> smarter than the designers??? =A0It would explain a lot of the seemingly
> dumb stuff I see come out of the tools. =A0It 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! =A0Geeze, I hope
> that's not the case!!! =A0If 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

Hi John,

John_H <n...@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

-- 
m...@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Jan 22, 5:21=A0am, Martin Thompson
<martin.j.thomp...@trw.com> wrote:
>
> 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. =A0Usually that is in direct
> opposition to clever synthesis tricks. =A0So if I can write readable
> code and the synthesizer does a good job on my "poor" code, then I
> regard that as a win!
>
> Or did I misunderstand your comment?

Your definition of "better" fits pretty well but there's a little more
to it.  When there's little consideration made for how the hardware
behaves with the Verilog tossed towards it, even very readable code
can be a problem.  Memory inferences want a properly clocked and
enabled assignment for a single memory write and proper references for
the memory reads; registers on the read address and/or read values are
critical for proper implementation in a given target hardware.  Flip-
flops like single edges and usually either asynchronous set/reset
controls or synchronous versions, not a mix (though a mix can be
supported by pushing the synchronous controls behind LUTs into the
logic).

It's people who have never designed to the hardware level either with
old TTL chips or coded with a dog-eared, printed copy of an FPGA
architecture chapter that can produce something that looks okay from a
software viewpoint - even readable - but will cause problems in clean
synthesis.

Clever synthesis tricks can be read, maintained, and debugged with
ease when done well.  Clever tricks not done well can be "poor" code,
indeed.


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

A "simple description" in my book is one that's clean relative to the
hardware.  When I see code that's trying to use dual-clocked
registers, case statements with (unintended) unpopulated states,
unintended combinatorial latches, abuses of asynchronous data
transfers or ugly workarounds to match pipelining, things get tough
for compilers.  But they usually still produce results.

Clean, readable code designed to favor using a heavily loaded signal
as close to the register as possible too often ends up with several
levels of LUTs in the critical path despite synthesis timing
constraints designed to keep those paths short.  Synthesizers decide
to do things different than the implied coding intent because they're
smarter.  Really?  Too often I've had to manually piece-up a logic
cone so the critical paths do what they should have from the beginning.

Martin Thompson wrote:

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

I agree.
If it sims and meets timing I'm usually done.
But then, I don't need that last LUT and that last nS.

     -- Mike Treseler

John_H <n...@johnhandwork.com>
writes:

> On Jan 22, 5:21 am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>
> Your definition of "better" fits pretty well but there's a little more
> to it.  When there's little consideration made for how the hardware
> behaves with the Verilog tossed towards it, even very readable code
> can be a problem.  Memory inferences want a properly clocked and
> enabled assignment for a single memory write and proper references for
> the memory reads; registers on the read address and/or read values are
> critical for proper implementation in a given target hardware.  Flip-
> flops like single edges and usually either asynchronous set/reset
> controls or synchronous versions, not a mix (though a mix can be
> supported by pushing the synchronous controls behind LUTs into the
> logic).
>
> It's people who have never designed to the hardware level either with
> old TTL chips or coded with a dog-eared, printed copy of an FPGA
> architecture chapter that can produce something that looks okay from a
> software viewpoint - even readable - but will cause problems in clean
> synthesis.
>


Agreed - that's a description I can go with... you have to give the
synth a fighting chance.  "Poor code" can also include describing
behaviour that really doesn't match what you have available.  A bit
like using floating-point code on a fixed-point processor and not
understanding the FP library shenanegins that's going to have to
support you.

Heh - when I look back to my early days VHDLing I use to forget it was
going to end up as hardware - and I used to solder 4000 series CMOS in
my bedroom as a teenager :)  So, yes, code like that

> Clever synthesis tricks can be read, maintained, and debugged with
> ease when done well.  Clever tricks not done well can be "poor" code,
> indeed.
>

Agreed!

>
>> 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? :)
>
> A "simple description" in my book is one that's clean relative to the
> hardware.  When I see code that's trying to use dual-clocked
> registers, case statements with (unintended) unpopulated states,
> unintended combinatorial latches, abuses of asynchronous data
> transfers or ugly workarounds to match pipelining, things get tough
> for compilers.  But they usually still produce results.
>

Yes, I had not interpreted your "poor code" to cover that sort of
thing at all, but I can entirely see your point there.

> Clean, readable code designed to favor using a heavily loaded signal
> as close to the register as possible too often ends up with several
> levels of LUTs in the critical path despite synthesis timing
> constraints designed to keep those paths short.  Synthesizers decide
> to do things different than the implied coding intent because they're
> smarter.  Really?  Too often I've had to manually piece-up a logic
> cone so the critical paths do what they should have from the beginning.

Maybe I've got luckier there then :)  Apart from that it sounds like
we don't differ as wildly as I implied, sorry!

Cheers,
Martin

-- 
m...@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Jan 22, 11:19=A0am, Mike Treseler
<mtrese...@gmail.com> wrote:
> Martin Thompson wrote:
> > 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? :)
>
> I agree.
> If it sims and meets timing I'm usually done.
> But then, I don't need that last LUT and that last nS.
>
> =A0 =A0 =A0-- Mike Treseler

I think the most common problem when designers try to be smarter than
their synthesizer is that they don't let the synthesizer try it first;
they just assume that they have to code this up-then-down count
sequence to get an acceptable implementation.

I'm as guilty of this as most, but I'm getting better at it. The tools
keep getting better (often faster than I'm getting better!), so I
continually have to recalibrate my estimate of when I will need to get
more creative.

In practice, this usually means that I (should) first write a fairly
straight forward behavioral (cycle accurate) description of what I
want, along with the testbench, which is often easier to debug with a
simple, functional test case. Then if I need to "improve" my code to
compensate for "weaknesses" in the synthesis tool, at least I have a
testbench that is already debugged and functionally correct.

And like Mike said, if it works fine as originally written, I'm done.

I suppose where this gets tricky is when you are writing IP that is
intended to be used by others, where you do not know how much
performance or space they will need (i.e. the definition of "works
fine" is a bit fuzzy).  Then you simply have to look at what can be
optimized in the time and budget available that will give you the most
bang for the buck. But getting it working first, with a good
testbench, then optimizing later is still a good route to success.

Andy