Methods for flow control

Discussion in 'VHDL' started by carloshyneman@gmail.com, Oct 18, 2012.

  1. Guest

    Hello,

    I like sharing some ideas to see the different points of view out there! :D

    Assuming that you have a pipelined design that does some calculation that requires 10 (or N) clock cycles of latency.
    The module is supposed to be able to perform flow control (pause its input and avoid writing to its output) whenever its output is busy, so the interface would look something similar to the one shown below.

    The way I see it, there are two main ways (at least that I know of) to implement correct flow control:
    #1- Use a clock enable signal that is controlled by busy_in, connect busy_out to busy_in, and disable your data_out_val whenever busy_out is set.
    #2- Don't using a clock enable on your processing, use a FIFO at the end ofyour processing that is deep enough to accommodate the remaining data flushed from the pipe (at least 10 elements), use an almost full flag, connect busy_out to busy_in, and empty the FIFO when the output is not busy.

    I usually use method #1 (roughly shown below)
    The way I see it, you save some resources (no FIFO) and the registers and multipliers already have a clock enable port, so no extra logic is required.

    - Are there any major pros/cons to using a method over another other?
    - Would you guys implement that differently?

    C.

    entity test is
    port (
    clk : in std_logic;
    reset : out std_logic;
    -- input port
    data_in : in std_logic_vector(7 downto 0);
    data_in_val : in std_logic;
    busy_out : out std_logic;
    -- output port
    data_out : out std_logic_vector(7 downto 0);
    data_out_val : in std_logic;
    busy_in : in std_logic
    );
    end test;

    architecture my_arc of test is
    type type_data_array is array (0 to 9) of std_logic_vector(7 downto 0);
    signal my_data_array : type_data_array;
    signal my_data_val : std_logic_vector(9 downto 0);
    signal my_enable : std_logic;

    begin

    my_enable <= not busy_in;
    busy_out <= busy_in;

    data_out <= my_data_array(9);
    data_out_val <= my_data_val(9) and (not busy_in);

    my_processing : process (clk)
    begin
    if rising_edge(clk) then
    if reset = '1' then
    my_data_array <= (others => (others => '0'));
    my_data_val <= (others => '0');
    elsif my_enable = '1' then

    -- shift register (emulates some random processing)
    my_data_array(0) <= data_in;
    my_data_val(0) <= data_in_val;
    for i in 1 to 9 loop
    my_data_array(i) <= my_data_array(i-1);
    my_data_val(i) <= my_data_val(i-1)
    end loop;

    end if;
    end if;
    end process my_processing;

    end my_arc;
     
    , Oct 18, 2012
    #1
    1. Advertising

  2. Guest

    Am Donnerstag, 18. Oktober 2012 16:35:57 UTC+2 schrieb :
    > Hello,
    >
    >
    >
    > I like sharing some ideas to see the different points of view out there! :D
    >
    >
    >
    > Assuming that you have a pipelined design that does some calculation thatrequires 10 (or N) clock cycles of latency.
    >
    > The module is supposed to be able to perform flow control (pause its input and avoid writing to its output) whenever its output is busy, so the interface would look something similar to the one shown below.
    >
    >
    >
    > The way I see it, there are two main ways (at least that I know of) to implement correct flow control:
    >
    > #1- Use a clock enable signal that is controlled by busy_in, connect busy_out to busy_in, and disable your data_out_val whenever busy_out is set.
    >
    > #2- Don't using a clock enable on your processing, use a FIFO at the end of your processing that is deep enough to accommodate the remaining data flushed from the pipe (at least 10 elements), use an almost full flag, connect busy_out to busy_in, and empty the FIFO when the output is not busy.
    >
    >
    >
    > I usually use method #1 (roughly shown below)
    >
    > The way I see it, you save some resources (no FIFO) and the registers andmultipliers already have a clock enable port, so no extra logic is required.
    >
    >
    >
    > - Are there any major pros/cons to using a method over another other?
    >
    > - Would you guys implement that differently?
    >
    >
    >
    > C.
    >
    >
    >
    > entity test is
    >
    > port (
    >
    > clk : in std_logic;
    >
    > reset : out std_logic;
    >
    > -- input port
    >
    > data_in : in std_logic_vector(7 downto 0);
    >
    > data_in_val : in std_logic;
    >
    > busy_out : out std_logic;
    >
    > -- output port
    >
    > data_out : out std_logic_vector(7 downto 0);
    >
    > data_out_val : in std_logic;
    >
    > busy_in : in std_logic
    >
    > );
    >
    > end test;
    >
    >
    >
    > architecture my_arc of test is
    >
    > type type_data_array is array (0 to 9) of std_logic_vector(7 downto 0);
    >
    > signal my_data_array : type_data_array;
    >
    > signal my_data_val : std_logic_vector(9 downto 0);
    >
    > signal my_enable : std_logic;
    >
    >
    >
    > begin
    >
    >
    >
    > my_enable <= not busy_in;
    >
    > busy_out <= busy_in;
    >
    >
    >
    > data_out <= my_data_array(9);
    >
    > data_out_val <= my_data_val(9) and (not busy_in);
    >
    >
    >
    > my_processing : process (clk)
    >
    > begin
    >
    > if rising_edge(clk) then
    >
    > if reset = '1' then
    >
    > my_data_array <= (others => (others => '0'));
    >
    > my_data_val <= (others => '0');
    >
    > elsif my_enable = '1' then
    >
    >
    >
    > -- shift register (emulates some random processing)
    >
    > my_data_array(0) <= data_in;
    >
    > my_data_val(0) <= data_in_val;
    >
    > for i in 1 to 9 loop
    >
    > my_data_array(i) <= my_data_array(i-1);
    >
    > my_data_val(i) <= my_data_val(i-1)
    >
    > end loop;
    >
    >
    >
    > end if;
    >
    > end if;
    >
    > end process my_processing;
    >
    >
    >
    > end my_arc;


    Hi,
    it depends on the structure of your pipelined algorithm.
    If it is as simple as mentioned, that you have a number of independent stages, then you don't even need to stop the system. You only need to flag valid data.

    The pipeline will continue to process the input, but without the data beingvalid.

    However, it depends on the following modules if it is necessary to stop thedata input at some time. But this can be done early (depending on the length of the pipeline) directly from the "slow" module.

    If you have some more complicated pipeline with feedbacks things are entirely different. These must be filled and flushed in a controlled way.

    So everything can be done in a special way.

    But maybe you prefer a design that uses standardized interfaces and handshakes between the modules. In that case you need to think about the type of data you are processing. If the data goes through the pipeline in a word by word way, stoping the pipeline would be OK. But if you are processing blocks of data the fifo solution will be preferable to ensure that always a complete block is available at the input of the next module.

    These are just some thoughts on the topic and far from being complete.
    There are just too many things having influence to the way you are doing the flow controll in a system.
    In any case you have to ensure that no deadlocks or pipeline stalls can happen with the chosen way of flow controll. Also data throughput and ressource usage should be taken into account when designing such a system.

    Have a nice synthesis
    Eilert
     
    , Oct 19, 2012
    #2
    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. Andrea Moro
    Replies:
    7
    Views:
    2,195
    Karl Seguin
    Jul 13, 2005
  2. pavs

    CONTROL FLOW GRAPH

    pavs, Feb 28, 2005, in forum: Java
    Replies:
    1
    Views:
    742
    bugbear
    Mar 7, 2005
  3. Replies:
    0
    Views:
    394
  4. Jack Dowson
    Replies:
    0
    Views:
    482
    Jack Dowson
    May 7, 2007
  5. Kenneth McDonald
    Replies:
    5
    Views:
    387
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page