data enable on a FF

Discussion in 'VHDL' started by Al, Nov 10, 2006.

  1. Al

    Al Guest

    Hi to all,
    writing some code I've noticed that to enable the data on a FF with the
    combination of two or more signals there are different ways of writing
    code (of course), which will turn in different implementation (maybe).
    I was wondering which is the difference between the following:

    -- first case
    process (clk, nrst)
    if nrst = '0' then
    A <= '0';
    if rising_edge (clk) then
    if enA_1 = '1' and enA_2 = '1' then
    A <= B;
    end if;
    end if;
    end process;

    -- second case
    process (clk, nrst)
    if nrst = '0' then
    A <= '0';
    if rising_edge (clk) then
    if enA_1 = '1' then
    if enA_2 = '1' then
    A <= B;
    end if;
    end if;
    end if;
    end process;

    I think there will be quite a big difference in the implementation: a
    combinational AND Cell and a sequential Cell will be implemented in the
    first case, while only a sequential Cell in the second case. Is this
    correct?
    My consideration is based on the Actel gate array layout, but I think
    the principle are the same for all the layouts (combinational and
    sequential Cells).
    Could you confirm this?

    Thanks a lot

    Al


    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Nov 10, 2006
    #1
    1. Advertising

  2. Al

    KJ Guest

    "Al" <> wrote in message
    news:ej1nks$lp8$...
    > Hi to all,
    > writing some code I've noticed that to enable the data on a FF with the
    > combination of two or more signals there are different ways of writing
    > code (of course), which will turn in different implementation (maybe).
    > I was wondering which is the difference between the following:
    >
    > -- first case
    > process (clk, nrst)
    > if nrst = '0' then
    > A <= '0';
    > if rising_edge (clk) then
    > if enA_1 = '1' and enA_2 = '1' then
    > A <= B;
    > end if;
    > end if;
    > end process;
    >
    > -- second case
    > process (clk, nrst)
    > if nrst = '0' then
    > A <= '0';
    > if rising_edge (clk) then
    > if enA_1 = '1' then
    > if enA_2 = '1' then
    > A <= B;
    > end if;
    > end if;
    > end if;
    > end process;
    >
    > I think there will be quite a big difference in the implementation: a
    > combinational AND Cell and a sequential Cell will be implemented in the
    > first case, while only a sequential Cell in the second case. Is this
    > correct?

    No, both will synthesize to the exact same thing. The synthesis process
    attempts to find the mimimal set of logic that is equivalent the original
    source code. Your two examples already are equivalent (i.e. 'A' gets
    updated with 'B' only when the two enables are set to 1 and the rising edge
    of the clock arises and nrst is 1). Try it and see.

    > My consideration is based on the Actel gate array layout, but I think the
    > principle are the same for all the layouts (combinational and sequential
    > Cells).
    > Could you confirm this?

    Try running both through any synthesis tool to target a particular device
    and see.

    KJ
    KJ, Nov 10, 2006
    #2
    1. Advertising

  3. Al

    Andy Guest

    In the old days, the differences could be used to handle late arriving
    inputs more quickly than early arriving inputs, assuming you knew at
    coding time which ones were which. Now, synthesis will look at timing
    estimates to determine early and late arrivals, and implement the
    circuit accordingly. In many cases with LUT based FPGAs there will be
    no difference in the implementation. Also, most synthesis tools will
    not seek to optimize early/late inputs until and unless timing
    constraints fail without doing so.

    Andy


    Al wrote:
    > Hi to all,
    > writing some code I've noticed that to enable the data on a FF with the
    > combination of two or more signals there are different ways of writing
    > code (of course), which will turn in different implementation (maybe).
    > I was wondering which is the difference between the following:
    >
    > -- first case
    > process (clk, nrst)
    > if nrst = '0' then
    > A <= '0';
    > if rising_edge (clk) then
    > if enA_1 = '1' and enA_2 = '1' then
    > A <= B;
    > end if;
    > end if;
    > end process;
    >
    > -- second case
    > process (clk, nrst)
    > if nrst = '0' then
    > A <= '0';
    > if rising_edge (clk) then
    > if enA_1 = '1' then
    > if enA_2 = '1' then
    > A <= B;
    > end if;
    > end if;
    > end if;
    > end process;
    >
    > I think there will be quite a big difference in the implementation: a
    > combinational AND Cell and a sequential Cell will be implemented in the
    > first case, while only a sequential Cell in the second case. Is this
    > correct?
    > My consideration is based on the Actel gate array layout, but I think
    > the principle are the same for all the layouts (combinational and
    > sequential Cells).
    > Could you confirm this?
    >
    > Thanks a lot
    >
    > Al
    >
    >
    > --
    > Alessandro Basili
    > CERN, PH/UGC
    > Hardware Designer
    Andy, Nov 10, 2006
    #3
  4. Al

    Andy Guest

    In the old days, the differences could be used to handle late arriving
    inputs more quickly than early arriving inputs, assuming you knew at
    coding time which ones were which. Now, synthesis will look at timing
    estimates to determine early and late arrivals, and implement the
    circuit accordingly. In many cases with LUT based FPGAs there will be
    no difference in the implementation. Also, most synthesis tools will
    not seek to optimize early/late inputs until and unless timing
    constraints fail without doing so.

    Andy


    Al wrote:
    > Hi to all,
    > writing some code I've noticed that to enable the data on a FF with the
    > combination of two or more signals there are different ways of writing
    > code (of course), which will turn in different implementation (maybe).
    > I was wondering which is the difference between the following:
    >
    > -- first case
    > process (clk, nrst)
    > if nrst = '0' then
    > A <= '0';
    > if rising_edge (clk) then
    > if enA_1 = '1' and enA_2 = '1' then
    > A <= B;
    > end if;
    > end if;
    > end process;
    >
    > -- second case
    > process (clk, nrst)
    > if nrst = '0' then
    > A <= '0';
    > if rising_edge (clk) then
    > if enA_1 = '1' then
    > if enA_2 = '1' then
    > A <= B;
    > end if;
    > end if;
    > end if;
    > end process;
    >
    > I think there will be quite a big difference in the implementation: a
    > combinational AND Cell and a sequential Cell will be implemented in the
    > first case, while only a sequential Cell in the second case. Is this
    > correct?
    > My consideration is based on the Actel gate array layout, but I think
    > the principle are the same for all the layouts (combinational and
    > sequential Cells).
    > Could you confirm this?
    >
    > Thanks a lot
    >
    > Al
    >
    >
    > --
    > Alessandro Basili
    > CERN, PH/UGC
    > Hardware Designer
    Andy, Nov 10, 2006
    #4
  5. Al

    KJ Guest

    "Andy" <> wrote in message
    news:...
    > In the old days, the differences could be used to handle late arriving
    > inputs more quickly than early arriving inputs, assuming you knew at
    > coding time which ones were which. Now, synthesis will look at timing
    > estimates to determine early and late arrivals, and implement the
    > circuit accordingly. In many cases with LUT based FPGAs there will be
    > no difference in the implementation. Also, most synthesis tools will
    > not seek to optimize early/late inputs until and unless timing
    > constraints fail without doing so.
    >
    > Andy
    >

    Even going back to the days of Abel (the language, not the Bible guy with
    brother troubles) the two versions of code that were posted and in question
    would synthesize to the exact same thing targetting anything from a PAL or
    the latest Virtex/Stratix.

    KJ
    KJ, Nov 10, 2006
    #5
  6. Al

    Al Guest

    KJ wrote:
    > "Andy" <> wrote in message
    > news:...
    >
    >>In the old days, the differences could be used to handle late arriving
    >>inputs more quickly than early arriving inputs, assuming you knew at
    >>coding time which ones were which. Now, synthesis will look at timing
    >>estimates to determine early and late arrivals, and implement the
    >>circuit accordingly. In many cases with LUT based FPGAs there will be
    >>no difference in the implementation. Also, most synthesis tools will
    >>not seek to optimize early/late inputs until and unless timing
    >>constraints fail without doing so.
    >>
    >>Andy
    >>

    >
    > Even going back to the days of Abel (the language, not the Bible guy with
    > brother troubles) the two versions of code that were posted and in question
    > would synthesize to the exact same thing targetting anything from a PAL or
    > the latest Virtex/Stratix.
    >
    > KJ
    >


    Is that means synthesizer will always get to the same point, based on
    time estimation? I've always believed (maybe erroneously and most
    probably because never gone into details) that differences like "if"
    statements and "case" statements will turn out in different resources
    inferred.
    Based on what Andy explained, I then assume that there is no meaning
    giving priority to a signal instead of another to synchronously set a
    Flip-Flop, because the synthesizer, based on time estimation, may revert
    the logic. But shouldn't it estimate time starting from the point that
    the code has a priority?
    I know that my first question was just a case of study, but then I would
    really like to understand if this is a more general problem of coding style.

    Thanks

    Al

    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Nov 11, 2006
    #6
  7. Al

    mysticlol Guest

    Is Gated clock approach advisable for this kind of requirement?

    en <= enA_1 and enA_2;

    process (clk, nrst, en)
    if nrst = '0' then
    A <= '0';
    elsif rising_edge (clk) and en='1' then
    A <= B;
    end if;
    end process;

    Regards,
    Krishna Janumanchi
    mysticlol, Nov 11, 2006
    #7
  8. Al

    Al Guest

    mysticlol wrote:
    > Is Gated clock approach advisable for this kind of requirement?
    >
    > en <= enA_1 and enA_2;
    >
    > process (clk, nrst, en)
    > if nrst = '0' then
    > A <= '0';
    > elsif rising_edge (clk) and en='1' then
    > A <= B;
    > end if;
    > end process;
    >
    > Regards,
    > Krishna Janumanchi
    >


    I don't really like this approach, first of all because sometimes it
    cannot be applicable from hardware point of view (hardwired clocks
    cannot be gated on the Actel, for instance). Secondly it is quite risky
    and can generate glitches because en has a routed delay.
    In third place this approach will not allow you to have both synchronous
    set and reset.

    Regards,

    Al

    p.s.: and it doesn't have a nice look, to me ;-)

    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Nov 11, 2006
    #8
  9. Al wrote:
    >
    > I've always believed (maybe erroneously and most
    > probably because never gone into details) that differences like "if"
    > statements and "case" statements will turn out in different resources
    > inferred.



    An if-then-else or case statement *cannot* infer a priority encoding.
    An if-then-elsif-else statement *might* infer a priority encoding.

    -- Mike Treseler
    Mike Treseler, Nov 11, 2006
    #9
  10. Al

    Al Guest

    Mike Treseler wrote:
    > Al wrote:
    >
    >>I've always believed (maybe erroneously and most
    >>probably because never gone into details) that differences like "if"
    >>statements and "case" statements will turn out in different resources
    >>inferred.

    >
    >
    >
    > An if-then-else or case statement *cannot* infer a priority encoding.
    > An if-then-elsif-else statement *might* infer a priority encoding.
    >
    > -- Mike Treseler


    Sorry Mike but I don't understand, isn't it obvious that an if-then-else
    cannot infer priority? priority on which other conditions if there are
    no others involved in the process (being it an if-then-else there will
    be only one condition)?.
    My concern was more about if-then-elsif-else and case-when.
    Even in if-then-elsif-else I didn't understand if the order has an
    effect on the synthesis or not; to me it has always had a meaning, i.e.
    if the two conditions (or more) are true in the same delta, then the
    first one will take over the others, meaning that a D-FlipFlop cannot go
    into a metastable condition. If I think of an A54SXA family (I've always
    worked with) then I can imagine the first condition will be routed to
    the the first mux of the R-Cell (the closest to the FF) and the second
    one will be routed to the second mux, with will have less priority just
    because is physically behind the other mux.
    But if the synthesizer might "change" the order based on its
    optimization algorithms, then all the "priority logic" is just
    unpredictable.
    Am I wrong in my understandings?

    Thank you

    p.s.: I love this NG!

    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Nov 11, 2006
    #10
  11. Al

    KJ Guest

    "Al" <> wrote in message
    news:ej4d44$l8t$...
    >>
    >> Even going back to the days of Abel (the language, not the Bible guy with
    >> brother troubles) the two versions of code that were posted and in
    >> question would synthesize to the exact same thing targetting anything
    >> from a PAL or the latest Virtex/Stratix.
    >>
    >> KJ
    >>

    >
    > Is that means synthesizer will always get to the same point, based on time
    > estimation?

    'Time estimation' has nothing to do with it. Logic that is equivalent will
    almost without exception synthesize to the exact same thing.

    > I've always believed (maybe erroneously and most probably because never
    > gone into details) that differences like "if" statements and "case"
    > statements will turn out in different resources inferred.

    Only if they are not logically equivalent. Try writing the code for
    something like an address decoder where you decode specific addresses and do
    so using only a case statement. Then translate that code into the
    equivalent if/elsif form. Synthesize and target to the same device and, if
    you translated correctly, you'll get the same result.

    case Address is
    when C1 => -- Do something
    when C2 => -- Do something else
    when C3 => -- Do some more
    when others => -- Do something different
    end case

    If written as an if statement should come out as
    elsif Address = C1 then -- Do something
    elsif Address = C2 then -- Do something else
    elsif Address = C3 then -- Do some more
    else -- Do something different
    end if;

    > Based on what Andy explained, I then assume that there is no meaning
    > giving priority to a signal instead of another to synchronously set a
    > Flip-Flop, because the synthesizer, based on time estimation, may revert
    > the logic. But shouldn't it estimate time starting from the point that the
    > code has a priority?

    I'm not quite sure what point Andy was trying to make. The synthesis
    process translates your code into boolean equations. Next it tries come up
    with an implementation of that set of boolean equations that meets any
    timing requirements. If it does not meet timing then it works with
    alternate equivaent forms of that same set of boolean equations that does
    meet the requirement.

    > I know that my first question was just a case of study, but then I would
    > really like to understand if this is a more general problem of coding
    > style.
    >

    Equivalent logic will synthesize to the same output. It usually has nothing
    to do with 'coding style', if you have a complicated algorithm to implement
    it will usually be a complicated structure. Where you get the most bang for
    the buck is having an understanding of how high level language structure get
    translated into boolean equations and what implications get implied and
    seeing if there is an alternative representation that implements the same
    functionality.

    As an example, from a 'coding style' perspective you might not like to see
    10 nested 'if' statements of the form....
    if s1 then
    if s2 then
    if s3 then
    ....
    end if;
    end if;
    end if;

    But this structure is exactly equivalent to
    if s1 and s2 and s2 .... then
    end if;

    and will produce the exact same synthesis result. So don't let dogma about
    how many nested if statements drive how the code gets written, let the
    driving force be how clear the code is to understand and map back to the
    requirements since, in this example, the number of NESTED if statements is
    irrelevant.

    But now if some (or all) of those if statements have 'else' branches now you
    look a bit harder. If s1 is a single signal than not(s1) (i.e. the path
    taken for the 'else' of "if s1 then" is pretty easy, but if s1 is the
    comparison of let's say an 8 bit address to a constant then not(s1) becomes
    quite a bit more complex. What if s1 is the comparison of an 8 bit address
    to something that is not constant? Now those nested 'if statements' quickly
    turn into a lot of logic and probably slow timing paths. But is that a
    problem? If your implementation of the the algorithm looks just like the
    algorithm specification and you meet timing, then the answer is 'no'. There
    is great value in being able to look at the algorithm specification (i.e.
    your functional requirements) and your implementation of that algorithm and
    being able to see that one to one correspondance. If that direct
    translation does NOT meet timing requirements than you have to come up with
    an alternative, that's where skill and experience will kick in and be the
    important determinant in getting the implementation completed correctly.

    The best way to get this innate 'feel' is to try writing some benchmark
    examples and see what pops out of the final synthesized result for the final
    boolean equations. Once you've mastered this you'll gain the ability to
    glance at code and know what things to look for that will make things
    difficult to implement in terms of either logic resources or timing
    performance. Their are no shortcuts to study and learn, just like doing
    homework in school has you doing specific problems to gain mastery over the
    topic so you can tackle new things.

    KJ
    KJ, Nov 12, 2006
    #11
  12. Al

    KJ Guest

    Oops, slight correction to above post...

    If written as an if statement should come out as
    if Address = C1 then -- Do something
    elsif Address = C2 then -- Do something else
    elsif Address = C3 then -- Do some more
    else -- Do something different
    end if;

    KJ
    KJ, Nov 12, 2006
    #12
  13. Al

    Jim Lewis Guest

    Mike
    > Al wrote:
    >> I've always believed (maybe erroneously and most
    >> probably because never gone into details) that differences like "if"
    >> statements and "case" statements will turn out in different resources
    >> inferred.

    >
    >
    > An if-then-else *cannot* infer a priority encoding.

    Can too. ;)

    The following two are the same:

    -- if elsif
    IfElsProc : process (A, ASel, B, BSel)
    begin
    if ASel = '1' then
    Y <= A ;
    elsif BSel = '1' then
    Y <= B ;
    else
    Y <= (others => '0') ;
    end if ;
    end process ;

    -- multiple separate if.
    -- Note priority in reverse order since last assignment wins
    IfEndProc : process (A, ASel, B, BSel)
    begin
    Y <= (others => '0') ; -- default in place of else
    if BSel = '1' then
    Y <= B ;
    end if ;
    if ASel = '1' then
    Y <= A ;
    end if ;
    end process ;


    > An case statement *cannot* infer a priority encoding.


    Can, but you probably would not want to.

    Sel <= ASel & BSel ;

    IfEndProc : process (A, B, Sel)
    begin
    case Sel is
    when "11" | "10" => Y <= A ;
    when "01" => Y <= B ;
    when others => Y <= (others => '0') ;
    end case ;
    end process ;

    > An if-then-elsif-else statement *might* infer a priority encoding.

    Most often infers priority. Will only not infer priority when
    the synthesis tool can detect conditions are mutually exclusive.

    -- ok, but masks X
    Y <= A when Sel = '1' else B ;

    -- ok, but sometimes synthesis slow (run time) and
    -- sometimes I would expect lower quality of results:
    works_but_do_not_do : process (Sel, A, B, C, D )
    begin
    if Sel = "00" then
    Y <= A ;
    elsif Sel = "01" then
    Y <= B ;
    elsif Sel = "10" then
    Y <= C ;
    elsif Sel = "11" then
    Y <= D ;
    else
    Y <= (others => '0') ;
    end if ;
    end process ;



    Sure would be nice if we could standardize a function
    that indicated when inputs were mutually exclusive in such
    a way that is both simulatable and understood by the
    synthesis tools. Such as something like the following:

    assert ZeroOneHot(ASel, BSel)
    report "ASel and BSel not mutually exclusive"
    severity error ;

    IfElsProc : process (A, ASel, B, BSel)
    begin
    if ASel = '1' then
    Y <= A ;
    elsif BSel = '1' then
    Y <= B ;
    else
    Y <= (others => '0') ;
    end if ;
    end process ;

    With a synthesis result of the following (which is not
    portable in synthesis):
    Y <= A and (A'range => ASel) or B and (B'range => BSel) ;


    The more interesting case is when ASel and BSel are both
    load enables to a register.

    Cheers,
    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, Nov 12, 2006
    #13
  14. Al

    Jim Lewis Guest

    KJ
    > Only if they are not logically equivalent. Try writing the code for
    > something like an address decoder where you decode specific addresses and do
    > so using only a case statement. Then translate that code into the
    > equivalent if/elsif form. Synthesize and target to the same device and, if
    > you translated correctly, you'll get the same result.
    >
    > case Address is
    > when C1 => -- Do something
    > when C2 => -- Do something else
    > when C3 => -- Do some more
    > when others => -- Do something different
    > end case
    >
    > If written as an if statement should come out as
    > elsif Address = C1 then -- Do something
    > elsif Address = C2 then -- Do something else
    > elsif Address = C3 then -- Do some more
    > else -- Do something different
    > end if;


    This works well for an address decoder where the "Do Something"
    is assign a constant since the result will be simple AND-OR logic.

    I would be careful using the same thoughts for more structured
    logic, such as multiplexers and math.
    Although for some tools and some technology targets, the
    equivalent "if" form will do fine, for others it will not,
    particularly if your target is an ASIC.


    > Equivalent logic will synthesize to the same output. It usually has nothing
    > to do with 'coding style', if you have a complicated algorithm to implement
    > it will usually be a complicated structure.
    > ... Snip ...
    > The best way to get this innate 'feel' is to try writing some benchmark
    > examples and see what pops out of the final synthesized result for the final
    > boolean equations. Once you've mastered this you'll gain the ability to
    > glance at code and know what things to look for that will make things
    > difficult to implement in terms of either logic resources or timing
    > performance. Their are no shortcuts to study and learn, just like doing
    > homework in school has you doing specific problems to gain mastery over the
    > topic so you can tackle new things.


    Well stated. I second this. Benchmarking and understanding
    the little pieces is very important.

    Sometimes synthesis tools may vary as they combine logic.
    If this makes you miss timing, you can isolate (hide) the
    terms that are causing the synthesis tool to mess up placing
    either "SYN_KEEP" in Synplicity or "KEEP" in Xilinx (IEEE
    1076.6-2004 compliant) on the logic term that you do not want
    to combine with other logic. Note don't do this as a general
    technique as sometimes the synthesis tool will find a better
    solution than the one you expect.

    Cheers,
    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, Nov 12, 2006
    #14
  15. Al

    Andy Guest

    First, in the example you gave, there is no priority. BOTH must be true
    to enable the assignment. The notion of priority implies that more than
    one possible behavior can occur, and one of those possibilities has
    priority over other possibilities.

    Priority is usually implied by an else statement, or by order of if
    statements (not nested), in that the last assignment wins in sequential
    code.

    For example:

    if a then
    x <= y;
    elsif b then
    x <= w;
    end if;

    The above implies that a (and the resulting x<=y assignment) has
    priority over b and its assignment. The same priority can be implied
    with:

    if b then
    x <= w;
    end if;
    if a then
    x <= y;
    end if;

    or:

    if a then
    x <= y;
    end if;
    if b and not a then -- ignoring metavalues
    x <= w;
    end if;

    The ONLY time a synthesis tool will ignore the coded priority is if it
    can determine that a and b are mutually exclusive. Then it can safely
    optimize out the priority logic.

    Andy


    Al wrote:
    > KJ wrote:
    > > "Andy" <> wrote in message
    > > news:...
    > >
    > >>In the old days, the differences could be used to handle late arriving
    > >>inputs more quickly than early arriving inputs, assuming you knew at
    > >>coding time which ones were which. Now, synthesis will look at timing
    > >>estimates to determine early and late arrivals, and implement the
    > >>circuit accordingly. In many cases with LUT based FPGAs there will be
    > >>no difference in the implementation. Also, most synthesis tools will
    > >>not seek to optimize early/late inputs until and unless timing
    > >>constraints fail without doing so.
    > >>
    > >>Andy
    > >>

    > >
    > > Even going back to the days of Abel (the language, not the Bible guy with
    > > brother troubles) the two versions of code that were posted and in question
    > > would synthesize to the exact same thing targetting anything from a PAL or
    > > the latest Virtex/Stratix.
    > >
    > > KJ
    > >

    >
    > Is that means synthesizer will always get to the same point, based on
    > time estimation? I've always believed (maybe erroneously and most
    > probably because never gone into details) that differences like "if"
    > statements and "case" statements will turn out in different resources
    > inferred.
    > Based on what Andy explained, I then assume that there is no meaning
    > giving priority to a signal instead of another to synchronously set a
    > Flip-Flop, because the synthesizer, based on time estimation, may revert
    > the logic. But shouldn't it estimate time starting from the point that
    > the code has a priority?
    > I know that my first question was just a case of study, but then I would
    > really like to understand if this is a more general problem of coding style.
    >
    > Thanks
    >
    > Al
    >
    > --
    > Alessandro Basili
    > CERN, PH/UGC
    > Hardware Designer
    Andy, Nov 13, 2006
    #15
  16. Al

    Al Guest

    Andy wrote:
    > First, in the example you gave, there is no priority. BOTH must be true
    > to enable the assignment. The notion of priority implies that more than
    > one possible behavior can occur, and one of those possibilities has
    > priority over other possibilities.


    I agree, maybe I massed up the thread, going a bit further out of the
    topic, but everything came from your phrase:

    > Now, synthesis will look at timing
    > estimates to determine early and late arrivals, and implement the
    > circuit accordingly.


    which led me to some erroneous assumptions (as you can see in the
    previous posts).
    About priority I do understand the example I posted didn't imply any
    priority and I do understand that priority is needed between two
    conditions, that's why an if-then-else cannot imply priority because the
    conditions are mutually exclusive.
    >
    > Priority is usually implied by an else statement, or by order of if
    > statements (not nested), in that the last assignment wins in sequential
    > code.

    (snip...)
    >
    > if b then
    > x <= w;
    > end if;
    > if a then
    > x <= y;
    > end if;
    >


    You are always talking about process assignment, is that true? I wasn't
    aware of this rule, good to know, thanks!

    Regards

    Al

    --
    Alessandro Basili
    CERN, PH/UGC
    Hardware Designer
    Al, Nov 14, 2006
    #16
  17. Al

    lokesh_boddu

    Joined:
    Oct 18, 2006
    Messages:
    6
    mysticlol wrote:
    > Is Gated clock approach advisable for this kind of requirement?
    >
    > en <= enA_1 and enA_2;
    >
    > process (clk, nrst, en)
    > if nrst = '0' then
    > A <= '0';
    > elsif rising_edge (clk) and en='1' then
    > A <= B;
    > end if;
    > end process;
    >
    > Regards,
    > Krishna Janumanchi
    >

    I don't really like this approach, first of all because sometimes it
    cannot be applicable from hardware point of view (hardwired clocks
    cannot be gated on the Actel, for instance). Secondly it is quite risky
    and can generate glitches because en has a routed delay.
    In third place this approach will not allow you to have both synchronous
    set and reset.

    Regards,

    Al

    --------------------
    Hi, could you please elaborate your explanation on the above program why it should not be written like that

    Thanks and Regards
    BODDU Lokesh
    lokesh_boddu, Nov 15, 2006
    #17
    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. Aliki

    Enable/disable operation

    Aliki, Sep 27, 2004, in forum: VHDL
    Replies:
    1
    Views:
    521
    ivailokroumov
    Sep 28, 2004
  2. jo
    Replies:
    6
    Views:
    679
  3. Joe Au

    how to enable paging on data grid

    Joe Au, Aug 19, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    2,706
    Joe Au
    Aug 19, 2004
  4. Patrick
    Replies:
    1
    Views:
    646
  5. ahmed k
    Replies:
    0
    Views:
    1,266
    ahmed k
    Sep 25, 2010
Loading...

Share This Page