redundant signals in sensitivity list?

Hello,

I have come across the following VHDL example describing a D flip-flop
with preset and clear. It seems to me that clr and pr can be omitted
entirely from the process's sensitivity list as the only time one
of these will change is when clr_l or pr_l will change. Is this
so or do the signals clr and pr (clear and preset) really have
to be included in the sensitivity list as well?

Thanks,

Neil

library ieee;
use ieee.std_logic_1164.all;

entity ff is
port (d, clk, pr_l, clr_l: in std_logic;
q, qn: out std_logic);
end entity ff;

architecture arch of ff is
signal pr, clr: std_logic;
begin
process (clr_l, clr, pr_l, pr, clk) is
begin
pr <= not pr_l; clr <= not clr_l;
if (clr and pr) = '1' then q <= '0'; qn <= '0';
elsif clr = '1' then q <= '0'; qn <= '1';
elsif pr = 'q' then q <= '1; qn <= '0';
elsif rising_edge(clk) then q <= d; qn <= not d;
end if;
end process;
end architecture arch;

Neil Zanella

In your example the signals clr and pr should be in the sensitivity list.
Note that a line in your description is:
> pr <= not pr_l; clr <= not clr_l;
Suppose that clr_l becomes '0' then the process will resume execution.
If the line above is executed clr will become '0' after a delta delay!
(signals are never updated immediatly).
> elsif clr = '1' then q <= '0'; qn <= '1';
So when the line above is exuted clk is still '0' (the 'old' value).

If the process suspends it and clr and pr are in the sensitivity list is
will resume execution 1 delta delay later.
Synthesis tools often look not that carefully to the sensitivity list
(assuming that all signal are in the list).

If you had used variables for pr and clr you don't have this mismatch.
Of course you don't need clr and pr at all.

library ieee;
use ieee.std_logic_1164.all;

entity ff is
port (d, clk, pr_l, clr_l: in std_logic;
q, qn: out std_logic);
end entity ff;

architecture arch of ff is
begin
process (clr_l, pr_l, clk) is
begin
if (clr_l='0') and (pr_l='0') then q<='0'; qn <='0';
elsif clr_l = '0' then q <= '0'; qn <= '1';
elsif pr_l = '0' then q <= '1'; qn <= '0';
elsif rising_edge(clk) then q <= d; qn <= not d;
end if;
end process;
end architecture arch;

Note that your description is will not result in 1 flipflop but 2 flipflops.

Egbert Molenkamp



"Neil Zanella" <> schreef in bericht
newsine.LNX.4.44.0312130600220.9271-...
>
> Hello,
>
> I have come across the following VHDL example describing a D flip-flop
> with preset and clear. It seems to me that clr and pr can be omitted
> entirely from the process's sensitivity list as the only time one
> of these will change is when clr_l or pr_l will change. Is this
> so or do the signals clr and pr (clear and preset) really have
> to be included in the sensitivity list as well?
>
> Thanks,
>
> Neil
>
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity ff is
> port (d, clk, pr_l, clr_l: in std_logic;
> q, qn: out std_logic);
> end entity ff;
>
> architecture arch of ff is
> signal pr, clr: std_logic;
> begin
> process (clr_l, clr, pr_l, pr, clk) is
> begin
> pr <= not pr_l; clr <= not clr_l;
> if (clr and pr) = '1' then q <= '0'; qn <= '0';
> elsif clr = '1' then q <= '0'; qn <= '1';
> elsif pr = 'q' then q <= '1; qn <= '0';
> elsif rising_edge(clk) then q <= d; qn <= not d;
> end if;
> end process;
> end architecture arch;
>

Egbert Molenkamp

Thank you for your reply...

I must admit that now I am somewhat confused...

"Egbert Molenkamp" <> wrote in message

> Note that a line in your description is:

> > pr <= not pr_l; clr <= not clr_l;

> Suppose that clr_l becomes '0' then the process will resume execution.
> If the line above is executed clr will become '0' after a delta delay!
> (signals are never updated immediatly).

Yes. The VHDL simulator schedules the signal to be updated one delta delay
later, since no explicit inertial or transport delays are specified in the
given signal assignment statement.

> > elsif clr = '1' then q <= '0'; qn <= '1';
> So when the line above is exuted clk is still '0' (the 'old' value).
>
> If the process suspends it and clr and pr are in the sensitivity list is
> will resume execution 1 delta delay later.

I am not sure I follow. Because of the aforementioned concurrent signal
assignment statement, the signals pr and clr will be updated in response
to an update to pr_l and clr_l, regardless of whether or not they appear
in the sensitivity list. This is because a wire is a wire, and when you
put a not gate in between two names signals, and you change the value of
one of them, the other one must physically change as well. At least, this
intuition applies to hardware, and, thus, I would expect software to
be representative of this too.

> Synthesis tools often look not that carefully to the sensitivity list
> (assuming that all signal are in the list).

What do you mean by ALL signals? Do you mean all signals appearing on the
RHS of a signal assignment statement, or do you really mean all of them?
It seems to me that if they do not appear on the RHS of an assignment
they are not really needed in the sensitivity list.

> If you had used variables for pr and clr you don't have this mismatch.
> Of course you don't need clr and pr at all.

OK, they are not really needed, but suppose they were outputs of the ff
device, which is very artificial, but let us suppose they were, just so
that we can further discuss this issue...

> library ieee;
> use ieee.std_logic_1164.all;
>
> entity ff is
> port (d, clk, pr_l, clr_l: in std_logic;
> q, qn: out std_logic);
> end entity ff;
>
> architecture arch of ff is
> begin
> process (clr_l, pr_l, clk) is
> begin
> if (clr_l='0') and (pr_l='0') then q<='0'; qn <='0';
> elsif clr_l = '0' then q <= '0'; qn <= '1';
> elsif pr_l = '0' then q <= '1'; qn <= '0';
> elsif rising_edge(clk) then q <= d; qn <= not d;
> end if;
> end process;
> end architecture arch;
>
> Note that your description is will not result in 1 flipflop but 2 flipflops.

Why is this so? And how can I fix it so that only one flip-flop is generated?

Thanks,

Neil

> Egbert Molenkamp
>
>
>
> "Neil Zanella" <> schreef in bericht
> newsine.LNX.4.44.0312130600220.9271-...
> >
> > Hello,
> >
> > I have come across the following VHDL example describing a D flip-flop
> > with preset and clear. It seems to me that clr and pr can be omitted
> > entirely from the process's sensitivity list as the only time one
> > of these will change is when clr_l or pr_l will change. Is this
> > so or do the signals clr and pr (clear and preset) really have
> > to be included in the sensitivity list as well?
> >
> > Thanks,
> >
> > Neil
> >
> > library ieee;
> > use ieee.std_logic_1164.all;
> >
> > entity ff is
> > port (d, clk, pr_l, clr_l: in std_logic;
> > q, qn: out std_logic);
> > end entity ff;
> >
> > architecture arch of ff is
> > signal pr, clr: std_logic;
> > begin
> > process (clr_l, clr, pr_l, pr, clk) is
> > begin
> > pr <= not pr_l; clr <= not clr_l;
> > if (clr and pr) = '1' then q <= '0'; qn <= '0';
> > elsif clr = '1' then q <= '0'; qn <= '1';
> > elsif pr = 'q' then q <= '1; qn <= '0';
> > elsif rising_edge(clk) then q <= d; qn <= not d;
> > end if;
> > end process;
> > end architecture arch;
> >

Neil Zanella

"Neil Zanella" <> schreef in bericht
news: om...
> I am not sure I follow. Because of the aforementioned concurrent signal
> assignment statement, the signals pr and clr will be updated in response
> to an update to pr_l and clr_l, regardless of whether or not they appear
> in the sensitivity list. This is because a wire is a wire, and when you

I think this is the problem.
All statements IN a process are sequential statements.

process (clr_l, pr_l, clk) is -- I removed clr and pr
begin
pr <= not pr_l; clr <= not clr_l;
if (clr and pr) = '1' then q <= '0'; qn <= '0';
elsif clr = '1' then q <= '0'; qn <= '1';
elsif pr = 'q' then q <= '1; qn <= '0';
elsif rising_edge(clk) then q <= d; qn <= not d;
end if;
end process;

The process above will resume execution when one of the signals in the
sensitivity list is changed.
Suppose clr_l becomes '0'. Then when the SEQUENTIAL statement
clr <= not clr_l; is executed clr will become '1' in the next delay
(assuming no others assignements is made to clr).
So during the remaining execution clr is still '0'.
Then if all processes have suspended execution the simulation time is going
to the next delta and the signal clr becomes '1'. ALL processes sensitive
to signal CLR resume execution. So if clr is not in the sensitivity list
of a process that process is not executed (as you already noticed
during simulation).

"a wire is a wire" .. well may be you should look at VHDL from a
more programming view in stead of a hardware description. I don't think
the word synthesis (or something like that) is used in the LRM of VHDL.

We are lucky that there are powerful synthesis tools available nowadays
that can handle a suset of VHDL very well. However in the beginning
these tooling were not very good.
Many tools nowadays still (and will be in the future, I guess for
portability
reasons?) have the problem that early synthesis tool did not really take
care of the sensitivity list.
In fact if a signal is read it is assumed that that signal is in the list
(sometimes generating a warming if it is not there).

> What do you mean by ALL signals? Do you mean all signals appearing on the
> RHS of a signal assignment statement, or do you really mean all of them?
Indeed those in the RHS.

Egbert Molenkamp

Egbert Molenkamp

> process (clr_l, clr, pr_l, pr, clk) is
> begin
> pr <= not pr_l; clr <= not clr_l;
> if (clr and pr) = '1' then q <= '0'; qn <= '0';
> elsif clr = '1' then q <= '0'; qn <= '1';
> elsif pr = 'q' then q <= '1; qn <= '0';
> elsif rising_edge(clk) then q <= d; qn <= not d;
> end if;
> end process;

This example code really combines the following two processes into one, so
all the signals in the sensitivity lists of the two processes need to be
included in the one process shown above.

process (clr_l, pr_l) is
begin
pr <= not pr_l; clr <= not clr_l;
end process;

process (clr, pr, clk) is
begin
if (clr and pr) = '1' then q <= '0'; qn <= '0';
elsif clr = '1' then q <= '0'; qn <= '1';
elsif pr = 'q' then q <= '1; qn <= '0';
elsif rising_edge(clk) then q <= d; qn <= not d;
end if;
end process;

Jim Wu
(remove capital letters)
http://www.geocities.com/jimwu88/chips

Jim Wu

Neil Zanella wrote:
>
> I am not sure I follow. Because of the aforementioned concurrent signal
> assignment statement, the signals pr and clr will be updated in response
> to an update to pr_l and clr_l, regardless of whether or not they appear
> in the sensitivity list. This is because a wire is a wire, and when you
> put a not gate in between two names signals, and you change the value of
> one of them, the other one must physically change as well. At least, this
> intuition applies to hardware, and, thus, I would expect software to
> be representative of this too.

I think Neil gave a pretty good explanation, but let me word it slightly
differently. This is one of those grey areas where a behavioral
simulation can (but not necessarily) behave differently from the real
synthesized hardware. The rules for VHDL simulation are crystal clear;
the code you show will not behave like a "wire" without clr and pr in
the sensitivity list. If it does, then your VHDL simulator is broken

However, the rules for synthesis are not so clear cut, especially in
cases like yours (removing clr and pr from the sensitivity list) where
the desired behavior is a bit ambiguous. When you write code in odd
ways, different synthesis tools might implement it in slightly different
ways.

--
My real email is akamail.com@dclark (or something like that).

Duane Clark

> However, the rules for synthesis are not so clear cut, especially in
> cases like yours (removing clr and pr from the sensitivity list) where
> the desired behavior is a bit ambiguous. When you write code in odd
> ways, different synthesis tools might implement it in slightly different
> ways.

WRT synthesis behavior, IEEE 1076.6-200X (currently in ballot)
will require compliant synthesis tools to generate an error
if a full sensitivity list is not provided for combinational
and latch type logic.

If you want consistent behavior between different synthesis
tools, make sure to let you synthesis tool vendor you
want them to support IEEE 1076.6-200X (will be either 2003 or
2004). Note you need to do this because to a vendor, support
of a standard is an investment and a business decision.
If you don't express your interest, they will not make the
investment.

Best Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Jim Lewis
Director of Training private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Duane Clark wrote:
> Neil Zanella wrote:
>
>>
>> I am not sure I follow. Because of the aforementioned concurrent signal
>> assignment statement, the signals pr and clr will be updated in response
>> to an update to pr_l and clr_l, regardless of whether or not they appear
>> in the sensitivity list. This is because a wire is a wire, and when you
>> put a not gate in between two names signals, and you change the value of
>> one of them, the other one must physically change as well. At least, this
>> intuition applies to hardware, and, thus, I would expect software to
>> be representative of this too.
>
>
> I think Neil gave a pretty good explanation, but let me word it slightly
> differently. This is one of those grey areas where a behavioral
> simulation can (but not necessarily) behave differently from the real
> synthesized hardware. The rules for VHDL simulation are crystal clear;
> the code you show will not behave like a "wire" without clr and pr in
> the sensitivity list. If it does, then your VHDL simulator is broken
>
> However, the rules for synthesis are not so clear cut, especially in
> cases like yours (removing clr and pr from the sensitivity list) where
> the desired behavior is a bit ambiguous. When you write code in odd
> ways, different synthesis tools might implement it in slightly different
> ways.

Jim Lewis

"Egbert Molenkamp" <> wrote in message news:<brhj0e$7h8$>...
> "Neil Zanella" <> schreef in bericht
> news: om...
> > I am not sure I follow. Because of the aforementioned concurrent signal
> > assignment statement, the signals pr and clr will be updated in response
> > to an update to pr_l and clr_l, regardless of whether or not they appear
> > in the sensitivity list. This is because a wire is a wire, and when you
>
> I think this is the problem.
> All statements IN a process are sequential statements.
>
> process (clr_l, pr_l, clk) is -- I removed clr and pr
> begin
> pr <= not pr_l; clr <= not clr_l;
> if (clr and pr) = '1' then q <= '0'; qn <= '0';
> elsif clr = '1' then q <= '0'; qn <= '1';
> elsif pr = 'q' then q <= '1; qn <= '0';
> elsif rising_edge(clk) then q <= d; qn <= not d;
> end if;
> end process;
>
> The process above will resume execution when one of the signals in the
> sensitivity list is changed.
> Suppose clr_l becomes '0'. Then when the SEQUENTIAL statement
> clr <= not clr_l; is executed clr will become '1' in the next delay
> (assuming no others assignements is made to clr).
> So during the remaining execution clr is still '0'.
> Then if all processes have suspended execution the simulation time is going
> to the next delta and the signal clr becomes '1'. ALL processes sensitive
> to signal CLR resume execution. So if clr is not in the sensitivity list
> of a process that process is not executed (as you already noticed
> during simulation).

OK, I see now. The key here is that clr is updated in the NEXT time slot,
hence the process will not run past one delta time period later unless the
clr is executed, because it cannot trigger the execution of the process until
it appears in the sensitivity list.

I guess in this case then the synthesizer would have to ignore the if
statement and its contents altogether, since the if can never run... (?)

> "a wire is a wire" .. well may be you should look at VHDL from a
> more programming view in stead of a hardware description. I don't think
> the word synthesis (or something like that) is used in the LRM of VHDL.

You're right. Folk lore has it that VHDL is different from other programming
languages, and that you should think about what you write it in terms of
the underlying hardware. This is partly true, because if you want to
synthesize your model, then you want to organize the code in a way
that will make the synthesizer's job easier and so that it will
infer the right hardware elements in its macrocells. However,
what several books lack, is a description of the synthesis
process. Also, several books spend lots of lines on the
syntax on the language, but do not delve into software
engineering issues too much, relating to how to good
design practices. Also, they do not delve into common
mistakes and how constructs such as the one discussed
would differ from each other. Syntax alone is useless
if you don't know something about how the simulator
uses the syntax and how the synthesizer synthesizes
it. However, we should all remember that VHDL was
originally not meant for synthesis, and that is
why the LRM does not mention it. Nevertheless,
synthesis is the new horizon for VHDL and how
to synthesize and syntheisis algorithms is a
hot topic of research these days in hardware
systems such as FPGAs. The key issue is that
one must know how the simulator, and the
synthesizer, interpret VHDL, despite its
syntactical correctness. Most important,
I feel that books do not satisfactorily
describe the pitfalls of VHDL when
compared to other programming
languages constructs like C.

> We are lucky that there are powerful synthesis tools available nowadays
> that can handle a suset of VHDL very well. However in the beginning
> these tooling were not very good.

Did they exist at all in the beginning???

> Many tools nowadays still (and will be in the future, I guess for
> portability
> reasons?) have the problem that early synthesis tool did not really take
> care of the sensitivity list.

I guess no synthesizer fully supports all VHDL syntax, even though they
all seem to parse all of VHDL correctly.

> In fact if a signal is read it is assumed that that signal is in the list
> (sometimes generating a warming if it is not there).

Well, there should be a warning! The problem though, is that VHDL compilation
time takes so, so, so, so, so long, that users become discouraged and sometimes
do not bother fixing warnings once the thing works. This is very bad, and I
very much regret the slowness of the synthesis process, given that C code
that mimics similar VHDL code can be compiled and debugged so quickly.
I wonder whether there's a way to speed the design process up.
Simulation seems not the answer, since you still need to write
testbenches for simulation, and it is hard to test manually.
For example a simulator will not show you LED outputs
directly as they would appear on a board, nor can it
take input directly from a PS/2 keyboard. THIS, is
the major drawback of the VHDL design process, and
this is precisely why coding in VHDL takes an
unnecessarily long time!

Best Regards,

Thanks!

Neil

Neil Zanella

Jim Lewis <> wrote in message news:<>...
> > However, the rules for synthesis are not so clear cut, especially in
> > cases like yours (removing clr and pr from the sensitivity list) where
> > the desired behavior is a bit ambiguous. When you write code in odd
> > ways, different synthesis tools might implement it in slightly different
> > ways.
>
> WRT synthesis behavior, IEEE 1076.6-200X (currently in ballot)
> will require compliant synthesis tools to generate an error
> if a full sensitivity list is not provided for combinational
> and latch type logic.
>
> If you want consistent behavior between different synthesis
> tools, make sure to let you synthesis tool vendor you
> want them to support IEEE 1076.6-200X (will be either 2003 or
> 2004). Note you need to do this because to a vendor, support
> of a standard is an investment and a business decision.
> If you don't express your interest, they will not make the
> investment.

It seems quite clear to me that vendors that will support the standard will
hold a competitive advantage over the others. Eventually, synthesizers that
do not comply with the standard will be regarded by the VHDL community as
being broken. Conesquently, any customers choosing between a noncompliant
synthesizer and a compliant one will choose the compliant one. Not only
is a compliant synthesizer well-behaved. Compliant code is also more
portable across design tools, and this is precisely one of the main
driving forces behind the design of the VHDL language itself. There
were portability problems across tools, and VHDL sought to put an
end to those problems. Expect vendors of non compliant synthesizers
to get a lot of rants from the VHDL community and a bad name. Any
noncompliant synthesizer for which the corresponding vendor does
not aim at correcting the problem in future releases might as
well be ditched. And competition will arise not only due to
supported hardware, but also based on the degree of compliancy.
Some companies will opt for a narrower range of hardware so long
as standard VHDL can be used. More designers will be focusing on
and learning standard VHDL features than nonstandard one, as is
already the case in just about any other language that has been
standardized. In general, vendor specific quirks are frowned
upon in the software community, as is the case with, as an
obvious example, the much hated incompatibilities between
netscape and internet explorer html extensions, just to
mention the obvious. Then comes the W3C and its web
standard, and all this incompatibility junk starts
to disappear. And I would expect the same to happen
with VHDL, and the faster this happens, the better.

And then, the authors of VHDL books will have a clearer
picture of what they need to write in order to explain
synthesis better, based on the new standard, and we will
start seeing more press releases dealing with synthesis
as opposed with just plain syntax and some simulation
aspects which do not clearly translate to synthesis.

Regards,

Neil

Neil Zanella

"Jim Wu" <> wrote in message news:<JrZCb.6302$>...
> > process (clr_l, clr, pr_l, pr, clk) is
> > begin
> > pr <= not pr_l; clr <= not clr_l;
> > if (clr and pr) = '1' then q <= '0'; qn <= '0';
> > elsif clr = '1' then q <= '0'; qn <= '1';
> > elsif pr = 'q' then q <= '1; qn <= '0';
> > elsif rising_edge(clk) then q <= d; qn <= not d;
> > end if;
> > end process;
>
> This example code really combines the following two processes into one, so
> all the signals in the sensitivity lists of the two processes need to be
> included in the one process shown above.

So what is the advantage of using two processes over using ones. What are
the pros and cons of using one style as opposed to the other? Which is
the more commonly used approach and why? Which one is better? Which
one is easier to understand? Which approach lends itself to handier
code modification and maintenance?

Thanks,

Neil

> process (clr_l, pr_l) is
> begin
> pr <= not pr_l; clr <= not clr_l;
> end process;
>
> process (clr, pr, clk) is
> begin
> if (clr and pr) = '1' then q <= '0'; qn <= '0';
> elsif clr = '1' then q <= '0'; qn <= '1';
> elsif pr = 'q' then q <= '1; qn <= '0';
> elsif rising_edge(clk) then q <= d; qn <= not d;
> end if;
> end process;
>
> Jim Wu
> (remove capital letters)
> http://www.geocities.com/jimwu88/chips

Neil Zanella