with clk'event, must we use clk='1' or clk='0' ?

Discussion in 'VHDL' started by sunshinekisses@gmail.com, Jul 28, 2007.

  1. Guest

    Hi,

    Consider this part of a hypothetical counter:

    process (CLK)
    if CLK'event then
    if ClrN = '1' then Qint <= "00";
    else Qint <= Qint + 1;
    end if;
    endif;
    end process;

    Is this legit as it is or MUST I have something like:

    if CLK'event and Clk='1' then...

    as the idea is to have a counter that changes with EVERY clock event,
    not just the leading edge.

    ty, -e
     
    , Jul 28, 2007
    #1
    1. Advertising

  2. On Sat, 28 Jul 2007 21:52:47 -0000,
    <> wrote:

    >Consider this part of a hypothetical counter:


    Hypothetical it certainly is.

    >process (CLK)
    >if CLK'event then
    > if ClrN = '1' then Qint <= "00";
    > else Qint <= Qint + 1;
    > end if;
    >endif;
    >end process;
    >
    >Is this legit as it is or MUST I have something like:
    >
    >if CLK'event and Clk='1' then...
    >
    >as the idea is to have a counter that changes with EVERY clock event,
    >not just the leading edge.


    How do you think this would be implemented in hardware?
    Flip-flops that trigger on both edges of a clock are
    as rare as rocking-horse shit. Synthesis tools rightly
    complain if you try to imply such logic. The code that
    you present is valid VHDL, but would not go through any
    synthesis tool I know about.

    However, it *is* possible to mimic double-data-rate (DDR)
    behaviour such as this using standard single-edge FFs.
    The big idea is to maintain two completely separate
    sets of registers, one clocked on rising edges and
    the other on falling edges. You then use the clock
    itself to multiplex the appropriate registers' contents
    on to your DDR output.

    However, your specific problem of a double-edge binary
    counter that's free-running would be rather simple if
    you could forgo the reset. Consider making the counter
    one bit shorter, and using the clock itself as the
    least significant output bit - use the falling clock
    edge to trigger the upper counter bit(s).

    Here's the clock-muxing DDR counter: note the three
    separate VHDL processes, and rather a lot of signals.

    --- Rising-edge counter
    process (clk)
    begin
    if rising_edge(clk) then
    if clear = '1' then
    QR <= (others => '0');
    else
    QR <= QN + 1;
    end if;
    end if;
    end process;

    --- Falling-edge counter
    process (clk)
    begin
    if falling_edge(clk) then
    if clear = '1' then
    QN <= (others => '0');
    else
    QN <= QR + 1;
    end if;
    end if;
    end process;

    --- Output multiplexer controlled by clock
    QDDR <= QR when clk = '1' else QN;

    Don't ask me to pretend I like it.
    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

    Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, Jul 28, 2007
    #2
    1. Advertising

  3. On Sat, 28 Jul 2007 21:52:47 -0000, ""
    <> wrote:

    >Hi,
    >
    >Consider this part of a hypothetical counter:
    >
    >process (CLK)
    >if CLK'event then
    > if ClrN = '1' then Qint <= "00";
    > else Qint <= Qint + 1;
    > end if;
    >endif;
    >end process;
    >
    >Is this legit as it is or MUST I have something like:
    >
    >if CLK'event and Clk='1' then...
    >
    >as the idea is to have a counter that changes with EVERY clock event,
    >not just the leading edge.
    >


    For simulation it should be fine.

    However if you want to generate hardware this way, see Jonathan's
    answer.

    - Brian
     
    Brian Drummond, Jul 29, 2007
    #3
  4. Andy Guest

    On Jul 28, 5:56 pm, Jonathan Bromley <>
    wrote:
    > On Sat, 28 Jul 2007 21:52:47 -0000,
    >
    > <> wrote:
    > >Consider this part of a hypothetical counter:

    >
    > Hypothetical it certainly is.
    >
    > >process (CLK)
    > >if CLK'event then
    > > if ClrN = '1' then Qint <= "00";
    > > else Qint <= Qint + 1;
    > > end if;
    > >endif;
    > >end process;

    >
    > >Is this legit as it is or MUST I have something like:

    >
    > >if CLK'event and Clk='1' then...

    >
    > >as the idea is to have a counter that changes with EVERY clock event,
    > >not just the leading edge.

    >
    > How do you think this would be implemented in hardware?
    > Flip-flops that trigger on both edges of a clock are
    > as rare as rocking-horse shit. Synthesis tools rightly
    > complain if you try to imply such logic. The code that
    > you present is valid VHDL, but would not go through any
    > synthesis tool I know about.
    >
    > However, it *is* possible to mimic double-data-rate (DDR)
    > behaviour such as this using standard single-edge FFs.
    > The big idea is to maintain two completely separate
    > sets of registers, one clocked on rising edges and
    > the other on falling edges. You then use the clock
    > itself to multiplex the appropriate registers' contents
    > on to your DDR output.
    >
    > However, your specific problem of a double-edge binary
    > counter that's free-running would be rather simple if
    > you could forgo the reset. Consider making the counter
    > one bit shorter, and using the clock itself as the
    > least significant output bit - use the falling clock
    > edge to trigger the upper counter bit(s).
    >
    > Here's the clock-muxing DDR counter: note the three
    > separate VHDL processes, and rather a lot of signals.
    >
    > --- Rising-edge counter
    > process (clk)
    > begin
    > if rising_edge(clk) then
    > if clear = '1' then
    > QR <= (others => '0');
    > else
    > QR <= QN + 1;
    > end if;
    > end if;
    > end process;
    >
    > --- Falling-edge counter
    > process (clk)
    > begin
    > if falling_edge(clk) then
    > if clear = '1' then
    > QN <= (others => '0');
    > else
    > QN <= QR + 1;
    > end if;
    > end if;
    > end process;
    >
    > --- Output multiplexer controlled by clock
    > QDDR <= QR when clk = '1' else QN;
    >
    > Don't ask me to pretend I like it.
    > --
    > Jonathan Bromley, Consultant
    >
    > DOULOS - Developing Design Know-how
    > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
    >
    > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
    > ://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.


    Another, non-glitchy way to implement a DDR register with single-edge
    flops is to encode the data between two flops, one on each of the
    clock edges, and decode the result combinatorially. What we need is a
    function such that any input can change the output, no matter what the
    other input is. The parity (XOR) function works very well for this,
    but so would equality (XNOR). Because of the nature of these two
    functions, this could also be expanded to an arbitraty number of
    clocks/edges, so long as all clocks/edges are synchronously related,
    and timing constraints between them are met.

    Note that in the examples below, "dr" could be the same as "df", and
    just use "d", and instead of rising and falling edges of the same
    clock, two related (synchronously) clocks could be used. This
    technique cannot be used for two asynchronous clocks. Naturally, this
    could be done with SLV instead of SL as well.

    re: process (clk, rst) is
    begin
    if rst = '1' then
    qr <= '0';
    elsif rising_edge(clk) then
    qr <= dr xor qf;
    end if;
    end process re;

    fe: process (clk, rst) it
    begin
    if rst = '1' then
    qf <= '0';
    elsif falling_edge(clk) then
    qf <= df xor qr;
    end if;
    end process fe;

    q <= qr xor qf;

    Alternatively, some synthesis tools (synplify and others) support
    multiple edges in the same process, so long as the same variable/
    signal is not assigned on both edges. Also, some of them accept a
    combinatorial assignment to a signal from an expression of variables,
    after the clock clause:

    be: process (clk, rst) is
    variable qr, qf : std_logic;
    begin
    if rst = '1' then
    qr := '0';
    qf := '0';
    elsif rising_edge(clk) then
    qr := dr xor qf; -- encode
    elsif falling_edge(clk) then
    qf := df xor qr; -- encode
    end if;
    q <= qr xor qf; -- combo decode
    end process;

    Andy
     
    Andy, Jul 30, 2007
    #4
  5. ast Guest

    "Jonathan Bromley" <> a écrit dans le message de news: ...
    > On Sat, 28 Jul 2007 21:52:47 -0000,
    > <> wrote:
    >
    >>Consider this part of a hypothetical counter:

    >
    > Hypothetical it certainly is.
    >
    >>process (CLK)
    >>if CLK'event then
    >> if ClrN = '1' then Qint <= "00";
    >> else Qint <= Qint + 1;
    >> end if;
    >>endif;
    >>end process;
    >>
    >>Is this legit as it is or MUST I have something like:
    >>
    >>if CLK'event and Clk='1' then...
    >>
    >>as the idea is to have a counter that changes with EVERY clock event,
    >>not just the leading edge.

    >
    > How do you think this would be implemented in hardware?
    > Flip-flops that trigger on both edges of a clock are
    > as rare as rocking-horse shit. Synthesis tools rightly
    > complain if you try to imply such logic. The code that
    > you present is valid VHDL, but would not go through any
    > synthesis tool I know about.
    >
    > However, it *is* possible to mimic double-data-rate (DDR)
    > behaviour such as this using standard single-edge FFs.
    > The big idea is to maintain two completely separate
    > sets of registers, one clocked on rising edges and
    > the other on falling edges. You then use the clock
    > itself to multiplex the appropriate registers' contents
    > on to your DDR output.
    >
    > However, your specific problem of a double-edge binary
    > counter that's free-running would be rather simple if
    > you could forgo the reset. Consider making the counter
    > one bit shorter, and using the clock itself as the
    > least significant output bit - use the falling clock
    > edge to trigger the upper counter bit(s).
    >
    > Here's the clock-muxing DDR counter: note the three
    > separate VHDL processes, and rather a lot of signals.
    >
    > --- Rising-edge counter
    > process (clk)
    > begin
    > if rising_edge(clk) then
    > if clear = '1' then
    > QR <= (others => '0');
    > else
    > QR <= QN + 1;
    > end if;
    > end if;
    > end process;
    >
    > --- Falling-edge counter
    > process (clk)
    > begin
    > if falling_edge(clk) then
    > if clear = '1' then
    > QN <= (others => '0');
    > else
    > QN <= QR + 1;
    > end if;
    > end if;
    > end process;
    >
    > --- Output multiplexer controlled by clock
    > QDDR <= QR when clk = '1' else QN;
    >
    > Don't ask me to pretend I like it.
    > --


    This doesnt behave as a DDR counter
    or i missed something
     
    ast, Jul 30, 2007
    #5
  6. On Mon, 30 Jul 2007 16:13:18 +0200, "ast" <> wrote:

    >
    >"Jonathan Bromley" <> a écrit

    [...]

    >This doesnt behave as a DDR counter


    Well, my brain and my simulator both agree that it does...

    >or i missed something


    I wonder if you missed the fact that each half of the
    counter increments the OTHER counter's count?
    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

    Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, Jul 30, 2007
    #6
  7. ast Guest

    "Jonathan Bromley" <> a écrit dans le message de news: ...
    > On Mon, 30 Jul 2007 16:13:18 +0200, "ast" <> wrote:
    >
    >>
    >>"Jonathan Bromley" <> a écrit

    > [...]
    >
    >>This doesnt behave as a DDR counter

    >
    > Well, my brain and my simulator both agree that it does...
    >
    >>or i missed something

    >
    > I wonder if you missed the fact that each half of the
    > counter increments the OTHER counter's count?
    > --


    oh yes, i understand now. nice trick.
     
    ast, Jul 30, 2007
    #7
  8. Dave Higton Guest

    In message <>
    Jonathan Bromley <> wrote:

    > On Sat, 28 Jul 2007 21:52:47 -0000,
    > <> wrote:
    >
    > >Consider this part of a hypothetical counter:

    >
    > Hypothetical it certainly is.
    >
    > >process (CLK)
    > >if CLK'event then
    > > if ClrN = '1' then Qint <= "00";
    > > else Qint <= Qint + 1;
    > > end if;
    > >endif;
    > >end process;
    > >
    > >Is this legit as it is or MUST I have something like:
    > >
    > >if CLK'event and Clk='1' then...
    > >
    > >as the idea is to have a counter that changes with EVERY clock event,
    > >not just the leading edge.

    >
    > How do you think this would be implemented in hardware?
    > Flip-flops that trigger on both edges of a clock are
    > as rare as rocking-horse shit. Synthesis tools rightly
    > complain if you try to imply such logic. The code that
    > you present is valid VHDL, but would not go through any
    > synthesis tool I know about.


    And since there have been at least two implementations
    suggested in this newsgroup, I think it's high time the
    synthesis vendors got off their bottoms and implemented
    something.

    After all, when someone writes VHDL for a counter in a
    CPLD, the vendors don't bleat "Woe is me, this CPLD has
    no counter primitive, I can't do this" - they synthesise
    a counter from the primitives they have available to them.
    Same for state machines.

    Dave
     
    Dave Higton, Jul 31, 2007
    #8
  9. mk Guest

    On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
    <> wrote:

    >After all, when someone writes VHDL for a counter in a
    >CPLD, the vendors don't bleat "Woe is me, this CPLD has
    >no counter primitive, I can't do this" - they synthesise
    >a counter from the primitives they have available to them.
    >Same for state machines.


    That's because the synthesis tool has the ingredients necessary to
    "synthesize" the desired functionality ie DFFs which triger on one
    edge of the clock, a clock tree which distributes said clock and
    combinational logic. In order to do DDR synthesis, they also need DFFs
    which can triger at either edge of the clock, suitable clock trees for
    this purpose and muxes which can control inputs from different phases
    of the clock domains without excessive delay. These new components
    don't exist on most programmable devices.
     
    mk, Aug 3, 2007
    #9
  10. Andy Guest

    On Aug 2, 11:05 pm, mk <kal*@dspia.*comdelete> wrote:
    > On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
    >
    > <> wrote:
    > >After all, when someone writes VHDL for a counter in a
    > >CPLD, the vendors don't bleat "Woe is me, this CPLD has
    > >no counter primitive, I can't do this" - they synthesise
    > >a counter from the primitives they have available to them.
    > >Same for state machines.

    >
    > That's because the synthesis tool has the ingredients necessary to
    > "synthesize" the desired functionality ie DFFs which triger on one
    > edge of the clock, a clock tree which distributes said clock and
    > combinational logic. In order to do DDR synthesis, they also need DFFs
    > which can triger at either edge of the clock, suitable clock trees for
    > this purpose and muxes which can control inputs from different phases
    > of the clock domains without excessive delay. These new components
    > don't exist on most programmable devices.


    If you read my post, you'd realize that it is a simple implementation
    for a DDR register using 3 XOR gates, two DFFs, and no clock/input/
    output muxing. Output is glitch free and 100% STA compatible. It can
    use separate clocks (synchronously related, with adequate time between
    edges) or both edges of the same clock, with separate inputs or
    combined.

    I have tried to persuade Synplicity to implement this, but to no
    avail. If a lot more users convince any one of the vendors to do it,
    then the rest will follow. Maybe Xilinx or Altera will jump on it as a
    way to sell more chips ("our chip now does DDR internally!"). Maybe it
    will be a new logo: "DDR Inside (TM)"!

    After all, if synthesis vendors can do TMR (triple mode redundancy)
    automatically, surely they can handle this.

    Andy
     
    Andy, Aug 3, 2007
    #10
  11. Dave Higton Guest

    In message <>
    mk <kal*@dspia.*comdelete> wrote:

    > On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
    > <> wrote:
    >
    > >After all, when someone writes VHDL for a counter in a
    > >CPLD, the vendors don't bleat "Woe is me, this CPLD has
    > >no counter primitive, I can't do this" - they synthesise
    > >a counter from the primitives they have available to them.
    > >Same for state machines.

    >
    > That's because the synthesis tool has the ingredients necessary to
    > "synthesize" the desired functionality ie DFFs which triger on one
    > edge of the clock, a clock tree which distributes said clock and
    > combinational logic. In order to do DDR synthesis, they also need DFFs
    > which can triger at either edge of the clock, suitable clock trees for
    > this purpose and muxes which can control inputs from different phases
    > of the clock domains without excessive delay. These new components
    > don't exist on most programmable devices.


    My point is that these "new" components can be synthesised from
    primitives that are in most/all programmable logic devices. So
    the synthesis tool /does/ have the necessary ingredients.

    Dave
     
    Dave Higton, Aug 3, 2007
    #11
  12. In news:
    timestamped Fri, 03 Aug 2007 11:35:32 -0700,
    Andy <> posted:
    |------------------------------------------------------------------------|
    |"[..] |
    | |
    |I have tried to persuade Synplicity to implement this, but to no |
    |avail. If a lot more users convince any one of the vendors to do it, |
    |then the rest will follow. Maybe Xilinx or Altera will jump on it as a |
    |way to sell more chips ("our chip now does DDR internally!"). Maybe it |
    |will be a new logo: "DDR Inside (TM)"!" |
    |------------------------------------------------------------------------|

    What excuse was used to avoid providing this? Maybe if some vendor
    implements it, other vendors will also do so, but it took years for
    simple things such as rising_edge and multidimensional arrays to be
    widely supported, so do not be too optimistic.

    |------------------------------------------------------------------------|
    |"After all, if synthesis vendors can do TMR (triple mode redundancy) |
    |automatically, surely they can handle this. |
    | |
    |Andy" |
    |------------------------------------------------------------------------|

    I am aware of one vendor which has claimed to automatically implement
    triple modular redundancy for FPGAs, but I received no satisfactory
    reponse to a point I made that this vendor's implementation did not
    seem to provide any improvement to not using triple modular redundancy
    at all. Triple modular redundancy can be better than not using TMR:
    are you aware of a vendor which automatically provides TMR in a useful
    manner?

    Regards,
    Colin Paul Gloster
     
    Colin Paul Gloster, Aug 6, 2007
    #12
  13. In news: timestamped Tue, 31 Jul
    2007 20:51:56 +0100, Dave Higton <> posted:
    |------------------------------------------------------------------------|
    |"In message <> |
    | Jonathan Bromley <> wrote: |
    | |
    |> On Sat, 28 Jul 2007 21:52:47 -0000, |
    |> <> wrote: |
    |> |
    |[..] |
    |> > |
    |> >as the idea is to have a counter that changes with EVERY clock event,|
    |> >not just the leading edge. |
    |> |
    |> How do you think this would be implemented in hardware? |
    |> Flip-flops that trigger on both edges of a clock are |
    |> as rare as rocking-horse shit." |
    |------------------------------------------------------------------------|

    Jonathan, I do not mean to be disrespectful, but it is irrelevant
    whether or not flip-flops which can be triggerred on both edges of a
    clock are available.

    |------------------------------------------------------------------------|
    |" Synthesis tools rightly |
    |> complain if you try to imply such logic." |
    |------------------------------------------------------------------------|

    They have no right to complain.

    |------------------------------------------------------------------------|
    |" The code that |
    |> you present is valid VHDL, but would not go through any |
    |> synthesis tool I know about. |
    | |
    |And since there have been at least two implementations |
    |suggested in this newsgroup, I think it's high time the |
    |synthesis vendors got off their bottoms and implemented |
    |something." |
    |------------------------------------------------------------------------|

    In theory this is true, but synthesis vendors seem to have an ability
    to not bother providing an implementation for something until a long
    time has passed. I do not know whether this is because they are busy
    working on other things or because they are lazy. One person I met
    attributed something similar to being a case of vendors knowing that
    for a few years a missing feature would be tolerable but that
    eventually customers would demand it as virtually essential in which
    case it would be eventually provided.

    |------------------------------------------------------------------------|
    |"After all, when someone writes VHDL for a counter in a |
    |CPLD, the vendors don't bleat "Woe is me, this CPLD has |
    |no counter primitive, I can't do this" - they synthesise |
    |a counter from the primitives they have available to them. |
    |Same for state machines. |
    | |
    |Dave" |
    |------------------------------------------------------------------------|

    I do not know whether Dave's examples are true, but they seem to be
    excellent examples of why a lack of straight forward mappings to
    efficient primitives is not a sufficient excuse for not providing
    synthesis support for some kinds of code. A synthesis tool should be
    more like a compiler instead of merely an assembler.

    Regards,
    C. P. G.
     
    Colin Paul Gloster, Aug 6, 2007
    #13
  14. Andy Guest

    On Aug 6, 10:15 am, Colin Paul Gloster <>
    wrote:
    > Innews:
    > timestamped Fri, 03 Aug 2007 11:35:32 -0700,
    > Andy <> posted:
    > |------------------------------------------------------------------------|
    > |"[..] |
    > | |
    > |I have tried to persuade Synplicity to implement this, but to no |
    > |avail. If a lot more users convince any one of the vendors to do it, |
    > |then the rest will follow. Maybe Xilinx or Altera will jump on it as a |
    > |way to sell more chips ("our chip now does DDR internally!"). Maybe it |
    > |will be a new logo: "DDR Inside (TM)"!" |
    > |------------------------------------------------------------------------|
    >
    > What excuse was used to avoid providing this? Maybe if some vendor
    > implements it, other vendors will also do so, but it took years for
    > simple things such as rising_edge and multidimensional arrays to be
    > widely supported, so do not be too optimistic.
    >
    > |------------------------------------------------------------------------|
    > |"After all, if synthesis vendors can do TMR (triple mode redundancy) |
    > |automatically, surely they can handle this. |
    > | |
    > |Andy" |
    > |------------------------------------------------------------------------|
    >
    > I am aware of one vendor which has claimed to automatically implement
    > triple modular redundancy for FPGAs, but I received no satisfactory
    > reponse to a point I made that this vendor's implementation did not
    > seem to provide any improvement to not using triple modular redundancy
    > at all. Triple modular redundancy can be better than not using TMR:
    > are you aware of a vendor which automatically provides TMR in a useful
    > manner?
    >
    > Regards,
    > Colin Paul Gloster


    IINM, Synplicity does, for non-volatile, rad hard FPGA (i.e. Actel)
    targets, provide the option of TMR on all registers. Whether that is
    "useful" I don't know, but it irrelevant to my point: They already
    take a single inference for register storage, and implement multiple
    flops and gates to realize the function desired. Their response was
    that they did not see a real need for it. And I suppose, for targets
    that have PLL/DLL clock generation facilities, that it is just as easy
    (and more efficient?) to double the clock, and use a single edge flop
    implementation.

    Andy
     
    Andy, Aug 6, 2007
    #14
  15. On 2007-08-06, Andy <> wrote:

    |----------------------------------------------------------------------------|
    |"[..] |
    | |
    |IINM, Synplicity does, for non-volatile, rad hard FPGA (i.e. Actel) |
    |targets, provide the option of TMR on all registers. Whether that is |
    |"useful" I don't know," |
    |----------------------------------------------------------------------------|

    It is not useful as what Synplicity described is basically equivalent to
    Vote_Result <= most_common_value(Voter1, Voter2, Voter3);
    which can be fine if just Voter1 is corrupted or just Voter2 or just
    Voter3 but which is not fine if Vote_Result is corrupted.

    |----------------------------------------------------------------------------|
    |" but it irrelevant to my point: [..]" |
    |----------------------------------------------------------------------------|

    True.

    Regards,
    Colin Paul Gloster
     
    Colin Paul Gloster, Aug 7, 2007
    #15
  16. Andy Guest

    On Aug 7, 3:54 am, Colin Paul Gloster <>
    wrote:
    > On 2007-08-06, Andy <> wrote:
    >
    > |----------------------------------------------------------------------------|
    > |"[..] |
    > | |
    > |IINM, Synplicity does, for non-volatile, rad hard FPGA (i.e. Actel) |
    > |targets, provide the option of TMR on all registers. Whether that is |
    > |"useful" I don't know," |
    > |----------------------------------------------------------------------------|
    >
    > It is not useful as what Synplicity described is basically equivalent to
    > Vote_Result <= most_common_value(Voter1, Voter2, Voter3);
    > which can be fine if just Voter1 is corrupted or just Voter2 or just
    > Voter3 but which is not fine if Vote_Result is corrupted.
    >
    > |----------------------------------------------------------------------------|
    > |" but it irrelevant to my point: [..]" |
    > |----------------------------------------------------------------------------|
    >
    > True.
    >
    > Regards,
    > Colin Paul Gloster


    Hmmm, I thought there were three copies of the vote_result logic, one
    for each voter. Not sure how or where I got that from though; perhaps
    it was just an assumption on my part.

    Andy
     
    Andy, Aug 7, 2007
    #16
  17. Evan Lavelle Guest

    On Fri, 03 Aug 2007 22:54:19 +0100, Dave Higton
    <> wrote:

    >In message <>
    > mk <kal*@dspia.*comdelete> wrote:
    >
    >> On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
    >> <> wrote:
    >>
    >> >After all, when someone writes VHDL for a counter in a
    >> >CPLD, the vendors don't bleat "Woe is me, this CPLD has
    >> >no counter primitive, I can't do this" - they synthesise
    >> >a counter from the primitives they have available to them.
    >> >Same for state machines.

    >>
    >> That's because the synthesis tool has the ingredients necessary to
    >> "synthesize" the desired functionality ie DFFs which triger on one
    >> edge of the clock, a clock tree which distributes said clock and
    >> combinational logic. In order to do DDR synthesis, they also need DFFs
    >> which can triger at either edge of the clock, suitable clock trees for
    >> this purpose and muxes which can control inputs from different phases
    >> of the clock domains without excessive delay. These new components
    >> don't exist on most programmable devices.

    >
    >My point is that these "new" components can be synthesised from
    >primitives that are in most/all programmable logic devices. So
    >the synthesis tool /does/ have the necessary ingredients.


    In principle, yes, a synthesis tool can do anything from the available
    primitives, just as you could draw up the circuit yourself using gates
    and wires. The problem is that all the interesting circuits (flops and
    latches) are asynchronous, and asynchronous design is best left to the
    library vendor. They know exactly what will and wont work, and they
    supply the results as primitives to the synthesiser. You can't expect
    a synthesiser to build an asynchronous circuit from scratch,
    especially when you've got something as coarse-grained as an FPGA to
    work with.

    Evan
     
    Evan Lavelle, Aug 9, 2007
    #17
  18. Dave Higton Guest

    In message <>
    Evan Lavelle <> wrote:

    > On Fri, 03 Aug 2007 22:54:19 +0100, Dave Higton
    > <> wrote:
    >
    > >In message <>
    > > mk <kal*@dspia.*comdelete> wrote:
    > >
    > >> On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
    > >> <> wrote:
    > >>
    > >> >After all, when someone writes VHDL for a counter in a
    > >> >CPLD, the vendors don't bleat "Woe is me, this CPLD has
    > >> >no counter primitive, I can't do this" - they synthesise
    > >> >a counter from the primitives they have available to them.
    > >> >Same for state machines.
    > >>
    > >> That's because the synthesis tool has the ingredients necessary to
    > >> "synthesize" the desired functionality ie DFFs which triger on one
    > >> edge of the clock, a clock tree which distributes said clock and
    > >> combinational logic. In order to do DDR synthesis, they also need DFFs
    > >> which can triger at either edge of the clock, suitable clock trees for
    > >> this purpose and muxes which can control inputs from different phases
    > >> of the clock domains without excessive delay. These new components
    > >> don't exist on most programmable devices.

    > >
    > >My point is that these "new" components can be synthesised from
    > >primitives that are in most/all programmable logic devices. So
    > >the synthesis tool /does/ have the necessary ingredients.

    >
    > In principle, yes, a synthesis tool can do anything from the available
    > primitives, just as you could draw up the circuit yourself using gates
    > and wires. The problem is that all the interesting circuits (flops and
    > latches) are asynchronous, and asynchronous design is best left to the
    > library vendor. They know exactly what will and wont work, and they
    > supply the results as primitives to the synthesiser. You can't expect
    > a synthesiser to build an asynchronous circuit from scratch,
    > especially when you've got something as coarse-grained as an FPGA to
    > work with.


    I'm sorry, I don't understand your point. We aren't talking about
    building an asynchronous circuit; we're talking about building a
    flip-flop that triggers on both edges of the clock. It's just as
    synchronous as a D type FF (synchronous from the clock, sync or
    async - user's choice - from S and R). Whichever of the double
    edge triggered circuit alternatives they choose to synthesise,
    they would do it from DFFs and gates.

    Dave
     
    Dave Higton, Aug 9, 2007
    #18
  19. Andy Guest

    On Aug 9, 2:44 pm, Evan Lavelle <> wrote:
    > On Fri, 03 Aug 2007 22:54:19 +0100, Dave Higton
    >
    >
    >
    > <> wrote:
    > >In message <>
    > > mk <kal*@dspia.*comdelete> wrote:

    >
    > >> On Tue, 31 Jul 2007 20:51:56 +0100, Dave Higton
    > >> <> wrote:

    >
    > >> >After all, when someone writes VHDL for a counter in a
    > >> >CPLD, the vendors don't bleat "Woe is me, this CPLD has
    > >> >no counter primitive, I can't do this" - they synthesise
    > >> >a counter from the primitives they have available to them.
    > >> >Same for state machines.

    >
    > >> That's because the synthesis tool has the ingredients necessary to
    > >> "synthesize" the desired functionality ie DFFs which triger on one
    > >> edge of the clock, a clock tree which distributes said clock and
    > >> combinational logic. In order to do DDR synthesis, they also need DFFs
    > >> which can triger at either edge of the clock, suitable clock trees for
    > >> this purpose and muxes which can control inputs from different phases
    > >> of the clock domains without excessive delay. These new components
    > >> don't exist on most programmable devices.

    >
    > >My point is that these "new" components can be synthesised from
    > >primitives that are in most/all programmable logic devices. So
    > >the synthesis tool /does/ have the necessary ingredients.

    >
    > In principle, yes, a synthesis tool can do anything from the available
    > primitives, just as you could draw up the circuit yourself using gates
    > and wires. The problem is that all the interesting circuits (flops and
    > latches) are asynchronous, and asynchronous design is best left to the
    > library vendor. They know exactly what will and wont work, and they
    > supply the results as primitives to the synthesiser. You can't expect
    > a synthesiser to build an asynchronous circuit from scratch,
    > especially when you've got something as coarse-grained as an FPGA to
    > work with.
    >
    > Evan


    There is nothing asynchronous about the 2-flop, 3-xor circuit I
    described, unless you count the async reset, which just uses the async
    resets on the flops directly (and synthesizers don't have a problem
    with those). That's the beauty of it: No clock gating, no muxing/
    demuxing with the clock, just plain synchronous gates and flops,
    connected in a synchronous circuit.

    Andy
     
    Andy, Aug 9, 2007
    #19
    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. Schmigz

    clk divider

    Schmigz, Feb 9, 2004, in forum: VHDL
    Replies:
    7
    Views:
    5,833
  2. NeoGeoSNK
    Replies:
    25
    Views:
    972
    NeoGeoSNK
    Nov 24, 2006
  3. Lord_MiL
    Replies:
    1
    Views:
    621
    Lord_MiL
    Mar 20, 2007
  4. Matt
    Replies:
    1
    Views:
    167
    Brynn
    Jan 18, 2004
  5. valtih1978

    clk event at firs simulation cycle

    valtih1978, Sep 4, 2012, in forum: VHDL
    Replies:
    3
    Views:
    643
    Gabor
    Sep 5, 2012
Loading...

Share This Page