one signal set ffrom two processes .....

Discussion in 'VHDL' started by Gerhard, Jun 17, 2011.

  1. Gerhard

    Gerhard Guest

    Hi,

    newbe needs help.

    My problem:
    I have a Moor state machine sitting around and waiting.
    After a falling edge on a port the state machine needs to start out
    working, which take about 96 clock cycles. the work mainly is clocking
    data in from a spi interface.
    After that the state machine wents sleeping again.

    I try to create a signal (later a variable) and set it in a process
    which monitors the start signal.
    The state machine consists of three processes (synced Moor state
    machine) and monitors my start signal (which is like a reset if not
    active) and starts out working on the next clock transition.
    After finishing the work, I try to reset my start signal, after
    entering the neutral state (sleeping), but ..

    I always get compiler errors, telling me that the net 'start' is
    constantely driven from different places ....

    Please tell me, how i should solve such an scenario in VHDL ....

    Thinking in 'plain hardware'. I need a FF, which is set by a port
    signal and some edge of the clock and is reset by some condition ....

    Sounds quite easy in hardware, but seems not so easy to implement in
    VHDL for a rouky...

    Thanks for helping.

    With best regards

    gerhard

    Here some snippets:

    nDRdy_sync:
    process
    begin
    wait until falling_edge(nDRDY);
    transfer := '1';
    end process;

    some other:
    process (mySCLK)
    begin
    ...
    ...
    transfer := '0';
    end process;
     
    Gerhard, Jun 17, 2011
    #1
    1. Advertising

  2. On Fri, 17 Jun 2011 03:05:28 -0700, Gerhard wrote:

    > Hi,
    >
    > newbe needs help.
    >
    > My problem:


    > I always get compiler errors, telling me that the net 'start' is
    > constantely driven from different places ....


    That is a very bad design pattern. There are ways to make it work, but
    it's unnecessary here.

    > Please tell me, how i should solve such an scenario in VHDL ....


    Drive "start" from one single process.

    The state machine can feed a second signal ("started", or "finished")
    back to that process to let it know when it is safe to return "start" to
    zero.

    > Thinking in 'plain hardware'. I need a FF, which is set by a port signal
    > and some edge of the clock and is reset by some condition ....


    > Here some snippets:
    >
    > nDRdy_sync:
    > process
    > begin
    > wait until falling_edge(nDRDY);
    > --transfer := '1';

    -- "transfer" should be a signal.
    -- A variable local to the process is OK but invisible outside the process
    -- A "shared variable" is likely to cause problems and best avoided.
    transfer <= '1';
    wait until active; -- a signal of type boolean
    transfer <= '0';
    > end process;
    >
    > some other:
    > process (mySCLK)
    > begin
    > ...
    > ...
    > -- transfer := '0';

    active <= true;
    ...
    -- now the state machine has returned to idle
    active <= false;
    > end process;


    Incidentally the first of these processes will probably not synthesise
    into an FPGA. You would be better off adopting synchronous design using
    one internal clock, for example:

    nDRdy_sync: process(clk)
    variable idle: boolean := true;
    begin
    if rising_edge(clk) then
    if idle then
    if nDRDY = '0' then
    idle := false;
    transfer <= '1';
    end if;
    else
    if active then
    transfer <= '0';
    idle := true;
    end if;
    end if;
    end if;
    end process;

    You will also simplify your state machine if you transform the obsolete
    three-process style into the equivalent single-process state machine. The
    archives of this group cover state machines on a regular basis.

    See also
    http://www.xilinx.com/itp/xilinx4/data/docs/xst/hdlcode15.html
    and some of Mike Treseler's examples on
    http://mysite.ncnetwork.net/reszotzl/

    - Brian
     
    Brian Drummond, Jun 17, 2011
    #2
    1. Advertising

  3. Gerhard

    Gerhard Guest

    On Jun 17, 1:29 pm, Brian Drummond <> wrote:
    > On Fri, 17 Jun 2011 03:05:28 -0700, Gerhard wrote:
    > > Hi,

    >
    > > newbe needs help.

    >
    > > My problem:
    > > I always get compiler errors, telling me that the net 'start' is
    > > constantely driven from different places ....

    >
    > That is a very bad design pattern. There are ways to make it work, but
    > it's unnecessary here.
    >
    > > Please tell me, how i should solve such an scenario in VHDL ....

    >
    > Drive "start" from one single process.
    >
    > The state machine can feed a second signal ("started", or "finished")
    > back to that process to let it know when it is safe to return "start" to
    > zero.
    >
    > > Thinking in 'plain hardware'. I need a FF, which is set by a port signal
    > > and some edge of the clock and is reset by some condition ....
    > > Here some snippets:

    >
    > > nDRdy_sync:
    > >       process
    > >          begin
    > >             wait until falling_edge(nDRDY);
    > >             --transfer := '1';

    >
    > -- "transfer" should be a signal.
    > -- A variable local to the process is OK but invisible outside the process
    > -- A "shared variable" is likely to cause problems and best avoided.
    >               transfer <= '1';
    >               wait until active;        -- a signalof type boolean
    >               transfer <= '0';>          end process;
    >
    > > some other:
    > >       process (mySCLK)
    > >          begin
    > >             ...
    > >             ...
    > >             -- transfer := '0';

    >
    >               active <= true;
    >               ...
    >               -- now the state machine has returned to idle
    >               active <= false;
    >
    > >          end process;

    >
    > Incidentally the first of these processes will probably not synthesise
    > into an FPGA. You would be better off adopting synchronous design using
    > one internal clock, for example:
    >
    > nDRdy_sync: process(clk)
    > variable idle: boolean := true;
    > begin
    >    if rising_edge(clk) then
    >       if idle then
    >          if nDRDY = '0' then
    >             idle := false;
    >             transfer <= '1';
    >          end if;
    >       else
    >          if active then
    >             transfer <= '0';
    >             idle := true;
    >          end if;
    >       end if;
    >    end if;
    > end process;
    >
    > You will also simplify your state machine if you transform the obsolete
    > three-process style into the equivalent single-process state machine. The
    > archives of this group cover state machines on a regular basis.
    >
    > See alsohttp://www.xilinx.com/itp/xilinx4/data/docs/xst/hdlcode15.html
    > and some of Mike Treseler's examples onhttp://mysite.ncnetwork.net/reszotzl/
    >
    > - Brian




    ???
    I get the book VHDL-synthese by Jürgen Reichardt and Bernd Schwarz,
    which discuss a three process, two process and one process approach,
    so I try the first one, because its more clear for the beginning and
    fully synchronized. Speed isn't an issue here.

    Ah, I should implement some kind of hand-shaking, one process rise
    start and waiting for some reply. The other process generate 'stopped'
    after the work is done and the first process clears the start signal.

    But, when the state machine enters the idle state and the start signal
    is still present .....
    ok, my state machine runs through some sequential states so I can drop
    the 'stopped' info earlier, but code will be not very clear ...

    Strange idea, but syntactically there is a chance of working.

    Problem is, that the start signal is async (came from another chip,
    running on another clock, no chance to change that) and is only held
    active as long as I start reading data via SPI.
    So I have to sync and I have to stretch this puls until the state
    machine is done or I have to make changes so the state machine doesnt
    need a permanent signal for running.

    Thanks a lot

    With best regards

    Gerhard
     
    Gerhard, Jun 17, 2011
    #3
  4. On Fri, 17 Jun 2011 07:06:50 -0700, Gerhard wrote:

    > On Jun 17, 1:29 pm, Brian Drummond <> wrote:
    >> On Fri, 17 Jun 2011 03:05:28 -0700, Gerhard wrote:
    >>
    >> > Please tell me, how i should solve such an scenario in VHDL ....

    >>
    >> Drive "start" from one single process.


    >> You will also simplify your state machine if you transform the obsolete
    >> three-process style into the equivalent single-process state machine.
    >> The archives of this group cover state machines on a regular basis.


    > ???
    > I get the book VHDL-synthese by Jürgen Reichardt and Bernd Schwarz,
    > which discuss a three process, two process and one process approach, so
    > I try the first one, because its more clear for the beginning and fully
    > synchronized. Speed isn't an issue here.


    All three will work, and should generate identical hardware. But the
    single-process variant is generally easier to get right, and easier to
    maintain.

    > Ah, I should implement some kind of hand-shaking, one process rise start
    > and waiting for some reply. The other process generate 'stopped' after
    > the work is done and the first process clears the start signal.


    YES, exactly.

    > But, when the state machine enters the idle state and the start signal
    > is still present .....


    then it would re-trigger. If the start signal is of indeterminate length,
    the SM should be designed to wait for start to be retracted before
    entering idle. (the "transfer" signal in my example should be maintained
    until n_RDY -> '1')

    > Problem is, that the start signal is async (came from another chip,
    > running on another clock, no chance to change that) and is only held
    > active as long as I start reading data via SPI. So I have to sync and I
    > have to stretch this puls until the state machine is done or I have to
    > make changes so the state machine doesnt need a permanent signal for
    > running.


    I think you have an understanding of the remaining issues.

    - Brian
     
    Brian Drummond, Jun 17, 2011
    #4
  5. Gerhard

    rickman Guest

    On Jun 17, 10:06 am, Gerhard <> wrote:
    > On Jun 17, 1:29 pm, Brian Drummond <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Fri, 17 Jun 2011 03:05:28 -0700, Gerhard wrote:
    > > > Hi,

    >
    > > > newbe needs help.

    >
    > > > My problem:
    > > > I always get compiler errors, telling me that the net 'start' is
    > > > constantely driven from different places ....

    >
    > > That is a very bad design pattern. There are ways to make it work, but
    > > it's unnecessary here.

    >
    > > > Please tell me, how i should solve such an scenario in VHDL ....

    >
    > > Drive "start" from one single process.

    >
    > > The state machine can feed a second signal ("started", or "finished")
    > > back to that process to let it know when it is safe to return "start" to
    > > zero.

    >
    > > > Thinking in 'plain hardware'. I need a FF, which is set by a port signal
    > > > and some edge of the clock and is reset by some condition ....
    > > > Here some snippets:

    >
    > > > nDRdy_sync:
    > > >       process
    > > >          begin
    > > >             wait until falling_edge(nDRDY);
    > > >             --transfer := '1';

    >
    > > -- "transfer" should be a signal.
    > > -- A variable local to the process is OK but invisible outside the process
    > > -- A "shared variable" is likely to cause problems and best avoided.
    > >               transfer <= '1';
    > >               wait until active;        -- a signal of type boolean
    > >               transfer <= '0';>          end process;

    >
    > > > some other:
    > > >       process (mySCLK)
    > > >          begin
    > > >             ...
    > > >             ...
    > > >             -- transfer := '0';

    >
    > >               active <= true;
    > >               ...
    > >               -- now the state machine has returned to idle
    > >               active <= false;

    >
    > > >          end process;

    >
    > > Incidentally the first of these processes will probably not synthesise
    > > into an FPGA. You would be better off adopting synchronous design using
    > > one internal clock, for example:

    >
    > > nDRdy_sync: process(clk)
    > > variable idle: boolean := true;
    > > begin
    > >    if rising_edge(clk) then
    > >       if idle then
    > >          if nDRDY = '0' then
    > >             idle := false;
    > >             transfer <= '1';
    > >          end if;
    > >       else
    > >          if active then
    > >             transfer <= '0';
    > >             idle := true;
    > >          end if;
    > >       end if;
    > >    end if;
    > > end process;

    >
    > > You will also simplify your state machine if you transform the obsolete
    > > three-process style into the equivalent single-process state machine. The
    > > archives of this group cover state machines on a regular basis.

    >
    > > See alsohttp://www.xilinx.com/itp/xilinx4/data/docs/xst/hdlcode15.html
    > > and some of Mike Treseler's examples onhttp://mysite.ncnetwork.net/reszotzl/

    >
    > > - Brian

    >
    > ???
    > I get the book VHDL-synthese by Jürgen Reichardt and Bernd Schwarz,
    > which discuss a three process, two process and one process approach,
    > so I try the first one, because its more clear for the beginning and
    > fully synchronized. Speed isn't an issue here.
    >
    > Ah, I should implement some kind of hand-shaking, one process rise
    > start and waiting for some reply. The other process generate 'stopped'
    > after the work is done and the first process clears the start signal.
    >
    > But, when the state machine enters the idle state and the start signal
    > is still present .....
    > ok, my state machine runs through some sequential states so I can drop
    > the 'stopped' info earlier, but code will be not very clear ...
    >
    > Strange idea, but syntactically there is a chance of working.
    >
    > Problem is, that the start signal is async (came from another chip,
    > running on another clock, no chance to change that) and is only held
    > active as long as I start reading data via SPI.
    > So I have to sync and I have to stretch this puls until the state
    > machine is done or I have to make changes so the state machine doesnt
    > need a permanent signal for running.



    Can you explain what makes the start signal go away? You mkae it
    sound like accessing the SPI port makes it go away which would be
    perfect if I understand your problem. But you say that your Finite
    State Machine (FSM) reads the SPI port, finishes and the start signal
    is still active. So something is not right with my understanding.

    If the start signal is asserted and cleared independently of your FSM
    then you need to design your machine to detect the assertion, not the
    fact that it is asserted. When the FSM gets to the end of its work,
    the start signal needs to be cleared before the FSM will trigger
    again, in other words, enter a state where you wait for Start to be
    false before you enter the state where it waits for Start to be
    true.

    If the Start signal can be cleared by the FSM, then do that before
    entering the state where it waits for the Start signal to be true.

    That is pretty simple, no?

    I can't say I understand your last part about stretching the Start
    signal. It only needs to be true long enough for the FSM to see that
    it is asserted. As long as that is two clock cycles, it is guaranteed
    to be seen. Then you only need to see it cleared before you return to
    the starting state waiting for Start to be true. Have you somehow
    written your code so that if Start goes away the FSM resets? That
    would be very bad and should be changed.

    One other thought, the code you give that seems to be waiting for
    nDRDY it treating nDRDY as a clock. Probably not a good idea unless
    nDRDY is not guaranteed to be at least two clock cycles long.

    Rick
     
    rickman, Jun 20, 2011
    #5
  6. Gerhard

    logic_guy Guest

    Re: one signal set from two processes .....

    I looks to me like you need something like this.

    Here is a basic single-process state machine with a synchronized start
    pulse. Input signal nDRDY is first synchronized to the state machine
    clock. When nDRDY makes a 1 -> 0 transition, you will get a 1-clock
    cycle pulse on start. This starts the state machine going through its
    steps. When done, it goes back to the IDLE state to wait for another
    start pulse.

    TYPE states is (IDLE, S1, S2, S3, S4);
    SIGNAL state : _states;
    SIGNAL nDRDY_1, nDRDY_2, start : std_logic;

    start <= NOT nDRDY_1 and nDRDY_2;

    clk_proc: PROCESS
    BEGIN
    WAIT until rising_edge(clk);
    nDRDY_1 <= nDRDY;
    nDRDY_2 <= nDRDY_1;
    CASE state is
    WHEN IDLE => If start='1'
    state <= S1;
    end if;
    WHEN S1 => -- Do state 1 processing here
    -- when done:
    state <= S2;
    WHEN S2 => -- Do state 2 processing here
    -- when done:
    state <= S3;
    WHEN S3 => -- Do state 3 processing here
    -- when done:
    state <= S4;
    WHEN S4 => -- Do state 4 processing here
    -- when done:
    state <= IDLE;
    -- Add or subtract states as needed
    END CASE;
    END PROCESS;


    Charles Bailey
     
    logic_guy, Jun 25, 2011
    #6
  7. Re: one signal set from two processes .....

    On 6/25/2011 7:30 PM, logic_guy wrote:
    > TYPE states is (IDLE, S1, S2, S3, S4);
    > SIGNAL state : _states;
    > SIGNAL nDRDY_1, nDRDY_2, start : std_logic;
    >
    > start <= NOT nDRDY_1 and nDRDY_2;
    >
    > clk_proc: PROCESS
    > BEGIN
    > WAIT until rising_edge(clk);
    > nDRDY_1 <= nDRDY;
    > nDRDY_2 <= nDRDY_1;
    > CASE state is
    > WHEN IDLE => If start='1'
    > state <= S1;
    > end if;
    > WHEN S1 => -- Do state 1 processing here
    > -- when done:
    > state <= S2;
    > WHEN S2 => -- Do state 2 processing here
    > -- when done:
    > state <= S3;
    > WHEN S3 => -- Do state 3 processing here
    > -- when done:
    > state <= S4;
    > WHEN S4 => -- Do state 4 processing here
    > -- when done:
    > state <= IDLE;
    > -- Add or subtract states as needed
    > END CASE;
    > END PROCESS;
    >


    I would put start in the process to have it clocked. This would avoid
    any racing problems between nDRDY_1 and nDRDY_2.
    The clause "when others =>" should also be added, to land always on a
    "safe" state.
    I would also honor the OP choice of naming, being the start the input
    signal to this component.

    Last comment is on the choice of the structure "WAIT until" which I'm
    not very accustomed to and seems to me lacking of the "block" view which
    you would get with an "if then end if" syntax.

    I extremely appreciated the simplicity of the example and how well it
    describes what the hardware should do.

    Al
     
    Alessandro Basili, Jul 6, 2011
    #7
  8. On 6/21/2011 12:46 AM, rickman wrote:
    > If the start signal is asserted and cleared independently of your FSM
    > then you need to design your machine to detect the assertion, not the
    > fact that it is asserted. When the FSM gets to the end of its work,
    > the start signal needs to be cleared before the FSM will trigger
    > again, in other words, enter a state where you wait for Start to be
    > false before you enter the state where it waits for Start to be
    > true.


    If you "detect the assertion" there's no need to wait anywhere, since
    you will need another "assertion".
    >
    > If the Start signal can be cleared by the FSM, then do that before
    > entering the state where it waits for the Start signal to be true.
    >


    Again if the FSM is designed to "detect the assertion" as you (and I
    also would) suggest, there's no need to do anything with it.

    > I can't say I understand your last part about stretching the Start
    > signal. It only needs to be true long enough for the FSM to see that
    > it is asserted. As long as that is two clock cycles, it is guaranteed
    > to be seen. Then you only need to see it cleared before you return to
    > the starting state waiting for Start to be true. Have you somehow
    > written your code so that if Start goes away the FSM resets? That
    > would be very bad and should be changed.


    If the start signal is asynchronous it should be first synchronized.
    Once it's synchronized, why the length should be two clock cycles to be
    seen?

    Why would it be bad if the start signal is used to start and reset the
    FSM? I agree the name would be absolutely wrong, since it should be
    called "enable".
    Certainly the reset should be synchronous.

    >
    > One other thought, the code you give that seems to be waiting for
    > nDRDY it treating nDRDY as a clock. Probably not a good idea unless
    > nDRDY is not guaranteed to be at least two clock cycles long.
    >


    I agree is a bad choice to use nDRDY as a clock, but I don't quite
    understand the argument of two clock cycles long, since there's no other
    clock in the process being nDRDY the only one.

    > Rick
     
    Alessandro Basili, Jul 6, 2011
    #8
  9. Gerhard

    logic_guy Guest

    Re: one signal set from two processes .....

    "Alessandro Basili" <> wrote in message
    news:...
    > On 6/25/2011 7:30 PM, logic_guy wrote:
    >> TYPE states is (IDLE, S1, S2, S3, S4);
    >> SIGNAL state : _states;
    >> SIGNAL nDRDY_1, nDRDY_2, start : std_logic;
    >>
    >> start <= NOT nDRDY_1 and nDRDY_2;
    >>
    >> clk_proc: PROCESS
    >> BEGIN
    >> WAIT until rising_edge(clk);
    >> nDRDY_1 <= nDRDY;
    >> nDRDY_2 <= nDRDY_1;
    >> CASE state is
    >> WHEN IDLE => If start='1'
    >> state <= S1;
    >> end if;
    >> WHEN S1 => -- Do state 1 processing here
    >> -- when done:
    >> state <= S2;
    >> WHEN S2 => -- Do state 2 processing here
    >> -- when done:
    >> state <= S3;
    >> WHEN S3 => -- Do state 3 processing here
    >> -- when done:
    >> state <= S4;
    >> WHEN S4 => -- Do state 4 processing here
    >> -- when done:
    >> state <= IDLE;
    >> -- Add or subtract states as needed
    >> END CASE;
    >> END PROCESS;
    >>

    >
    > I would put start in the process to have it clocked. This would avoid
    > any racing problems between nDRDY_1 and nDRDY_2.

    It is not necessary to put "start" in the process because it is the AND
    of nDRDY_1 and nDRDY_2, which are clocked by "clk", so "start" is
    already synchronized with "clk". Also, "start" should not have any
    glitches on it the way it is generated in the example. Even if it did,
    glitches are no problem in a synchronous system as long as the longest
    latch-to-latch path delay is less than the clock period.

    > The clause "when others =>" should also be added, to land always on a
    > "safe" state.

    An "others" clause is not needed here since "state" is defined with
    exactly 5 states, so there are no other states. If you did put an
    "others" clause there some tools would give you a warning that the
    "others" clause is unreachable.

    > I would also honor the OP choice of naming, being the start the input
    > signal to this component.
    >
    > Last comment is on the choice of the structure "WAIT until" which I'm
    > not very accustomed to and seems to me lacking of the "block" view
    > which
    > you would get with an "if then end if" syntax.

    "WAIT until rising_edge(clk);" is a perfectly legitimate way of
    specifying the clock of a clocked process and is simpler to code than
    the "if then end if" syntax. I work on a team that has been designing
    large, multi-million gate ASICs for years and we have 100,000's of lines
    of VHDL coded like that.

    Charles
     
    logic_guy, Jul 8, 2011
    #9
  10. Re: one signal set from two processes .....

    On 7/8/2011 6:04 AM, logic_guy wrote:
    > "Alessandro Basili" <> wrote in message
    >> I would put start in the process to have it clocked. This would avoid
    >> any racing problems between nDRDY_1 and nDRDY_2.

    > It is not necessary to put "start" in the process because it is the AND
    > of nDRDY_1 and nDRDY_2, which are clocked by "clk", so "start" is
    > already synchronized with "clk". Also, "start" should not have any
    > glitches on it the way it is generated in the example. Even if it did,
    > glitches are no problem in a synchronous system as long as the longest
    > latch-to-latch path delay is less than the clock period.
    >


    Indeed, my bad!

    >> The clause "when others =>" should also be added, to land always on a
    >> "safe" state.

    > An "others" clause is not needed here since "state" is defined with
    > exactly 5 states, so there are no other states. If you did put an
    > "others" clause there some tools would give you a warning that the
    > "others" clause is unreachable.
    >


    Depending on the encoding (onehot, gray, etc.) the number of FF you are
    going to use certainly gives you more than 5 states (32 for onehot, 8
    for gray). How the synthesizer is going to know what to do in case your
    FF are presenting a state that is not among the 5?
    But maybe you care if a bit flip will put your FSM in a state out of
    which it cannot get out.

    > "WAIT until rising_edge(clk);" is a perfectly legitimate way of
    > specifying the clock of a clocked process and is simpler to code than
    > the "if then end if" syntax.


    I'm not blaming the illegitimacy of the statement, I simply dislike it
    as to me it lacks of readability and as well the possibility to include
    an asynch reset to the process. If you can post a snippet of a code
    including an asynch reset I would appreciate.

    >
    > Charles
    >
    >
     
    Alessandro Basili, Jul 8, 2011
    #10
  11. Re: one signal set from two processes .....

    Alessandro Basili wrote:

    >> "WAIT until rising_edge(clk);" is a perfectly legitimate way of
    >> specifying the clock of a clocked process and is simpler to code than
    >> the "if then end if" syntax.

    >
    > I'm not blaming the illegitimacy of the statement, I simply dislike it
    > as to me it lacks of readability


    For me readability is the main reason for using and promoting to use "WAIT
    UNTIL clk='1'" (or "WAIT UNTIL rising_edge(clk)").

    As soon as I see "WAIT UNTIL clk='1'", I know that I need not look further
    to see what kind of process it is. It is a pure clocked process without any
    asynchronicities.

    Another (visual/layout) advantage is the lack of a long stretched if-end-if
    statement, which eats up indentation as well.

    > and as well the possibility to include
    > an asynch reset to the process. If you can post a snippet of a code
    > including an asynch reset I would appreciate.


    That is not possible with the WAIT statement.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Jul 8, 2011
    #11
  12. Gerhard

    logic_guy Guest

    Re: one signal set from two processes .....

    "Paul Uiterlinden" <> wrote in message
    news:4e16f3ef$0$21846$4all.nl...
    > For me readability is the main reason for using and promoting to use
    > "WAIT
    > UNTIL clk='1'" (or "WAIT UNTIL rising_edge(clk)").
    >
    > As soon as I see "WAIT UNTIL clk='1'", I know that I need not look
    > further
    > to see what kind of process it is. It is a pure clocked process
    > without any
    > asynchronicities.
    >
    > Another (visual/layout) advantage is the lack of a long stretched
    > if-end-if
    > statement, which eats up indentation as well.
    >

    My sentiments exactly.

    Also, regarding asynchronous resets, those should be avoided wherever
    possible. The logic team I work with is just finishing an ASIC with
    over 900,000 latches. Only a very small handful of those have
    asynchronous resets. That was for a case where some logic needed to be
    reset when the clock wasn't running.

    Charles Bailey
     
    logic_guy, Jul 8, 2011
    #12
  13. Gerhard

    KJ Guest

    Re: one signal set from two processes .....

    On Jul 8, 1:02 am, Alessandro Basili <>
    wrote:
    > On 7/8/2011 6:04 AM, logic_guy wrote:
    > >> The clause "when others =>" should also be added, to land always on a
    > >> "safe" state.

    > > An "others" clause is not needed here since "state" is defined with
    > > exactly 5 states, so there are no other states.  If you did put an
    > > "others" clause there some tools would give you a warning that the
    > > "others" clause is unreachable.

    >
    > Depending on the encoding (onehot, gray, etc.) the number of FF you are
    > going to use certainly gives you more than 5 states (32 for onehot, 8
    > for gray). How the synthesizer is going to know what to do in case your
    > FF are presenting a state that is not among the 5?
    > But maybe you care if a bit flip will put your FSM in a state out of
    > which it cannot get out.
    >


    The synthesis tool default is not to implement safe state machines
    (i.e. ones that return to a particular state if it ever gets into an
    'illegal' state).

    Unless you play with that synthesis tool setting you will not get
    'safe state machines'. In particular, you will not get 'safe state
    machines' regardless of how the FSM states are encoded. But don't
    take my word for it, try your own state machine with and without an
    otherwise unreachable 'when others' clause, and you should see that
    you get the same implementation regardless of state bit encoding...or
    likely regardless of any other settings other than the tool control
    specifically for implementing safe state machines.

    As a parting note, the causes for getting into an illegal state are:
    - Timing problem
    - SEU

    In neither of these situations would it be likely that the correct
    course of action would be to simply go to some arbitrary reset state.

    Kevin Jennings
     
    KJ, Jul 8, 2011
    #13
  14. Re: one signal set from two processes .....

    On 7/8/2011 6:08 PM, KJ wrote:
    > The synthesis tool default is not to implement safe state machines
    > (i.e. ones that return to a particular state if it ever gets into an
    > 'illegal' state).
    >


    Indeed I used to turn on the "safe" mode in Synplify to have what I
    "wanted".

    > Unless you play with that synthesis tool setting you will not get
    > 'safe state machines'. In particular, you will not get 'safe state
    > machines' regardless of how the FSM states are encoded. But don't
    > take my word for it, try your own state machine with and without an
    > otherwise unreachable 'when others' clause, and you should see that
    > you get the same implementation regardless of state bit encoding...or
    > likely regardless of any other settings other than the tool control
    > specifically for implementing safe state machines.
    >


    And indeed the tool tends to optimize away all the "unnecessary" FF
    regardless of the encoding. What I did not know is that in the "safe"
    mode the 'when others' clause is not really followed the way it is
    written and Synplify will resolve the illegal state to the reset state,
    whether it is asynchronous or synchronous:

    > http://klabs.org/richcontent/software_content/safe_state_machines_synplify_1.pdf


    To force the tool to follow the 'when others' clause it is suggested to
    turn off the the FSM compiler. At this point the 'when others' clause
    will be exactly followed (provided the "enumerated type" is changed with
    constants [why???]).

    > As a parting note, the causes for getting into an illegal state are:
    > - Timing problem
    > - SEU
    >
    > In neither of these situations would it be likely that the correct
    > course of action would be to simply go to some arbitrary reset state.
    >


    Assuming the design has gone through timing analysis, the SEU is really
    a concern that in some applications may get you in troubles. That is why
    some communication protocols for space applications (ex. spacewire) can
    recover if the FSM fail over the reset state, causing the link on both
    sides to an "exchange of silence" procedure that will restore communication.

    I do agree that some time a "safe" state maybe safe from the FSM point
    of view but system wise doesn't help that much, unless every part of the
    design is designed to tolerate it.

    Al
     
    Alessandro Basili, Jul 9, 2011
    #14
  15. Re: one signal set from two processes .....

    Paul Uiterlinden <> writes:

    > Alessandro Basili wrote:
    >> and as well the possibility to include
    >> an asynch reset to the process. If you can post a snippet of a code
    >> including an asynch reset I would appreciate.

    >
    > That is not possible with the WAIT statement.


    It sort of is... but it's unpleasant in various ways:

    process is
    begin
    -- do_reset things here
    wait until reset = '0'; -- wait until reset goes away
    main : loop
    wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    -- do one set of things
    wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    -- do another set of things
    -- etc.. repeat long wait until line as many times as necessary
    end loop;
    end process;

    Also on "inferred state machines":

    http://parallelpoints.com/node/69

    (apologies to Chrome users, the code wraps rather than providing scroll-bars
    like in Firefox. I haven't figured out why yet)

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.co.uk/capabilities/39-electronic-hardware
     
    Martin Thompson, Jul 11, 2011
    #15
  16. Re: one signal set from two processes .....

    On 7/11/2011 12:07 PM, Martin Thompson wrote:
    [...]
    > process is
    > begin
    > -- do_reset things here
    > wait until reset = '0'; -- wait until reset goes away
    > main : loop
    > wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    > -- do one set of things
    > wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    > -- do another set of things
    > -- etc.. repeat long wait until line as many times as necessary
    > end loop;
    > end process;
    >


    Isn't the "exit main when reset = '1'" a synchronous reset? The way I
    read is the following:

    - wait until rising_edge(clk) and then
    - if reset = '1' exit the main loop.

    Am I wrong (*)?

    > Also on "inferred state machines":
    >
    > http://parallelpoints.com/node/69
    >


    very interesting approach. And I do share the same view when you say:

    > it saves you having to think of names for your states


    since IMHO what is more critical is the condition under which an FSM
    moves from one state to the other, rather than the state itself.
    The suggestion to move at a higher level of description and leave the
    synthesizer infer whatever is needed to perform the functionality
    described is the right way of exploiting the language. Too many times we
    loose ourselves amongst gates and flops forgetting the big picture.

    Two comments though:

    - giving the impression that "less code is usually good" is a
    misconception (as Nemo's father would say about clownfish). Being on the
    defense line "the smaller the better" usually drives designers to write
    unreadable and therefore unmaintainable code.

    - comparing vhdl with C# in terms of lines of code is risky. Hardware
    acceleration is nothing related to the lines of code and its main goal
    is to search for tasks in the sequential (and/or multi-threaded)
    computing that can be performed in parallel by an external device (or
    additional dedicated CPU) in the hope of being more efficient (number of
    computations/cycle). Nothing related to lines of code.

    > (apologies to Chrome users, the code wraps rather than providing scroll-bars
    > like in Firefox. I haven't figured out why yet)
    >


    Didn't work for me as well, but found the following:

    http://code.google.com/p/chromium/issues/detail?id=10533

    even though they claim they fixed this problem...

    (*) my apologies I cannot try it out myself...reinstalling my pc! :-(
     
    Alessandro Basili, Jul 11, 2011
    #16
  17. Re: one signal set from two processes .....

    Alessandro Basili <> writes:

    > On 7/11/2011 12:07 PM, Martin Thompson wrote:
    > [...]
    >> process is
    >> begin
    >> -- do_reset things here
    >> wait until reset = '0'; -- wait until reset goes away
    >> main : loop
    >> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    >> -- do one set of things
    >> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    >> -- do another set of things
    >> -- etc.. repeat long wait until line as many times as necessary
    >> end loop;
    >> end process;
    >>

    >
    > Isn't the "exit main when reset = '1'" a synchronous reset? The way I
    > read is the following:
    >
    > - wait until rising_edge(clk) and then


    wait until rising_edge(clk) or falling_edge(reset)
    ^^^^^^^^^^^^^^^^^^^^^^

    > - if reset = '1' exit the main loop.
    >
    > Am I wrong (*)?
    >


    reset is also "in the sensitivity list" of the wait statement.

    >> Also on "inferred state machines":
    >>
    >> http://parallelpoints.com/node/69
    >>

    >
    > very interesting approach. And I do share the same view when you say:
    >
    >> it saves you having to think of names for your states

    >
    > since IMHO what is more critical is the condition under which an FSM
    > moves from one state to the other, rather than the state itself.
    > The suggestion to move at a higher level of description and leave the
    > synthesizer infer whatever is needed to perform the functionality
    > described is the right way of exploiting the language. Too many times we
    > loose ourselves amongst gates and flops forgetting the big picture.
    >
    > Two comments though:
    >
    > - giving the impression that "less code is usually good" is a
    > misconception (as Nemo's father would say about clownfish). Being on the
    > defense line "the smaller the better" usually drives designers to write
    > unreadable and therefore unmaintainable code.
    >


    Yes, it always needs some common-sense applying. But note that I didn't
    say "smaller is better".

    "Less code is *usually* good". A much weaker assertion :)

    > - comparing vhdl with C# in terms of lines of code is risky.


    Oh, yes of course - it's not meant to be much more than a
    pseudo-academic "playing with possibilities". My original motivation
    was simply in response to the originally presented HDL solution to show
    that the VHDL *could* look much like the C# approach. (Bar the
    horrible-ness of the clocking construct).

    But I also feel that "lines of code" is not a metric to be completely
    discarded.

    > Hardware acceleration is nothing related to the lines of code and its
    > main goal is to search for tasks in the sequential (and/or
    > multi-threaded) computing that can be performed in parallel by an
    > external device (or additional dedicated CPU) in the hope of being
    > more efficient (number of computations/cycle). Nothing related to
    > lines of code.


    No, but if you can (readably!) do the same thing in many less lines of
    code, that's a win, surely? LOC matters not to the machine, but it is
    still a significant metric to the programmer/designer, and even more so
    to the reviewers of said code.

    Cheers,
    Martin
    (all his own opinions)
     
    Martin Thompson, Jul 12, 2011
    #17
  18. Re: one signal set from two processes .....

    On 7/12/2011 10:46 AM, Martin Thompson wrote:
    > Alessandro Basili <> writes:
    >
    >> On 7/11/2011 12:07 PM, Martin Thompson wrote:
    >> [...]
    >>> process is
    >>> begin
    >>> -- do_reset things here
    >>> wait until reset = '0'; -- wait until reset goes away
    >>> main : loop
    >>> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    >>> -- do one set of things
    >>> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
    >>> -- do another set of things
    >>> -- etc.. repeat long wait until line as many times as necessary
    >>> end loop;
    >>> end process;
    >>>

    >>
    >> Isn't the "exit main when reset = '1'" a synchronous reset? The way I
    >> read is the following:
    >>
    >> - wait until rising_edge(clk) and then

    >
    > wait until rising_edge(clk) or falling_edge(reset)
    > ^^^^^^^^^^^^^^^^^^^^^^
    >


    I was much too distracted by the "exit main when reset = '1';" that I
    totally miss that! Uhm, talking about readability I do admit the reader
    sometimes has his/her own responsability :)
    My apologies.
     
    Alessandro Basili, Jul 12, 2011
    #18
    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. Phil Hays
    Replies:
    1
    Views:
    1,152
    Jeremy Pyle
    Jun 30, 2003
  2. Jonathan Bromley

    Re: Two processes writing one signal

    Jonathan Bromley, Jun 30, 2003, in forum: VHDL
    Replies:
    0
    Views:
    2,238
    Jonathan Bromley
    Jun 30, 2003
  3. Divyang M
    Replies:
    4
    Views:
    1,006
    Divyang M
    Feb 17, 2005
  4. Silver
    Replies:
    7
    Views:
    1,366
    Thomas Stanka
    Oct 16, 2007
  5. jumpz
    Replies:
    5
    Views:
    459
Loading...

Share This Page