Generating combination signal from within clocked clocked bl

[Valentin Tihomirov]

An example looks like this. Please, don't be very quarrel to small
inaccuracies.

//on clock
Sample <= Sample + 1;
if Sample = 7 then
BitPos <= BitPos + 1;
case BitPos is
0: ...
9: BitPos <= 0; Sample <= 0; -- AVAIL <= '1';
else ..
end case;
end if;

I get a FF and loose one clock cycle signaling data availabalility when
asserting AVAIL signal inside the CASE block. I want AVAIL to be calculated
from Sample and BitPost signals:

AVAIL <= (Sample = 7) and (BitPos = 9);

I could have this statement out of the clocked block (inside a combinational
process) but this would involve additional logic that is already synthesied
inside case block.

 

[Jonathan Bromley]

"Valentin Tihomirov" <valentin@abelectron.com> wrote in message
news:3f9cf39e$1_1@news.estpak.ee...

on clock
Sample <= Sample + 1;
if Sample = 7 then
BitPos <= BitPos + 1;
case BitPos is
0: ...
9: BitPos <= 0; Sample <= 0; -- AVAIL <= '1';
else ..
end case;
end if;

I get a FF and loose one clock cycle signaling data availabalility when
asserting AVAIL signal inside the CASE block. I want AVAIL to be
calculated
from Sample and BitPost signals:

AVAIL <= (Sample = 7) and (BitPos = 9);

I could have this statement out of the clocked block (inside a
combinational
process) but this would involve additional logic that is already
synthesied
inside case block.

Consider putting BitPos and Sample into variables. You can then
test their "next state" values. This gives you the benefit of
a registered AVAIL output without the added 1-clock delay.

....on clock...
-- Sample := Sample + 1; -- DON'T DO THIS YET!!!!
if Sample = 7 then -- test OLD value of Sample
-- BitPos := BitPos + 1; -- DON'T DO THIS YET!!!
case BitPos is -- test OLD value of BitPos
when 0=> ...
when 9=> BitPos := 0; Sample := 0;
when others => BitPos := BitPos+1;
end case;
end if;
Sample := Sample + 1;
-- Sample and BitPos now have their NEW, next-state values
if BitPos=7 and Sample=9 then AVAIL <= '1'; end if;

AVAIL will then be true synchronously with BitPos=7, Sample=9.
Obviously, I may not have the details exactly right. But it
is a useful technique, in my opinion.

If you need the values of Sample and BitPos outside the
process, you will have to assign them to signals at the
end of the clocked branch of the process.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Valentin Tihomirov]

Jonathan,

1. Thanks for the attempt
2. I use default initializers (increments) for Sample and BitPos because I
need this increment in most branches
3. Using variables does not change the sense, you are just showing one
approach of "concurrent block assignment" I referred. The problem of logic
doubling is not clarified.

Let me state it again. "(BitPos=7) and (Sample=9)" signal is used twice,
i.e.

(a) asserting 0 to BitPos and Sample;
// on clock
if Sample = 7 then
case BitPos of
0: ...
9: BitPos := 0; Sample := 0; --here
else ...
end case;
.....
end if;

and
(b) assigning AVAL.
AVAIL <= (BitPos=7) and (Sample=9);

And it is not importand where I calculate Avail signal:
- in the same process (as you'he shown);
- in another (combinational) process; and
- in a body of architecture;

The question is: will synthesis tool recognize and reuse logic once
generated for calculation of "(BitPos=7) and (Sample=9)" signal?
Alternatively,will it generate the same logic twice?

Hope my question now is quite "fundamental" and clear.

 

[Jonathan Bromley]

"Valentin Tihomirov" <valentin@abelectron.com> wrote in
message news:3f9d931a_1@news.estpak.ee...

2. I use default initializers (increments) for Sample and BitPos because I
need this increment in most branches

OK. If you wish to use variables in the process you can easily
work around this by adding another set of variables that
are used to hold the "old" value:

if rising_edge(clk) then
oldState := state;
synchOutput <= '0';
state := <default new state assignment>;
case oldState is
... [possible new state assignments]
endcase
case state is
when Special_Case =>
synchOutput <= '1';
endcase

3. Using variables does not change the sense, you are just showing one
approach of "concurrent block assignment" I referred. The problem of logic
doubling is not clarified.

I disagree. By using variables in the process, you have access
to the *next-state* value of the process's registers. If you
make use of those next-state values within the same process,
you have *not* duplicated any logic in the code, and your
synthesis tool will probably be able to share the common logic.

Let me state it again. "(BitPos=7) and (Sample=9)" signal is used twice,
i.e.

(a) asserting 0 to BitPos and Sample;
// on clock
if Sample = 7 then
case BitPos of
0: ...
9: BitPos := 0; Sample := 0; --here
else ...
end case;
....
end if;

and
(b) assigning AVAL.
AVAIL <= (BitPos=7) and (Sample=9);

Yes, I agree I coded the example in a poor way. Sorry.
It would have been better if I had used the "old state"
arrangement. Then I could easily have made the assignment
to AVAIL within the same branch of the case statement.
(I didn't do that because I was a little unsure of the
exact functionality you require. But I hope you now
can see what I mean.)

The question is: will synthesis tool recognize and reuse logic once
generated for calculation of "(BitPos=7) and (Sample=9)" signal?
Alternatively,will it generate the same logic twice?

Common expressions within the same process *should* be
eliminated by the synthesis tool, but of course there are
plenty of situations where tools can get confused. The only
sensible approach is to try some test cases on the synthesis
tool you actually use.

Hope my question now is quite "fundamental" and clear.

Perfectly clear; I'm sorry my original answer was less so.

--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.