data enable on a FF

[Al]

Hi to all,
writing some code I've noticed that to enable the data on a FF with the
combination of two or more signals there are different ways of writing
code (of course), which will turn in different implementation (maybe).
I was wondering which is the difference between the following:

-- first case
process (clk, nrst)
if nrst = '0' then
A <= '0';
if rising_edge (clk) then
if enA_1 = '1' and enA_2 = '1' then
A <= B;
end if;
end if;
end process;

-- second case
process (clk, nrst)
if nrst = '0' then
A <= '0';
if rising_edge (clk) then
if enA_1 = '1' then
if enA_2 = '1' then
A <= B;
end if;
end if;
end if;
end process;

I think there will be quite a big difference in the implementation: a
combinational AND Cell and a sequential Cell will be implemented in the
first case, while only a sequential Cell in the second case. Is this
correct?
My consideration is based on the Actel gate array layout, but I think
the principle are the same for all the layouts (combinational and
sequential Cells).
Could you confirm this?

Thanks a lot

Al

 

[KJ]

Hi to all,
writing some code I've noticed that to enable the data on a FF with the
combination of two or more signals there are different ways of writing
code (of course), which will turn in different implementation (maybe).
I was wondering which is the difference between the following:

-- first case
process (clk, nrst)
if nrst = '0' then
A <= '0';
if rising_edge (clk) then
if enA_1 = '1' and enA_2 = '1' then
A <= B;
end if;
end if;
end process;

-- second case
process (clk, nrst)
if nrst = '0' then
A <= '0';
if rising_edge (clk) then
if enA_1 = '1' then
if enA_2 = '1' then
A <= B;
end if;
end if;
end if;
end process;

I think there will be quite a big difference in the implementation: a
combinational AND Cell and a sequential Cell will be implemented in the
first case, while only a sequential Cell in the second case. Is this
correct?

No, both will synthesize to the exact same thing. The synthesis process
attempts to find the mimimal set of logic that is equivalent the original
source code. Your two examples already are equivalent (i.e. 'A' gets
updated with 'B' only when the two enables are set to 1 and the rising edge
of the clock arises and nrst is 1). Try it and see.

My consideration is based on the Actel gate array layout, but I think the
principle are the same for all the layouts (combinational and sequential
Cells).
Could you confirm this?

Try running both through any synthesis tool to target a particular device
and see.

KJ

 

[Andy]

In the old days, the differences could be used to handle late arriving
inputs more quickly than early arriving inputs, assuming you knew at
coding time which ones were which. Now, synthesis will look at timing
estimates to determine early and late arrivals, and implement the
circuit accordingly. In many cases with LUT based FPGAs there will be
no difference in the implementation. Also, most synthesis tools will
not seek to optimize early/late inputs until and unless timing
constraints fail without doing so.

Andy

 

[Andy]

In the old days, the differences could be used to handle late arriving
inputs more quickly than early arriving inputs, assuming you knew at
coding time which ones were which. Now, synthesis will look at timing
estimates to determine early and late arrivals, and implement the
circuit accordingly. In many cases with LUT based FPGAs there will be
no difference in the implementation. Also, most synthesis tools will
not seek to optimize early/late inputs until and unless timing
constraints fail without doing so.

Andy

 

[KJ]

In the old days, the differences could be used to handle late arriving
inputs more quickly than early arriving inputs, assuming you knew at
coding time which ones were which. Now, synthesis will look at timing
estimates to determine early and late arrivals, and implement the
circuit accordingly. In many cases with LUT based FPGAs there will be
no difference in the implementation. Also, most synthesis tools will
not seek to optimize early/late inputs until and unless timing
constraints fail without doing so.

Andy

Even going back to the days of Abel (the language, not the Bible guy with
brother troubles) the two versions of code that were posted and in question
would synthesize to the exact same thing targetting anything from a PAL or
the latest Virtex/Stratix.

KJ

 

[Al]

Even going back to the days of Abel (the language, not the Bible guy with
brother troubles) the two versions of code that were posted and in question
would synthesize to the exact same thing targetting anything from a PAL or
the latest Virtex/Stratix.

KJ

Is that means synthesizer will always get to the same point, based on
time estimation? I've always believed (maybe erroneously and most
probably because never gone into details) that differences like "if"
statements and "case" statements will turn out in different resources
inferred.
Based on what Andy explained, I then assume that there is no meaning
giving priority to a signal instead of another to synchronously set a
Flip-Flop, because the synthesizer, based on time estimation, may revert
the logic. But shouldn't it estimate time starting from the point that
the code has a priority?
I know that my first question was just a case of study, but then I would
really like to understand if this is a more general problem of coding style.

Thanks

Al

 

[mysticlol]

Is Gated clock approach advisable for this kind of requirement?

en <= enA_1 and enA_2;

process (clk, nrst, en)
if nrst = '0' then
A <= '0';
elsif rising_edge (clk) and en='1' then
A <= B;
end if;
end process;

Regards,
Krishna Janumanchi

 

[Al]

Is Gated clock approach advisable for this kind of requirement?

en <= enA_1 and enA_2;

process (clk, nrst, en)
if nrst = '0' then
A <= '0';
elsif rising_edge (clk) and en='1' then
A <= B;
end if;
end process;

Regards,
Krishna Janumanchi

I don't really like this approach, first of all because sometimes it
cannot be applicable from hardware point of view (hardwired clocks
cannot be gated on the Actel, for instance). Secondly it is quite risky
and can generate glitches because en has a routed delay.
In third place this approach will not allow you to have both synchronous
set and reset.

Regards,

Al

p.s.: and it doesn't have a nice look, to me ;-)

 

[Mike Treseler]

I've always believed (maybe erroneously and most
probably because never gone into details) that differences like "if"
statements and "case" statements will turn out in different resources
inferred.

An if-then-else or case statement *cannot* infer a priority encoding.
An if-then-elsif-else statement *might* infer a priority encoding.

-- Mike Treseler

 

[Al]

An if-then-else or case statement *cannot* infer a priority encoding.
An if-then-elsif-else statement *might* infer a priority encoding.

-- Mike Treseler

Sorry Mike but I don't understand, isn't it obvious that an if-then-else
cannot infer priority? priority on which other conditions if there are
no others involved in the process (being it an if-then-else there will
be only one condition)?.
My concern was more about if-then-elsif-else and case-when.
Even in if-then-elsif-else I didn't understand if the order has an
effect on the synthesis or not; to me it has always had a meaning, i.e.
if the two conditions (or more) are true in the same delta, then the
first one will take over the others, meaning that a D-FlipFlop cannot go
into a metastable condition. If I think of an A54SXA family (I've always
worked with) then I can imagine the first condition will be routed to
the the first mux of the R-Cell (the closest to the FF) and the second
one will be routed to the second mux, with will have less priority just
because is physically behind the other mux.
But if the synthesizer might "change" the order based on its
optimization algorithms, then all the "priority logic" is just
unpredictable.
Am I wrong in my understandings?

Thank you

p.s.: I love this NG!

 

[KJ]

Is that means synthesizer will always get to the same point, based on time
estimation?

'Time estimation' has nothing to do with it. Logic that is equivalent will
almost without exception synthesize to the exact same thing.

I've always believed (maybe erroneously and most probably because never
gone into details) that differences like "if" statements and "case"
statements will turn out in different resources inferred.

Only if they are not logically equivalent. Try writing the code for
something like an address decoder where you decode specific addresses and do
so using only a case statement. Then translate that code into the
equivalent if/elsif form. Synthesize and target to the same device and, if
you translated correctly, you'll get the same result.

case Address is
when C1 => -- Do something
when C2 => -- Do something else
when C3 => -- Do some more
when others => -- Do something different
end case

If written as an if statement should come out as
elsif Address = C1 then -- Do something
elsif Address = C2 then -- Do something else
elsif Address = C3 then -- Do some more
else -- Do something different
end if;

Based on what Andy explained, I then assume that there is no meaning
giving priority to a signal instead of another to synchronously set a
Flip-Flop, because the synthesizer, based on time estimation, may revert
the logic. But shouldn't it estimate time starting from the point that the
code has a priority?

I'm not quite sure what point Andy was trying to make. The synthesis
process translates your code into boolean equations. Next it tries come up
with an implementation of that set of boolean equations that meets any
timing requirements. If it does not meet timing then it works with
alternate equivaent forms of that same set of boolean equations that does
meet the requirement.

I know that my first question was just a case of study, but then I would
really like to understand if this is a more general problem of coding
style.

Equivalent logic will synthesize to the same output. It usually has nothing
to do with 'coding style', if you have a complicated algorithm to implement
it will usually be a complicated structure. Where you get the most bang for
the buck is having an understanding of how high level language structure get
translated into boolean equations and what implications get implied and
seeing if there is an alternative representation that implements the same
functionality.

As an example, from a 'coding style' perspective you might not like to see
10 nested 'if' statements of the form....
if s1 then
if s2 then
if s3 then
....
end if;
end if;
end if;

But this structure is exactly equivalent to
if s1 and s2 and s2 .... then
end if;

and will produce the exact same synthesis result. So don't let dogma about
how many nested if statements drive how the code gets written, let the
driving force be how clear the code is to understand and map back to the
requirements since, in this example, the number of NESTED if statements is
irrelevant.

But now if some (or all) of those if statements have 'else' branches now you
look a bit harder. If s1 is a single signal than not(s1) (i.e. the path
taken for the 'else' of "if s1 then" is pretty easy, but if s1 is the
comparison of let's say an 8 bit address to a constant then not(s1) becomes
quite a bit more complex. What if s1 is the comparison of an 8 bit address
to something that is not constant? Now those nested 'if statements' quickly
turn into a lot of logic and probably slow timing paths. But is that a
problem? If your implementation of the the algorithm looks just like the
algorithm specification and you meet timing, then the answer is 'no'. There
is great value in being able to look at the algorithm specification (i.e.
your functional requirements) and your implementation of that algorithm and
being able to see that one to one correspondance. If that direct
translation does NOT meet timing requirements than you have to come up with
an alternative, that's where skill and experience will kick in and be the
important determinant in getting the implementation completed correctly.

The best way to get this innate 'feel' is to try writing some benchmark
examples and see what pops out of the final synthesized result for the final
boolean equations. Once you've mastered this you'll gain the ability to
glance at code and know what things to look for that will make things
difficult to implement in terms of either logic resources or timing
performance. Their are no shortcuts to study and learn, just like doing
homework in school has you doing specific problems to gain mastery over the
topic so you can tackle new things.

KJ

 

[KJ]

Oops, slight correction to above post...

If written as an if statement should come out as
if Address = C1 then -- Do something
elsif Address = C2 then -- Do something else
elsif Address = C3 then -- Do some more
else -- Do something different
end if;

KJ

 

[Jim Lewis]

Mike

An if-then-else *cannot* infer a priority encoding.

Can too.

The following two are the same:

-- if elsif
IfElsProc : process (A, ASel, B, BSel)
begin
if ASel = '1' then
Y <= A ;
elsif BSel = '1' then
Y <= B ;
else
Y <= (others => '0') ;
end if ;
end process ;

-- multiple separate if.
-- Note priority in reverse order since last assignment wins
IfEndProc : process (A, ASel, B, BSel)
begin
Y <= (others => '0') ; -- default in place of else
if BSel = '1' then
Y <= B ;
end if ;
if ASel = '1' then
Y <= A ;
end if ;
end process ;

> An case statement *cannot* infer a priority encoding.

Can, but you probably would not want to.

Sel <= ASel & BSel ;

IfEndProc : process (A, B, Sel)
begin
case Sel is
when "11" | "10" => Y <= A ;
when "01" => Y <= B ;
when others => Y <= (others => '0') ;
end case ;
end process ;

An if-then-elsif-else statement *might* infer a priority encoding.

Most often infers priority. Will only not infer priority when
the synthesis tool can detect conditions are mutually exclusive.

-- ok, but masks X
Y <= A when Sel = '1' else B ;

-- ok, but sometimes synthesis slow (run time) and
-- sometimes I would expect lower quality of results:
works_but_do_not_do : process (Sel, A, B, C, D )
begin
if Sel = "00" then
Y <= A ;
elsif Sel = "01" then
Y <= B ;
elsif Sel = "10" then
Y <= C ;
elsif Sel = "11" then
Y <= D ;
else
Y <= (others => '0') ;
end if ;
end process ;



Sure would be nice if we could standardize a function
that indicated when inputs were mutually exclusive in such
a way that is both simulatable and understood by the
synthesis tools. Such as something like the following:

assert ZeroOneHot(ASel, BSel)
report "ASel and BSel not mutually exclusive"
severity error ;

IfElsProc : process (A, ASel, B, BSel)
begin
if ASel = '1' then
Y <= A ;
elsif BSel = '1' then
Y <= B ;
else
Y <= (others => '0') ;
end if ;
end process ;

With a synthesis result of the following (which is not
portable in synthesis):
Y <= A and (A'range => ASel) or B and (B'range => BSel) ;


The more interesting case is when ASel and BSel are both
load enables to a register.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jim Lewis]

KJ

Only if they are not logically equivalent. Try writing the code for
something like an address decoder where you decode specific addresses and do
so using only a case statement. Then translate that code into the
equivalent if/elsif form. Synthesize and target to the same device and, if
you translated correctly, you'll get the same result.

case Address is
when C1 => -- Do something
when C2 => -- Do something else
when C3 => -- Do some more
when others => -- Do something different
end case

If written as an if statement should come out as
elsif Address = C1 then -- Do something
elsif Address = C2 then -- Do something else
elsif Address = C3 then -- Do some more
else -- Do something different
end if;

This works well for an address decoder where the "Do Something"
is assign a constant since the result will be simple AND-OR logic.

I would be careful using the same thoughts for more structured
logic, such as multiplexers and math.
Although for some tools and some technology targets, the
equivalent "if" form will do fine, for others it will not,
particularly if your target is an ASIC.

Equivalent logic will synthesize to the same output. It usually has nothing
to do with 'coding style', if you have a complicated algorithm to implement
it will usually be a complicated structure.
> ... Snip ...
The best way to get this innate 'feel' is to try writing some benchmark
examples and see what pops out of the final synthesized result for the final
boolean equations. Once you've mastered this you'll gain the ability to
glance at code and know what things to look for that will make things
difficult to implement in terms of either logic resources or timing
performance. Their are no shortcuts to study and learn, just like doing
homework in school has you doing specific problems to gain mastery over the
topic so you can tackle new things.

Well stated. I second this. Benchmarking and understanding
the little pieces is very important.

Sometimes synthesis tools may vary as they combine logic.
If this makes you miss timing, you can isolate (hide) the
terms that are causing the synthesis tool to mess up placing
either "SYN_KEEP" in Synplicity or "KEEP" in Xilinx (IEEE
1076.6-2004 compliant) on the logic term that you do not want
to combine with other logic. Note don't do this as a general
technique as sometimes the synthesis tool will find a better
solution than the one you expect.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Andy]

First, in the example you gave, there is no priority. BOTH must be true
to enable the assignment. The notion of priority implies that more than
one possible behavior can occur, and one of those possibilities has
priority over other possibilities.

Priority is usually implied by an else statement, or by order of if
statements (not nested), in that the last assignment wins in sequential
code.

For example:

if a then
x <= y;
elsif b then
x <= w;
end if;

The above implies that a (and the resulting x<=y assignment) has
priority over b and its assignment. The same priority can be implied
with:

if b then
x <= w;
end if;
if a then
x <= y;
end if;

or:

if a then
x <= y;
end if;
if b and not a then -- ignoring metavalues
x <= w;
end if;

The ONLY time a synthesis tool will ignore the coded priority is if it
can determine that a and b are mutually exclusive. Then it can safely
optimize out the priority logic.

Andy

 

[Al]

First, in the example you gave, there is no priority. BOTH must be true
to enable the assignment. The notion of priority implies that more than
one possible behavior can occur, and one of those possibilities has
priority over other possibilities.

I agree, maybe I massed up the thread, going a bit further out of the
topic, but everything came from your phrase:

Now, synthesis will look at timing
estimates to determine early and late arrivals, and implement the
circuit accordingly.

which led me to some erroneous assumptions (as you can see in the
previous posts).
About priority I do understand the example I posted didn't imply any
priority and I do understand that priority is needed between two
conditions, that's why an if-then-else cannot imply priority because the
conditions are mutually exclusive.

Priority is usually implied by an else statement, or by order of if
statements (not nested), in that the last assignment wins in sequential
code. (snip...)

if b then
x <= w;
end if;
if a then
x <= y;
end if;

You are always talking about process assignment, is that true? I wasn't
aware of this rule, good to know, thanks!

Regards

Al

 

[lokesh_boddu]

mysticlol wrote:
> Is Gated clock approach advisable for this kind of requirement?
>
> en <= enA_1 and enA_2;
>
> process (clk, nrst, en)
> if nrst = '0' then
> A <= '0';
> elsif rising_edge (clk) and en='1' then
> A <= B;
> end if;
> end process;
>
> Regards,
> Krishna Janumanchi
>

I don't really like this approach, first of all because sometimes it
cannot be applicable from hardware point of view (hardwired clocks
cannot be gated on the Actel, for instance). Secondly it is quite risky
and can generate glitches because en has a routed delay.
In third place this approach will not allow you to have both synchronous
set and reset.

Regards,

Al

--------------------
Hi, could you please elaborate your explanation on the above program why it should not be written like that

Thanks and Regards
BODDU Lokesh