More synthesis myths?

[KJ]

On Apr 15, 8:16 pm, JimLewis <j...@synthworks.com> wrote:

On Apr 15, 4:11 am, "KJ" <kkjenni...@sbcglobal.net> wrote:

"JimLewis" <j...@synthworks.com> wrote in message

news:7082d731-d77d-406d-b347-2774cd918d83@y33g2000prg.googlegroups.com....

another contributing factor with the last 2 examples.  With an
incrementer
and a smart synthesis tool, the condition  "counter = 4" is the same
as
(converting to unsigned for notation only) "counter(2) = '1'"

Which is why it is usually better to code it as "counter >= 4".  Then you
don't need to have as smart of a synthesis tool in order to reach the
conclusion that only bit 2 of the counter is needed.

KJ

KJ,
I don't think I agree.  While >= 4 seems to produce similar results
to the bit comparison, what about >= 5?  If I did my kmaps right -
yikes this is digging back some, decoding the general sense of >= 5
requires:
((Count(2) and Count(0)) or (Count(2) and Count(1))

OTOH, if I count up to 5 and think "=" rather than ">=", due to
properties of counters, I can decode just the bits that are 1
and the resulting logic is:
(Count(2) and Count(0)) ='1'.

I'm not sure that this is a fair comparison, specifically the way
you're creating the logic for "=5" by virtue of your simply counting
the one bits and "due to properties of counters" but not applying that
same thinking to the ">=" case.

The only way you can get the logic that you listed for the "=5" case
is by 'knowing' that count=7 can not occur therefore count(1) is not
needed in the decode. Fair enough. But to be fair on the >=5 case
you should also acknowledge that if one 'knows' that count=7 is
impossible, then count=6 is just as impossible and therefore the "or
(Count(2) and Count(1))" term would not be needed and the exact same
logic would be produced.

A given revision of a given synthesis tool would either have the
capability to detect this condition or not and I think would not
generate the logic that you listed for '>=5' if it was capable of
producing the logic that you listed for '=5'.

For =5 or >=5 to do as good as decoding bits, you need a smart
compiler.

My point wasn't that a smart compiler wouldn't do better than a not so
smart one (the rising tide will lift all boats after all). My point
was that for a given compiler, I believe you'll get equivalent or
better logic by using >=5 than by using =5. I'll accept that there
might be some instance where this is not true, but I've seen far more
instances where it is and have yet to run across the case where it is
not.

OTOH, in a LUT based design, will I notice the
difference of 1 LUT pin?  Probably not - unless I have alot
of counters.

But that's the reason for these discussions huh?

Kevin Jennings

 

[KJ]

On Apr 15, 10:06 pm, kennheinr...@sympatico.ca wrote:

On Apr 15, 8:16 pm, JimLewis <j...@synthworks.com> wrote:
I tend to be more concerned with
correctness, recoverability and reliability. I'd much rather it never
locks up and recovers quickly when I fuzz test it.

I'm fully in the same camp as you on this. The primary reason for >is to insure recovery of the design, a secondary benefit is
potentially less logic (and most likely but I've never formally proved
it...never produce more logic). From a readability/maintainability/
support perspective either method is equivalent in my opinion.

KJ

 

[JimLewis]

KJ,

From a readability/maintainability/
support perspective either method is equivalent in my opinion.
Agreed.

For me, readability and maintainability are most important.

Recovery is also important. I count down. It recovers also.

From hardware optimization standpoint, counting down and detecting
0 costs one carry output - independent of the size of the
counter and the value to be detected.


signal CountReg : unsigned(2 downto 0) ;

CountProc : process(Clk, nReset)
variable vCountReg : unsigned(CountReg'length downto 0) ; -- 3
downto 0
begin
if nReset = '0' then
CountReg <= "101" ;

elsif rising_edge(Clk) then
vCountReg := ('0' & CountReg) - 1 ;
if vCountReg(vCountReg'left) = '1' then
vCountReg := "0101" ;
end if ;
CountReg <= vCountReg(CountReg'range) ;
end if ;
end process ;

From a readability perspective, I would throw this into a procedure.
procedure Dec (
signal Count : inout unsigned ;
constant ReloadVal : in unsigned ;
constant IncEnable : in std_logic := '1'
) is
variable vCount : unsigned(Count'length downto 0) ;
begin
vCount := ('0' & Count) - IncEnable ;
if vCount(vCount'left) = '1' then
vCount := '0' & ReloadVal ;
end if ;
Count <= vCount(Count'length -1 downto 0) ;
end procedure ;


Then the process is:
CountProc : process(Clk, nReset)
begin
if nReset = '0' then
CountReg <= "101" ;

elsif rising_edge(Clk) then
Dec(CountReg, "101") ;

end if ;
end process ;

In the general implementation, you may prefer
if IncEnable = '1' then
vCount := ('0' & Count) - 1;
end if ;

instead of:
vCount := ('0' & Count) - IncEnable ;

I prefer the latter since it often produces smaller
hardware (although not always).

The primary reason for >=
is to insure recovery of the design, a secondary benefit is
potentially less logic (and most likely but I've never formally proved
it...never produce more logic).

WRT less logic, one counter example proves an assertion false.
Decoding =5 results in:
Count(2) and Count(1) and Count(0)

Decoding >= 5 results in:
((Count(2) and Count(0)) or (Count(2) and Count(1))

Here is a case where ">=" creates more hardware than "=".
So you can't prove your assertion "never produce more logic"
because it isn't true.

Cheers,
Jim

 

[JimLewis]

KJ

For =5 or >=5 to do as good as decoding bits, you need a smart
compiler.

My point wasn't that a smart compiler wouldn't do better than a not so
smart one (the rising tide will lift all boats after all).  My point
was that for a given compiler, I believe you'll get equivalent or
better logic by using >=5 than by using =5.  I'll accept that there
might be some instance where this is not true, but I've seen far more
instances where it is and have yet to run across the case where it is
not.

Note that I have always hand coded the =5 trick since
this is only more effective than counting down and detecting 0 where
there are only a few bits (I only do it when there is 1 or 2 bits
decoded).

WRT optimizing >=5, you can't do both recovery and counter bit
optimizations. Recovery in this case requires coverage of the
terms 5, 6, and 7. So the best you will get is:
((Count(2) and Count(0)) or (Count(2) and Count(1))
|------ 5 or 7 --------| |------ 6 or 7 -------|


To me though both of these are a mute point as this discussion has
only
reinforced my thought that counting down and detecting 0 (using the
carry chain) is the better implementation (from both optimization and
recovery).

Cheers,
Jim

 

[Marc Guardiani]

Paul wrote:

Tricky wrote:

I just overheard the following (or thereabouts)

using the following template:
process(clk, en)
begin
if en = '1' then
if rising_edge(clk) then
d <= b;
end if;
end if;
end process;

is better than the "normal" way

process(clk)
begin
if rising_edge(clk) then
if en = '1' then
c <= a;
end if;
end if;
end process;

because the 2nd can produce latches where the clock is gated with
enable? has this ever been the case? running either through quartus
produces the same (expected) thing - a d-type with enable.

Why should 'en' be included in the sensitivity list in the first
template? It just does not make sense to me. Or does this fall under
the "or thereabouts"?

As I understand processes, 'en' is in the sensitivity list because you
want the process to "run", so to speak, whenever it changes.

 

[KJ]

Why should 'en' be included in the sensitivity list in the first
template? It just does not make sense to me. Or does this fall under
the "or thereabouts"?

As I understand processes, 'en' is in the sensitivity list because you
want the process to "run", so to speak, whenever it changes.

Since the very next statement is "if rising_edge(clk) then..." the process
certainly won't be running too far...

From a synthesis perspective including (or not including) 'en' makes no
difference. From a simulation perspective, including 'en' in the
sensitivity list will make that process chew up some miniscule extra bit of
processor time, but everything will simulate exactly the same.

Kevin