redundant signals in sensitivity list?

[Neil Zanella]

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]

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" <nzanella@cs.mun.ca> schreef in bericht
newsine.LNX.4.44.0312130600220.9271-100000@garfield.cs.mun.ca...

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]

Thank you for your reply...

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

"Egbert Molenkamp" <molenkam_no_spam@cs.utwente.nl> 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" <nzanella@cs.mun.ca> schreef in bericht
newsine.LNX.4.44.0312130600220.9271-100000@garfield.cs.mun.ca...

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]

"Neil Zanella" <nzanella@cs.mun.ca> schreef in bericht
news:b68d2f19.0312132359.6dd08461@posting.google.com...

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

 

[Jim Wu]

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
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips

 

[Duane Clark]

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).

 

[Jim Lewis]

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 mailto:Jim@SynthWorks.com
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.

 

[Neil Zanella]

"Egbert Molenkamp" <molenkam_no_spam@cs.utwente.nl> wrote in message news:<brhj0e$7h8$1@ares.cs.utwente.nl>...

"Neil Zanella" <nzanella@cs.mun.ca> schreef in bericht
news:b68d2f19.0312132359.6dd08461@posting.google.com...
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 <Jim@SynthWorks.com> wrote in message news:<vtpeo4chrovs2a@corp.supernews.com>...

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" <jimwu88NOOOSPAM@yahoo.com> wrote in message news:<JrZCb.6302$w23.6003@nwrdny02.gnilink.net>...

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
jimwu88NOOOSPAM@yahoo.com (remove capital letters)
http://www.geocities.com/jimwu88/chips

 

[Egbert Molenkamp]

"Neil Zanella" <nzanella@cs.mun.ca> wrote in message
news:b68d2f19.0312152304.55c72bdb@posting.google.com...

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... (?)

In 1997 we had a paper on the sensitity list and synthesis. It is a long
time ago but maybe you enjoy reading it:
http://wwwhome.cs.utwente.nl/~molenkam/p.ps

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.

The VHDL courses I organize I start almost immediatly with the simulation
model of VHDL.
(also in my book, in dutch I'm sorry, I discuss this subject on page 9
http://wwwhome.cs.utwente.nl/~molenkam/DownloadVhdlBoek.htm)

After that I tell about nice features of VHDL.
In the synthesis part I again start with very simple examples that shows how
a synthesis handles VHDL with respect to signal and variable assigments.
However with some pitfalls, e.g. the sensitivity list .. But nevertheless
synthesis tools do a nice job. If the simulation model is known the
synthesis result is not a surprise (although .. synthesis tools .. that is
software .. and software without errors is seldom ).

I feel that books do not satisfactorily
describe the pitfalls of VHDL when
compared to other programming

Well a long time ago Joseph R Pick wrote a nice book. A long time ago so it
uses VHDL'87
but maybe you enjoy reading it (if it still available):
Vhdl Techniques Experiments and Caveats; McGraw - Hill
The book is about simulation (LRM-VHDL), I don't think it includes synthesis
pitfalls, I'm not sure here.

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???

I'm not quite sure when I used VHDL synthesis the first time: 1991?
At that time you had to tell the tool exactly what you want.
VHDL language support was very poor, e.g.
Integer range was not supported. So if you had a counter counting from 0
till 9
you could NOT write:
variable cnt : integer range 0 to 9; (resulting in 4 bits)
but you had to write:
variable cnt : integer; => (32 bits!!).
This means writing it all at the bit level. (At that time I used
'vlbit_vector'.
Each company had its own multi value logic. Nowadays we all use
std_logic_vector
(and with the package numeric_std also unsigend and signed))

The synthesis tool really made progress since then.
In the mean time also there are also IEEE activitites ont this subject
see www.eda.org; e.g the 1076.6 VHDL Synthesis Interoperability Working
Group.

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.

Maybe the integration of PSL into VHDL (and other languages) can help here.
You still need simulation but you can include properties in your design.
See: http://www.accellera.org
Ben Cohen has written a book "Using PSL/Sugar with Verilog and VHDL".

Egbert Molenkamp

 

[fe]

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?

In one process, the assignments
pr <= not pr_l; clr <= not clr_l;
will be executed each time clr_l, clr, pr_l, pr, clk change.
In two processes, they will be executed only when clr_l, pr_l changed. So a
time simulation's gain (faster).

You shouldn't use combinatorial signal assignment and clocked signal
assignment in the same process because it's harder to understand and slower
in simulation.

BTW, use variables for locally equations (if it needs), don't use too much
signal for nothing. Signals slowdown simulation and use more computer's
memory than variables in simulation.

for one dff with clear, preset, q and qn :

process (clr_l, pr_l, clk) is
begin
if clr_l = '0' then q <= '0';
elsif pr_l = '0' then q <= '1;
elsif rising_edge(clk) then q <= d;
end if;
end process;
qn <= not q; -- q must be a signal, not an output port

or

process (clr_l, pr_l, clk) is
variable v_q : std_logic;
begin
if clr_l = '0' then v_q := '0';
elsif pr_l = '0' then v_q := '1;
elsif rising_edge(clk) then v_q := d;
end if;
q <= v_q; -- q can be an output port or a signal
qn <= not v_q;
end process;

regards
Pat

 

[Duane Clark]

Neil Zanella wrote:

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?

I'll just say that in cases like this, I generally like to arrange the
statements in a way that makes clear what executes when. So I would have
rearranged the code like this. It has no effect the simulation or
synthesis results, but clearly shows the expected operation.

process (clr_l, clr, pr_l, 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;
pr <= not pr_l; clr <= not clr_l; -- statement put at end
end process;


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

 

[Jim Lewis]

fe wrote:

or

process (clr_l, pr_l, clk) is
variable v_q : std_logic;
begin
if clr_l = '0' then v_q := '0';
elsif pr_l = '0' then v_q := '1;
elsif rising_edge(clk) then v_q := d;
end if;
q <= v_q; -- q can be an output port or a signal
qn <= not v_q;
end process;

I would not recommend this last example as some synthesis
tools have the habit of creating a separate register for
each signal assignment in a clocked process. As a result,
it is possible to get two registers, one for Q one for Qn.

I recommend putting the assignment to Qn outside of the
process as shown in Pat's first example.

Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Mike Treseler]

Jim Lewis wrote:

fe wrote:

or

process (clr_l, pr_l, clk) is
variable v_q : std_logic;
begin
if clr_l = '0' then v_q := '0';
elsif pr_l = '0' then v_q := '1'; -- added a '
elsif rising_edge(clk) then v_q := d;
end if;
q <= v_q; -- q can be an output port or a signal
qn <= not v_q;
end process;



I would not recommend this last example as some synthesis
tools have the habit of creating a separate register for
each signal assignment in a clocked process. As a result,
it is possible to get two registers, one for Q one for Qn.

Pat's code made a single register
and no warnings using either Leo 2003
or Quartus 3.0 for synthesis.

Pat's use of a variable clarifies the code for me.

Anyone have another outcome?

-- Mike Treseler

 

[Jim Wu]

So what is the advantage of using two processes over using ones.

Obviously you don't have to type as much when combining two processes into
one. Sometimes it is easier to read and understand if you group similiar
signals into one process.

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?

I think it's really a personal preference of which style is better. But I
would not combine a sequential process and combinational process together as
shown in your example.

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