signals in sensitiv list... and reset

Hi all,

I have been away from the vhdl design for a while and when I got back
and read through some code I found some things that was new for me.

1.) In a process sensitive list I usually have a clock and a reset
making it synchronous or signals to do some combinatorial stuff. But
now I see that the two versions are being mixed.

process (clk, reset, switch)
begin
if rising_edge(clk) then
a_delay <= b or c;

if switch = "00" then
output <= "010" & a_delay;
elsif switch = "01" then
output <= "011" & a_delay;
elsif switch = "10" then
output <= "111" & a_delay or d;
elsif switch = "11" then
output <= "101" & a_delay;
end if;
end if;
end process;

As I see it this would place a combinatorial cloud on the output flip-
flop a_delay with an or gate at its input. Is there any advantage to
write this in a single process?

2.) is there any benefit of writing a synchronous reset as follows?
....
if rising_edge(clk) then
....
a <= b;
c <= d;
etc....

if reset = '1' then
a <= '0';
c <= '1';
end if;
end if;
.....

instead of

if rising_edge(clk) then
if reset = '1' then
a <= '0';
c <= '1';
else
....
a <= b;
c <= d;
etc....
end if;
end if;


What do you think?

Best regards,
Rick

On Aug 12, 3:32*pm, Rick North <dontreplytothisa...@hotmail.com>
wrote:
> Hi all,
>
> I have been away from the vhdl design for a while and when I got back
> and read through some code I found some things that was new for me.
>
> 1.) In a process sensitive list I usually have a clock and a reset
> making it synchronous or signals to do some combinatorial stuff. But
> now I see that the two versions are being mixed.
>
> process (clk, reset, switch)
> begin
> * *if rising_edge(clk) then
> * * *a_delay <= b or c;
>
> * * * if switch = "00" then
> * * * * *output <= "010" & a_delay;
> * * *elsif switch = "01" then
> * * * * *output <= "011" & a_delay;
> * * *elsif switch = "10" then
> * * * * *output <= "111" & a_delay or d;
> * * *elsif switch = "11" then
> * * * * *output <= "101" & a_delay;
> * * *end if;
> *end if;
> end process;
>
> As I see it this would place a combinatorial cloud on the output flip-
> flop a_delay with an or gate at its input.

I'm not sure what 'cloud' you're seeing but what I see is a strictly
synchronous process that will take some slight teeny bit longer to
simulate because of the extraneous signals in the sensitivity list.
In this case, the process 'wakes up' when clk, switch or reset
changes, BUT the outermost 'if rising_edge(clk) then...' will inhibit
any of the code from executing unless the rising edge of clk has
occurred, thus it is a strictly synchronous process and will
synthesize as such (no async reset, no 'combinatorial cloud').


> Is there any advantage to
> write this in a single process?
>

It is one process.

> 2.) is there any benefit of writing a synchronous reset as follows?
> ...
> if rising_edge(clk) then
> * * ....
> * * a <= b;
> * * c *<= d;
> * * etc....
>
> * * if reset = '1' then
> * * * *a <= '0';
> * * * *c <= '1';
> * * end if;
> end if;
> ....
>
> instead of
>
> if rising_edge(clk) then
> * * if reset = '1' then
> * * * *a <= '0';
> * * * *c <= '1';
> * * else
> * * * *....
> * * * *a <= b;
> * * * *c *<= d;
> * * * *etc....
> * * end if;
> end if;
>

They are both functionally equivalent, they will both synthesize to
the same thing so it's simply a matter of appearances then as to which
you think is 'better' and whether you think there is any benefit.

> What do you think?
>
Personally, I prefer the following form
if reset = '1' then
....
else
....
end if;
simply because I hate wading through a long process trying to decipher
the logic only to find that it is all moot because there is an 'if
The_Sky_Is_Falling = '1' statement at the end. Reset logic tends to
usually be short and sweet, one line per signal whereas the 'else'
portion can get long and windy. But again, it's not a functional
anything, strictly a beauty contest as to the form.

KJ

On Aug 12, 3:20 pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On Aug 12, 3:32 pm, Rick North <dontreplytothisa...@hotmail.com>
> wrote:
> > 2.) is there any benefit of writing a synchronous reset as follows?
> > ...
> > if rising_edge(clk) then
> > ....
> > a <= b;
> > c <= d;
> > etc....
>
> > if reset = '1' then
> > a <= '0';
> > c <= '1';
> > end if;
> > end if;
> > ....
>
> > instead of
>
> > if rising_edge(clk) then
> > if reset = '1' then
> > a <= '0';
> > c <= '1';
> > else
> > ....
> > a <= b;
> > c <= d;
> > etc....
> > end if;
> > end if;
>
> They are both functionally equivalent, they will both synthesize to
> the same thing so it's simply a matter of appearances then as to which
> you think is 'better' and whether you think there is any benefit.
>

The two forms are not necessarily equivalent. In the first form, if a
register is not reset, its value is preserved with a feedback mux
while reset is active. In the second form, if a register is not reset,
it functions normally. Synplify will warn you if it uses a feedback
mux with an async reset, but I don't know if it does so for
synchronous resets.

I use asynchronous resets for initialization, so I use the first form
most of the time, to get the warnings indicating unreset registers. If
I intentionally need to not reset some things in a process (like
distributed ram array), then I use the second form, which also reminds
me to double check the completeness of the reset assignments.

Andy

On 12 Aug, 20:32, Rick North <dontreplytothisa...@hotmail.com> wrote:
> Hi all,
>
> I have been away from the vhdl design for a while and when I got back
> and read through some code I found some things that was new for me.
>
> 1.) In a process sensitive list I usually have a clock and a reset
> making it synchronous or signals to do some combinatorial stuff. But
> now I see that the two versions are being mixed.
>
> process (clk, reset, switch)
> begin
> * *if rising_edge(clk) then
> * * *a_delay <= b or c;
>
> * * * if switch = "00" then
> * * * * *output <= "010" & a_delay;
> * * *elsif switch = "01" then
> * * * * *output <= "011" & a_delay;
> * * *elsif switch = "10" then
> * * * * *output <= "111" & a_delay or d;
> * * *elsif switch = "11" then
> * * * * *output <= "101" & a_delay;
> * * *end if;
> *end if;
> end process;
>
> As I see it this would place a combinatorial cloud on the output flip-
> flop a_delay with an or gate at its input. Is there any advantage to
> write this in a single process?
>
> 2.) is there any benefit of writing a synchronous reset as follows?
> ...
> if rising_edge(clk) then
> * * ....
> * * a <= b;
> * * c *<= d;
> * * etc....
>
> * * if reset = '1' then
> * * * *a <= '0';
> * * * *c <= '1';
> * * end if;
> end if;
> ....
>
> instead of
>
> if rising_edge(clk) then
> * * if reset = '1' then
> * * * *a <= '0';
> * * * *c <= '1';
> * * else
> * * * *....
> * * * *a <= b;
> * * * *c *<= d;
> * * * *etc....
> * * end if;
> end if;
>
> What do you think?
>
> Best regards,
> Rick

if reset = '1' in the first example causes parrallel assignment. It
may have synthesys problem.

On Aug 15, 12:03*pm, jacko <jackokr...@gmail.com> wrote:
k
>
> if reset = '1' in the first example causes parrallel assignment. It
> may have synthesys problem.- Hide quoted text -
>

You're mistaken, there will be no parallel assignment or synthesis
problem.

KJ

On 15 Aug, 17:38, KJ <kkjenni...@sbcglobal.net> wrote:
> On Aug 15, 12:03*pm, jacko <jackokr...@gmail.com> wrote:
> k
>
>
>
> > if reset = '1' in the first example causes parrallel assignment. It
> > may have synthesys problem.- Hide quoted text -
>
> You're mistaken, there will be no parallel assignment or synthesis
> problem.
>
> KJ

if rising_edge(clk) then
....
a <= b; --assignment 1
c <= d;
etc....


if reset = '1' then
a <= '0'; --assignment 2
c <= '1';
end if;
end if;


a <= b and/or ('0' and reset)_extended;
c <= d and/or ('1' and reset)_extended;

the assignments are multiple when reset = '1' on risign_edge(clk) am I
to infer that the assignment 1 is not performed on rising_edge(clk)?
That's not what the code says. The systhesis of the or logic would be
dependant on implementation technology and so be ambiguous.

cheers
jacko

On Aug 15, 1:03*pm, jacko <jackokr...@gmail.com> wrote:
> On 15 Aug, 17:38, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > On Aug 15, 12:03*pm, jacko <jackokr...@gmail.com> wrote:
> > k
>
> > > if reset = '1' in the first example causes parrallel assignment. It
> > > may have synthesys problem.- Hide quoted text -
>
> > You're mistaken, there will be no parallel assignment or synthesis
> > problem.
>
> > KJ
>
> if rising_edge(clk) then
> * * ....
> * * a <= b; *--assignment 1
> * * c *<= d;
> * * etc....
>
> * * if reset = '1' then
> * * * *a <= '0'; --assignment 2
> * * * *c <= '1';
> * * end if;
> end if;
>
> a <= b and/or ('0' and reset)_extended;
> c <= d and/or ('1' and reset)_extended;
>
> the assignments are multiple when reset = '1' on risign_edge(clk) am I
> to infer that the assignment 1 is not performed on rising_edge(clk)?

If you'd look at your own code, the "if reset = '1' then" is inside
the "if rising_edge(clk) then", this is one form for a synchronous
reset. If there is not clock, then reset is ignored...just as you
wrote it.

Then take a look at how VHDL does things and realize that if there are
multiple assignments to a signal *inside a process* that the last
assignment takes precedence. This is not creating multiples of
anything...any synthesis tool can handle this.

> That's not what the code says. The systhesis of the or logic would be
> dependant on implementation technology and so be ambiguous.
>
Perhaps you should step back and actually try to synthesize this
before you post.

I'm assuming that these statements that you listed...
a <= b and/or ('0' and reset)_extended;
c <= d and/or ('1' and reset)_extended;

are just nonsense, and the only 'code' we're talking about is the
process.

There is nothing technology dependent or ambiguous in the code for the
process.

KJ

On 15 Aug, 18:16, KJ <kkjenni...@sbcglobal.net> wrote:
> On Aug 15, 1:03*pm, jacko <jackokr...@gmail.com> wrote:
>
>
>
>
>
> > On 15 Aug, 17:38, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > On Aug 15, 12:03*pm, jacko <jackokr...@gmail.com> wrote:
> > > k
>
> > > > if reset = '1' in the first example causes parrallel assignment. It
> > > > may have synthesys problem.- Hide quoted text -
>
> > > You're mistaken, there will be no parallel assignment or synthesis
> > > problem.
>
> > > KJ
>
> > if rising_edge(clk) then
> > * * ....
> > * * a <= b; *--assignment 1
> > * * c *<= d;
> > * * etc....
>
> > * * if reset = '1' then
> > * * * *a <= '0'; --assignment 2
> > * * * *c <= '1';
> > * * end if;
> > end if;
>
> > a <= b and/or ('0' and reset)_extended;
> > c <= d and/or ('1' and reset)_extended;
>
> > the assignments are multiple when reset = '1' on risign_edge(clk) am I
> > to infer that the assignment 1 is not performed on rising_edge(clk)?
>
> If you'd look at your own code, the "if reset = '1' then" is inside
> the "if rising_edge(clk) then", this is one form for a synchronous
> reset. *If there is not clock, then reset is ignored...just as you
> wrote it.

cut and paste it with edits.

> Then take a look at how VHDL does things and realize that if there are
> multiple assignments to a signal *inside a process* that the last
> assignment takes precedence. *This is not creating multiples of
> anything...any synthesis tool can handle this.

Synthesis is sequential emulation of parallel.

> > That's not what the code says. The systhesis of the or logic would be
> > dependant on implementation technology and so be ambiguous.
>
> Perhaps you should step back and actually try to synthesize this
> before you post.

Yes and organized by cut and paste to get nice read shame about the
error introduced by just moving some parallel assignment statements
about.

> I'm assuming that these statements that you listed...
> a <= b and/or ('0' and reset)_extended;
> c <= d and/or ('1' and reset)_extended;
>
> are just nonsense, and the only 'code' we're talking about is the
> process.

No I was wondering how a dual parallel assignment was performed.

> There is nothing technology dependent or ambiguous in the code for the
> process.

Until the VHDL for <= is called serial overidden parallel assignment
statement, I will not use the two assignment infered form.

cheers
jacko

On Aug 13, 11:49 am, Andy <jonesa...@comcast.net> wrote:
> On Aug 12, 3:20 pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
>
>
> > On Aug 12, 3:32 pm, Rick North <dontreplytothisa...@hotmail.com>
> > wrote:
> > > 2.) is there any benefit of writing a synchronous reset as follows?
> > > ...
> > > if rising_edge(clk) then
> > > ....
> > > a <= b;
> > > c <= d;
> > > etc....
>
> > > if reset = '1' then
> > > a <= '0';
> > > c <= '1';
> > > end if;
> > > end if;
> > > ....
>
> > > instead of
>
> > > if rising_edge(clk) then
> > > if reset = '1' then
> > > a <= '0';
> > > c <= '1';
> > > else
> > > ....
> > > a <= b;
> > > c <= d;
> > > etc....
> > > end if;
> > > end if;
>
> > They are both functionally equivalent, they will both synthesize to
> > the same thing so it's simply a matter of appearances then as to which
> > you think is 'better' and whether you think there is any benefit.
>
> The two forms are not necessarily equivalent. In the first form, if a
> register is not reset, its value is preserved with a feedback mux
> while reset is active. In the second form, if a register is not reset,
> it functions normally. Synplify will warn you if it uses a feedback
> mux with an async reset, but I don't know if it does so for
> synchronous resets.

I disagree. Both forms are identical. Neither generates an async
reset, both create a sync reset and the rest of the time cause the
output of the register to be defined by the non-reset logic.


> I use asynchronous resets for initialization, so I use the first form
> most of the time, to get the warnings indicating unreset registers. If
> I intentionally need to not reset some things in a process (like
> distributed ram array), then I use the second form, which also reminds
> me to double check the completeness of the reset assignments.

I also use async resets for FPGA logic since they need to be
initialized at power up. I use neither of the above forms, I use one
that actually creates an async reset.

if reset = '1' then
a <= '0';
c <= '1';
elsif rising_edge(clk) then
....
a <= b;
c <= d;
etc....
end if;

By putting the reset test inside the rising_edge if, it is a sync
reset, not async.

Rick

On Aug 15, 1:03 pm, jacko <jackokr...@gmail.com> wrote:
> On 15 Aug, 17:38, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > On Aug 15, 12:03 pm, jacko <jackokr...@gmail.com> wrote:
> > k
>
> > > if reset = '1' in the first example causes parrallel assignment. It
> > > may have synthesys problem.- Hide quoted text -
>
> > You're mistaken, there will be no parallel assignment or synthesis
> > problem.
>
> > KJ
>
> if rising_edge(clk) then
> ....
> a <= b; --assignment 1
> c <= d;
> etc....
>
> if reset = '1' then
> a <= '0'; --assignment 2
> c <= '1';
> end if;
> end if;
>
> a <= b and/or ('0' and reset)_extended;
> c <= d and/or ('1' and reset)_extended;
>
> the assignments are multiple when reset = '1' on risign_edge(clk) am I
> to infer that the assignment 1 is not performed on rising_edge(clk)?
> That's not what the code says. The systhesis of the or logic would be
> dependant on implementation technology and so be ambiguous.

This is not a multiple assignment. You need to refresh yourself on
how processes work. The <= is an assignment, but it is pending the
suspension of the process. Or another way to look at it is to say the
assignment is made at the present time plus one delta delay.

Otherwise, the statements inside a process are executed sequentially.
So if you first execute a <= b; a pending assignment is made to happen
at "now" plus delta. When a <= '0'; is executed the first assignment
is replaced with the second. When the process exits at the end
process; statement and all other operations pending the current time
the assignment to a can be run and it assumes the appropriate value.

This is done all the time... well by some of us. It is not uncommon
for a complex piece of logic to not be fully specified. Rather than
to type a <= '0'; into a dozen branches of if statement to complement
the one where a is updated, you can put the assignment of a <= '0';
ahead of the first if and it will be the default when no other
assignment to a is made inside the conditionals. This mostly happens
when multiple signals are assigned values in a complex if or case
statements where the other assignments are sparse.

Rick