Coding style, wait statement, sensitivity list and synthesis.

Discussion in 'VHDL' started by AG, Dec 14, 2005.

  1. AG

    AG Guest

    Hi,

    I am new in vhdl.

    In my book, the following code is given :

    entity LATCH ....
    end entity;

    architecture A of LATCH is
    begin
    process
    begin
    if CK='1' then
    Q <= D;
    QB <= not D;
    end if;
    wait on CK,D; -- compiler error
    end process;
    end A;

    Compilier says during elaboration :
    'Wait Statement must contain condition clause with UNTIL keyword'

    If I use the sensitivity list instead, the problem disappears. (except the
    fact that the behavior is not strictly equivalent).

    In my book, it says that using "sensitivity list" is an old fashion way of
    coding, and using the wait statement is better (more generic). Who should I
    believe ?

    This leads me to the following question : if not all vhdl statement are
    valid, how do I write portable vhdl so that it can be compiled on several
    targets ?

    I use Quartus II web free edition.

    Thanks.

    Heydji.
     
    AG, Dec 14, 2005
    #1
    1. Advertising

  2. AG ha scritto:
    > Hi,
    >
    > I am new in vhdl.
    >
    > In my book, the following code is given :
    >
    > entity LATCH ....
    > end entity;
    >
    > architecture A of LATCH is
    > begin
    > process
    > begin
    > if CK='1' then
    > Q <= D;
    > QB <= not D;
    > end if;
    > wait on CK,D; -- compiler error

    it is valid VHDL but
    it is the sythesis that failed, you try to build a 2-edge triggered
    clocks FF and this stuff doesnt exist in a FPGA.
    > end process;
    > end A;
    >



    > Compilier says during elaboration :
    > 'Wait Statement must contain condition clause with UNTIL keyword'
    >
    > If I use the sensitivity list instead, the problem disappears. (except the
    > fact that the behavior is not strictly equivalent).
    >
    > In my book, it says that using "sensitivity list" is an old fashion way of
    > coding, and using the wait statement is better (more generic). Who should I
    > believe ?


    What's the title of this book!?

    >
    > This leads me to the following question : if not all vhdl statement are
    > valid, how do I write portable vhdl so that it can be compiled on several
    > targets ?
    >
    > I use Quartus II web free edition.


    Important: Coding Vhdl not only mean synthesis but even simulation,
    verification, autodocumentation....
    >
    > Thanks.
    >
    > Heydji.
    >
    >
     
    antonio bergnoli, Dec 14, 2005
    #2
    1. Advertising

  3. AG

    Harpreet Guest

    Hello AG,

    Even I am new to VHDL but I did a course on it as part of my undergrad
    program recently.
    In my opinion, your problem is quite simple. You have a statement in
    your code "wait on D, CK", Now, according to this statement, the
    simulation won't progress until you have events on both the signals.
    However, putting them in the sensitivity list resolves your problem
    because the sensitivity list checks for events on any the arguments
    specified in it.

    Regarding the sensitivity list being an outdated way of coding, there
    might be debates on that. However, it goes without saying that wait
    statements are more popular state machine coding wise.

    I can't really answer your last query as I myself am novice in this
    field.

    Hope that helps.
    -Harpreet
     
    Harpreet, Dec 15, 2005
    #3
  4. AG

    AG Guest

    "Harpreet" <> a écrit dans le message de news:
    ...
    > In my opinion, your problem is quite simple. You have a statement in
    > your code "wait on D, CK", Now, according to this statement, the
    > simulation won't progress until you have events on both the signals.
    > However, putting them in the sensitivity list resolves your problem
    > because the sensitivity list checks for events on any the arguments
    > specified in it.

    Sure, but why the "wait on D,CK" can't be synthesised while the same
    behavior with the sensitivity list way can.

    Antonio says it's because a "wait on D,CK" statement corresponds to a 2-edge
    triggered clocks which doesn't exist in FPGA. But how does the synthesis do
    to build the equivalent with the sensitivity list ?

    Adji.
     
    AG, Dec 15, 2005
    #4
  5. AG a écrit:
    > Sure, but why the "wait on D,CK" can't be synthesised while the same
    > behavior with the sensitivity list way can.
    > Antonio says it's because a "wait on D,CK" statement corresponds to a 2-edge
    > triggered clocks which doesn't exist in FPGA. But how does the synthesis do
    > to build the equivalent with the sensitivity list ?


    Hi
    The "wait on d, ck;" statement is strictly equivalent to a sensitivity
    list. It does _not_ imply a 2-edge triggered FF or anything, and it
    doesn't wait for activity on both signals either.
    All synthesis tools do not support 100% of the sythesizable subset of
    the language. You sometimes find that what worked with some tool does
    not with another.
    It seems that QII does not support your wait statement, well, don't use
    it and go with a sensitivity list instead.
    And for your book's statement about sensitivity list, my opinion is
    that it is utterly wrong.
    What book is it?

    Nicolas
     
    Nicolas Matringe, Dec 15, 2005
    #5
  6. AG

    AG Guest


    >And for your book's statement about sensitivity list, my opinion is
    >that it is utterly wrong.
    >What book is it?

    Some french book. Probably a bad one. I have ordered a better one.

    Thanks anyway.
     
    AG, Dec 15, 2005
    #6
  7. Nicolas Matringe ha scritto:
    > AG a écrit:
    >
    >>Sure, but why the "wait on D,CK" can't be synthesised while the same
    >>behavior with the sensitivity list way can.
    >>Antonio says it's because a "wait on D,CK" statement corresponds to a 2-edge
    >>triggered clocks which doesn't exist in FPGA. But how does the synthesis do
    >>to build the equivalent with the sensitivity list ?

    >
    >
    > Hi
    > The "wait on d, ck;" statement is strictly equivalent to a sensitivity
    > list. It does _not_ imply a 2-edge triggered FF or anything, and it
    > doesn't wait for activity on both signals either.

    Yes Nicolas, you're definitively right. Rereading now what i wrote
    yesterday i recognize that i said a silly thing. But the statement "wait
    on..." is not completely equivalent to put a sensitivity list, this is
    true only if "wait on..." is the first statement after "begin" process.
    Or i'm going wrong again?
    > All synthesis tools do not support 100% of the sythesizable subset of
    > the language. You sometimes find that what worked with some tool does
    > not with another.
    > It seems that QII does not support your wait statement, well, don't use
    > it and go with a sensitivity list instead.
    > And for your book's statement about sensitivity list, my opinion is
    > that it is utterly wrong.
    > What book is it?
    >
    > Nicolas
    >
     
    antonio bergnoli, Dec 15, 2005
    #7
  8. AG a écrit:
    > Some french book. Probably a bad one.


    I know a few (being french myself :eek:), which one is it?

    Nicolas
     
    Nicolas Matringe, Dec 15, 2005
    #8
  9. antonio bergnoli a écrit:
    > But the statement "wait on..." is not completely equivalent to
    > put a sensitivity list, this is true only if "wait on..." is the first
    > statement after "begin" process. Or i'm going wrong again?


    I think you're right, actually.
    It doesn't make big difference except at first simulation cycle where
    the process with the 'wait on' at the end is executed and the two
    others are not.

    Nicolas
     
    Nicolas Matringe, Dec 15, 2005
    #9
  10. AG

    AG Guest

    "Nicolas Matringe" <> a écrit dans le message de news:
    > I know a few (being french myself :eek:), which one is it?


    VHDL du langage a la modélisation
     
    AG, Dec 15, 2005
    #10
  11. Nicolas Matringe wrote:

    > It seems that QII does not support your wait statement, well, don't use
    > it and go with a sensitivity list instead.


    Leo synthesizes the OP's code correctly without complaint.
    Quartus is unhappy first with the entity name "LATCH"
    which is reserved. Once I fix that, I get
    the same error message as the OP. Once I fix
    that using process(CK,D) it works fine:
    http://home.comcast.net/~mike_treseler/latch.pdf

    > And for your book's statement about sensitivity list, my opinion is
    > that it is utterly wrong.


    Yes, the list format has much better support,
    but note that leo can go either way.
    The wait style process better matches
    how the language works, but the list style
    is much better for reuse.

    The OP should note that synthesis of a latch
    is only a good idea for educational purposes.
    process(reset, clock) is a more practical start
    for useful synthesis.

    -- Mike Treseler
     
    Mike Treseler, Dec 15, 2005
    #11
  12. AG a écrit:
    > VHDL du langage a la modélisation


    1990
    A bit outdated maybe...

    Nicolas
     
    Nicolas Matringe, Dec 16, 2005
    #12
  13. AG

    AG Guest

    > The OP should note that synthesis of a latch
    > is only a good idea for educational purposes.
    > process(reset, clock) is a more practical start
    > for useful synthesis.
    >
    > -- Mike Treseler


    Thank you Mike. The OP is learning VHDL, indeed.
     
    AG, Dec 19, 2005
    #13
  14. AG

    Rob Dekker Guest

    Hi Mike, AG,

    I wrote the VHDL synthesis front-end for both Leonardo (when at Exemplar) and Quartus (when at Verific),
    so I feel somewhat responsible for this thread... :eek:)

    Indeed the 'on' clause in a wait statement is identical to a sensitivity list on the process
    (apart from the initialization run through the process), so we should really allow it for synthesis.

    I will remove this test in future releases, also because it is a cosmetic test :
    Ignoring the message would allow normal combinational synthesis of the process to be done
    (which will result in a latch in this case).

    Verific exports a feature to downgrade any errors to warnings at run time,
    and if Altera exports this feature in Quartus, you might want to use that (I'm not sure if they do).

    Apologies for this inconsistency in VHDL synthesis front-ends.

    Rob


    "Mike Treseler" <> wrote in message news:...
    > Nicolas Matringe wrote:
    >
    >> It seems that QII does not support your wait statement, well, don't use
    >> it and go with a sensitivity list instead.

    >
    > Leo synthesizes the OP's code correctly without complaint.
    > Quartus is unhappy first with the entity name "LATCH"
    > which is reserved. Once I fix that, I get
    > the same error message as the OP. Once I fix
    > that using process(CK,D) it works fine:
    > http://home.comcast.net/~mike_treseler/latch.pdf
    >
    >> And for your book's statement about sensitivity list, my opinion is
    >> that it is utterly wrong.

    >
    > Yes, the list format has much better support,
    > but note that leo can go either way.
    > The wait style process better matches
    > how the language works, but the list style
    > is much better for reuse.
    >
    > The OP should note that synthesis of a latch
    > is only a good idea for educational purposes.
    > process(reset, clock) is a more practical start
    > for useful synthesis.
    >
    > -- Mike Treseler
     
    Rob Dekker, Dec 23, 2005
    #14
  15. AG

    Jim Lewis Guest

    Rob,
    So what you propose is that synthesis tools should
    accept the following:
    sen_list_equiv : process
    begin
    if CK='1' then
    Q <= D;
    QB <= not D;
    end if;
    wait on CK,D;
    end process;

    Will you also support the following hardware equivalent
    process:
    hardware_equiv: process
    begin
    wait on CK,D;
    if CK='1' then
    Q <= D;
    QB <= not D;
    end if;
    end process;

    Can I put the "wait on" anywhere else?
    Can I have multiple "wait on" in the process?

    Can I have one wait on at the end of each
    path through the process (which is also similar
    to a sensitivity list):

    also_sen_list_equiv : process
    begin
    if CK='1' then
    Q <= D;
    QB <= not D;
    wait on CK,D;
    else
    wait on CK,D;
    end if;
    end process;

    It is great to make enhancements, but hopefully
    at the same time you can keep the rules simple.

    You will note that there are other valuable features
    that are in 1076.6-2004, such as multiple edge
    registers that I would consider higher priority than
    yet another way to do a sensitivity list.

    Cheers,
    Jim


    > Hi Mike, AG,
    >
    > I wrote the VHDL synthesis front-end for both Leonardo (when at Exemplar) and Quartus (when at Verific),
    > so I feel somewhat responsible for this thread... :eek:)
    >
    > Indeed the 'on' clause in a wait statement is identical to a sensitivity list on the process
    > (apart from the initialization run through the process), so we should really allow it for synthesis.
    >
    > I will remove this test in future releases, also because it is a cosmetic test :
    > Ignoring the message would allow normal combinational synthesis of the process to be done
    > (which will result in a latch in this case).
    >
    > Verific exports a feature to downgrade any errors to warnings at run time,
    > and if Altera exports this feature in Quartus, you might want to use that (I'm not sure if they do).
    >
    > Apologies for this inconsistency in VHDL synthesis front-ends.
    >
    > Rob
    >
    >
    > "Mike Treseler" <> wrote in message news:...
    >
    >>Nicolas Matringe wrote:
    >>
    >>
    >>>It seems that QII does not support your wait statement, well, don't use
    >>>it and go with a sensitivity list instead.

    >>
    >>Leo synthesizes the OP's code correctly without complaint.
    >>Quartus is unhappy first with the entity name "LATCH"
    >>which is reserved. Once I fix that, I get
    >>the same error message as the OP. Once I fix
    >>that using process(CK,D) it works fine:
    >>http://home.comcast.net/~mike_treseler/latch.pdf
    >>
    >>
    >>>And for your book's statement about sensitivity list, my opinion is
    >>>that it is utterly wrong.

    >>
    >>Yes, the list format has much better support,
    >>but note that leo can go either way.
    >>The wait style process better matches
    >>how the language works, but the list style
    >>is much better for reuse.
    >>
    >>The OP should note that synthesis of a latch
    >>is only a good idea for educational purposes.
    >>process(reset, clock) is a more practical start
    >>for useful synthesis.
    >>
    >> -- Mike Treseler

    >
    >
    >



    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    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 23, 2005
    #15
  16. AG

    Rob Dekker Guest

    Hi Jim,

    "Jim Lewis" <> wrote in message news:...
    > Rob,
    > So what you propose is that synthesis tools should
    > accept the following:
    > sen_list_equiv : process
    > begin
    > if CK='1' then
    > Q <= D;
    > QB <= not D;
    > end if;
    > wait on CK,D;
    > end process;


    Yes.

    >
    > Will you also support the following hardware equivalent
    > process:
    > hardware_equiv: process
    > begin
    > wait on CK,D;
    > if CK='1' then
    > Q <= D;
    > QB <= not D;
    > end if;
    > end process;


    Yes.

    >
    > Can I put the "wait on" anywhere else?


    Yes, but that might have functional implications (the function might change).
    This example :

    process begin
    <statement1>
    wait on CK,D;
    <statement2>
    end process

    is functionally equivalent to this process :

    process begin
    wait on CK,D;
    <statement2>
    <statement1>
    end process

    note that the order of the statements in flipped !
    That is because the wait statement determines when the simulator 'stops' updating the drivers.
    This change in ordering should be supported by the synthesis tool (and it is in Verific, if we only
    downgraded the current error).

    > Can I have multiple "wait on" in the process?


    You can in some synthesis tools, but Verific does not support multiple wait statements in one process.

    >
    > Can I have one wait on at the end of each
    > path through the process (which is also similar
    > to a sensitivity list):
    >
    > also_sen_list_equiv : process
    > begin
    > if CK='1' then
    > Q <= D;
    > QB <= not D;
    > wait on CK,D;
    > else
    > wait on CK,D;
    > end if;
    > end process;


    In prociple, we could support this, since it is similar to a single wait at the end of
    the process. However, just to be on the safe side, synthesis tools not supporting
    multiple waits per process might error out.

    >
    > It is great to make enhancements, but hopefully
    > at the same time you can keep the rules simple.


    Simple rule that I used to use :
    A process can have only one wait statement, and it needs an 'until' clause.

    Simple rule that I will use :
    A process can have only one wait statement.

    >
    > You will note that there are other valuable features
    > that are in 1076.6-2004, such as multiple edge
    > registers that I would consider higher priority than
    > yet another way to do a sensitivity list.


    Interesting, I just investigated this last month :
    I personally find the 'multiple edge' feature in 1076.6 extremely confusing, and potentially incorrect.

    The example given in 1076.6 is this :
    Example 1:

    process (reset, clk1, clk2) begin
    if (reset) then
    Q <= '0' ;
    elsif rising_edge(clk1) then
    Q <= data1 ;
    elsif rising_edge(clk2) then
    Q <= data2 ;
    end if ;
    end

    Clearly, no hardware element (that I am aware of) can update its output on multiple rising edges,
    so you should get a synthesis error.
    But 1076.6 now proposes to accept this style, and that we should ignore the second (clk2) edge.
    So, a Flip-flop should be synthesized which triggers on 'clk1' only.

    I find that very uncomforting, because there will at least be big-time simulation-synthesis differences.

    Now lets look at a similar, but different example (not in the 1076.6 LRM) :
    Example 2:

    process (reset, clk1, clk2) begin
    if (reset) then
    Q1 <= '0' ;
    Q2 <= '0' ;
    elsif rising_edge(clk1) then
    Q1 <= data1 ;
    elsif rising_edge(clk2) then
    Q2 <= data2 ;
    end if ;
    end

    This should in prociple be synthesizable (without risking simulation/synthesis differences), with two flip-flops :
    Q1 clocked on clk1 and Q2 clocked on clk2. The only assumption is that the two clock edges
    do not occur simultaniously (which is a very light assumption, considering delta-time event driven simulators,
    and even 1076.6 states that this assumption can be made).

    However, if we follow the 1076.6 rule, this process should ignore the second edge :
    (6.1.3.3, Note 2: "The determination of the functional clock is made on a process-by-process basis; the
    intended clock has to be coded first in each process").
    So the (one and only) functional clock should be determined per process, and not per signal.

    That is an incorrect rule !
    It tells us that we should ignore clk2 in example 2, and thus Q2 will not be clocked.
    And that is just plain wrong.

    So, I would recommend NOT promoting this 1076.6 rule.
    Verific will continue to error out on example1. It is really not synthesizable.

    Just stick with a single clock per process, since that is supported by every vendor,
    prevents any simulation-synthesis mismatch and does not violate any 1076.6 rules.

    >
    > Cheers,
    > Jim
    >
    >
    >> Hi Mike, AG,
    >>
    >> I wrote the VHDL synthesis front-end for both Leonardo (when at Exemplar) and Quartus (when at Verific),
    >> so I feel somewhat responsible for this thread... :eek:)
    >>
    >> Indeed the 'on' clause in a wait statement is identical to a sensitivity list on the process
    >> (apart from the initialization run through the process), so we should really allow it for synthesis.
    >>
    >> I will remove this test in future releases, also because it is a cosmetic test :
    >> Ignoring the message would allow normal combinational synthesis of the process to be done
    >> (which will result in a latch in this case).
    >>
    >> Verific exports a feature to downgrade any errors to warnings at run time,
    >> and if Altera exports this feature in Quartus, you might want to use that (I'm not sure if they do).
    >>
    >> Apologies for this inconsistency in VHDL synthesis front-ends.
    >>
    >> Rob
    >>
    >>
    >> "Mike Treseler" <> wrote in message news:...
    >>
    >>>Nicolas Matringe wrote:
    >>>
    >>>
    >>>>It seems that QII does not support your wait statement, well, don't use
    >>>>it and go with a sensitivity list instead.
    >>>
    >>>Leo synthesizes the OP's code correctly without complaint.
    >>>Quartus is unhappy first with the entity name "LATCH"
    >>>which is reserved. Once I fix that, I get
    >>>the same error message as the OP. Once I fix
    >>>that using process(CK,D) it works fine:
    >>>http://home.comcast.net/~mike_treseler/latch.pdf
    >>>
    >>>
    >>>>And for your book's statement about sensitivity list, my opinion is
    >>>>that it is utterly wrong.
    >>>
    >>>Yes, the list format has much better support,
    >>>but note that leo can go either way.
    >>>The wait style process better matches
    >>>how the language works, but the list style
    >>>is much better for reuse.
    >>>
    >>>The OP should note that synthesis of a latch
    >>>is only a good idea for educational purposes.
    >>>process(reset, clock) is a more practical start
    >>>for useful synthesis.
    >>>
    >>> -- Mike Treseler

    >>
    >>
    >>

    >
    >
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > 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
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Rob Dekker, Dec 23, 2005
    #16
  17. AG

    Dave Higton Guest

    In message <xpZqf.44317$>
    "Rob Dekker" <> wrote:

    > I personally find the 'multiple edge' feature in 1076.6 extremely
    > confusing, and potentially incorrect.
    >
    > The example given in 1076.6 is this :
    > Example 1:
    >
    > process (reset, clk1, clk2) begin
    > if (reset) then
    > Q <= '0' ;
    > elsif rising_edge(clk1) then
    > Q <= data1 ;
    > elsif rising_edge(clk2) then
    > Q <= data2 ;
    > end if ;
    > end
    >
    > Clearly, no hardware element (that I am aware of) can update its output on
    > multiple rising edges, so you should get a synthesis error.


    OK, I'll bite:

    I think you can synthesise this "element" from 4 D-types, one S-R
    latch and a 2-input multiplexer. You use 1 D-type to register data1
    from clk1, another to register data2 from clk2; then you use 2
    D-types and the S-R latch to detect which edge, clk1 or clk2, was
    most recent, and switch the multiplexer's output appropriately.

    It depends on what you define as an element - also on whether I'm
    right about the functionality above.

    Dave
     
    Dave Higton, Dec 23, 2005
    #17
  18. Rob Dekker wrote:

    > I wrote the VHDL synthesis front-end for both Leonardo (when at Exemplar) and Quartus (when at Verific),
    > so I feel somewhat responsible for this thread... :eek:)


    Thanks for the posting, and for your
    concern about the standards.
    It is a rare event to get info
    right from the horse's mouth!

    > Indeed the 'on' clause in a wait statement is identical to a sensitivity list on the process
    > (apart from the initialization run through the process), so we should really allow it for synthesis.


    If the "wait on foo" is at the end of the process,
    it is exactly the same as process(foo) at the top.
    See:
    http://groups.google.com/groups?q=wait statement Menchini Sinha

    -- Mike Treseler
     
    Mike Treseler, Dec 23, 2005
    #18
  19. AG

    Rob Dekker Guest

    "Dave Higton" <> wrote in message news:...
    > In message <xpZqf.44317$>
    > "Rob Dekker" <> wrote:
    >
    >> I personally find the 'multiple edge' feature in 1076.6 extremely
    >> confusing, and potentially incorrect.
    >>
    >> The example given in 1076.6 is this :
    >> Example 1:
    >>
    >> process (reset, clk1, clk2) begin
    >> if (reset) then
    >> Q <= '0' ;
    >> elsif rising_edge(clk1) then
    >> Q <= data1 ;
    >> elsif rising_edge(clk2) then
    >> Q <= data2 ;
    >> end if ;
    >> end
    >>
    >> Clearly, no hardware element (that I am aware of) can update its output on
    >> multiple rising edges, so you should get a synthesis error.

    >
    > OK, I'll bite:
    >
    > I think you can synthesise this "element" from 4 D-types, one S-R
    > latch and a 2-input multiplexer. You use 1 D-type to register data1
    > from clk1, another to register data2 from clk2; then you use 2
    > D-types and the S-R latch to detect which edge, clk1 or clk2, was
    > most recent, and switch the multiplexer's output appropriately.
    >
    > It depends on what you define as an element - also on whether I'm
    > right about the functionality above.
    >
    > Dave


    That is creative, and indeed at first glance your trick should work.

    Two remarks :
    (1) Note that 1076.6 does NOT define that we should mimic the Verilog
    behavior (with whatever hardware we can). Instead, they say that we should
    use a normal DFF, and ignore the second clock !

    (2) I am not sure if a Verilog designer would really want to see such
    odd hardware being created. It is more likely that this designer is
    more of a newbie in RTL Verilog modeling, and therefor it might be
    more appropriate to issue an error any way.
    A very experiences designer willing to risk the hardware implications
    could always do hard gate-instantiations to achieve the exact hardware
    they deem necessary. But create this from benign looking piece of
    Verilog at least unorthodox, and somewhat misleading.
    Similar to accepting a division operator "/" on two 48 bit variables...
    and creating the massive amount of hardware that goes with that.
    Part of the task of RTL synthesis tools is to make designers aware
    (sometimes painfullly aware) when they do something that would create
    very unorthodox (amounts) of hardware.

    Rob
     
    Rob Dekker, Dec 23, 2005
    #19
  20. AG

    Dave Higton Guest

    In message <QK%qf.39240$q%>
    "Rob Dekker" <> wrote:

    >
    > "Dave Higton" <> wrote in message
    > news:...
    > > In message <xpZqf.44317$>
    > > "Rob Dekker" <> wrote:
    > >
    > >> I personally find the 'multiple edge' feature in 1076.6 extremely
    > >> confusing, and potentially incorrect.
    > >>
    > >> The example given in 1076.6 is this :
    > >> Example 1:
    > >>
    > >> process (reset, clk1, clk2) begin
    > >> if (reset) then
    > >> Q <= '0' ;
    > >> elsif rising_edge(clk1) then
    > >> Q <= data1 ;
    > >> elsif rising_edge(clk2) then
    > >> Q <= data2 ;
    > >> end if ;
    > >> end
    > >>
    > > > Clearly, no hardware element (that I am aware of) can update its output
    > > > on multiple rising edges, so you should get a synthesis error.

    > >
    > > OK, I'll bite:
    > >
    > > I think you can synthesise this "element" from 4 D-types, one S-R
    > > latch and a 2-input multiplexer. You use 1 D-type to register data1
    > > from clk1, another to register data2 from clk2; then you use 2
    > > D-types and the S-R latch to detect which edge, clk1 or clk2, was
    > > most recent, and switch the multiplexer's output appropriately.
    > >
    > > It depends on what you define as an element - also on whether I'm
    > > right about the functionality above.
    > >
    > > Dave

    >
    > That is creative, and indeed at first glance your trick should work.
    >
    > Two remarks :
    > (1) Note that 1076.6 does NOT define that we should mimic the Verilog
    > behavior (with whatever hardware we can). Instead, they say that we should
    > use a normal DFF, and ignore the second clock !
    >
    > (2) I am not sure if a Verilog designer would really want to see such
    > odd hardware being created. It is more likely that this designer is
    > more of a newbie in RTL Verilog modeling, and therefor it might be
    > more appropriate to issue an error any way.
    > A very experiences designer willing to risk the hardware implications
    > could always do hard gate-instantiations to achieve the exact hardware
    > they deem necessary. But create this from benign looking piece of
    > Verilog at least unorthodox, and somewhat misleading.
    > Similar to accepting a division operator "/" on two 48 bit variables...
    > and creating the massive amount of hardware that goes with that.
    > Part of the task of RTL synthesis tools is to make designers aware
    > (sometimes painfullly aware) when they do something that would create
    > very unorthodox (amounts) of hardware.


    There are a couple of things that I find interesting:

    1) The topic of flip-flops triggered from multiple edges keeps cropping
    up here. I'm inclined to the view that at least some of those people
    know what they're asking for.

    2) I think there's a whole family of flip-flops triggered from
    multiple edges. I feel sure that the scheme I put forward above
    can be extended to an arbitrary number of inputs. There is also
    the simple FF with one clock and one D input that registers on both
    rising and falling edges; this is the one that's most commonly
    requested, I think. There exist at least two implementations
    of it.

    Dave
     
    Dave Higton, Dec 25, 2005
    #20
    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:
    4
    Views:
    2,175
    Ralf Hildebrandt
    Sep 8, 2003
  2. walala
    Replies:
    4
    Views:
    1,269
    Technology Consultant
    Sep 9, 2003
  3. Elinore
    Replies:
    6
    Views:
    5,582
    Ahmed Samieh
    Jun 10, 2007
  4. calmar
    Replies:
    11
    Views:
    952
    calmar
    Feb 21, 2006
  5. Markus Jochim
    Replies:
    3
    Views:
    2,569
    HT-Lab
    Jun 1, 2007
Loading...

Share This Page