redundant signals in sensitivity list?

Discussion in 'VHDL' started by Neil Zanella, Dec 13, 2003.

  1. Neil Zanella

    Neil Zanella Guest

    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, Dec 13, 2003
    #1
    1. Advertising

  2. 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
    news:p...
    >
    > 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, Dec 13, 2003
    #2
    1. Advertising

  3. Neil Zanella

    Neil Zanella Guest

    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
    > news:p...
    > >
    > > 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, Dec 14, 2003
    #3
  4. "Neil Zanella" <> schreef in bericht
    news:...
    > 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, Dec 14, 2003
    #4
  5. Neil Zanella

    Jim Wu Guest


    > 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, Dec 14, 2003
    #5
  6. Neil Zanella

    Duane Clark Guest

    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, Dec 14, 2003
    #6
  7. Neil Zanella

    Jim Lewis Guest

    > 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:
    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, Dec 14, 2003
    #7
  8. Neil Zanella

    Neil Zanella Guest

    "Egbert Molenkamp" <> wrote in message news:<brhj0e$7h8$>...
    > "Neil Zanella" <> schreef in bericht
    > news:...
    > > 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, Dec 16, 2003
    #8
  9. Neil Zanella

    Neil Zanella Guest

    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, Dec 16, 2003
    #9
  10. Neil Zanella

    Neil Zanella Guest

    "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, Dec 16, 2003
    #10
  11. "Neil Zanella" <> wrote in message
    news:...
    > 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
     
    Egbert Molenkamp, Dec 16, 2003
    #11
  12. Neil Zanella

    fe Guest

    > 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
     
    fe, Dec 16, 2003
    #12
  13. Neil Zanella

    Duane Clark Guest

    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).
     
    Duane Clark, Dec 16, 2003
    #13
  14. Neil Zanella

    Jim Lewis Guest

    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:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Dec 16, 2003
    #14
  15. 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
     
    Mike Treseler, Dec 16, 2003
    #15
  16. Neil Zanella

    Jim Wu Guest

    > 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
    (remove capital letters)
    http://www.geocities.com/jimwu88/chips
     
    Jim Wu, Dec 18, 2003
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. walala
    Replies:
    3
    Views:
    761
    Allan Herriman
    Sep 9, 2003
  2. Roger Dahl
    Replies:
    10
    Views:
    825
    Mike Treseler
    Oct 3, 2003
  3. Eqbal

    sensitivity list

    Eqbal, Nov 18, 2003, in forum: VHDL
    Replies:
    2
    Views:
    611
    Herwig Dietl
    Nov 18, 2003
  4. antonio bergnoli
    Replies:
    5
    Views:
    4,522
    Mike Treseler
    Dec 18, 2005
  5. Steven Kauffmann
    Replies:
    21
    Views:
    2,706
    Ponceludon de Malavoy
    Jan 9, 2008
Loading...

Share This Page