confusion about signal assignments...

Discussion in 'VHDL' started by Neil, Apr 23, 2008.

  1. Neil

    Neil Guest

    hi, all,

    I want to know some feathures of signal, so i just write a test design file
    as follow to check
    how the signal assignment works. but it doesn't work as I think.
    In my opinion, finally, bOut should be 22, and aOut should be 11, since
    there is a delta delay for the assignment of signal.
    but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    11.
    so what's wrong in my thought, can anyone explain it? thank you.

    library ieee;
    use ieee.std_logic_1164.all;
    use ieee.std_logic_unsigned.all;

    entity test is
    port(
    aOut : out integer range 0 to 100;
    bOut : out integer range 0 to 100);
    end entity test;

    architecture behave of test is
    signal a: integer range 0 to 100 := 11; -- assign the initial values
    signal b : integer range 0 to 100 := 22;
    begin
    process(a, b) -- the current value of a is 11 as default, and the b is
    22 as default
    begin
    a <= b; -- assign the current value of b to a, but not really
    assigned yet
    b <= a; -- assign the current value of a to b, but not really
    assigned yet
    aOut <= a; -- assign the current value of a to aOut, but not really
    assigned yet
    bOut <= b; -- assign the current value of b to bOut, but not really
    assigned yet
    end process; -- and now, all assignments take effect, and the value
    of a is 22, the value b is 11
    -- and with next process execution, the value of aOut
    and bOut is 22 and 11 for each
    end architecture behave;

    but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    11

    Best Regards!
    -- Neil
    Neil, Apr 23, 2008
    #1
    1. Advertising

  2. Neil

    eko

    Joined:
    Apr 16, 2008
    Messages:
    12
    You generate combinational logic. Combinational logic pretty much does everything at the same time. Whenever a signal changes, this change affects whatever other signals are tied to it right away.
    In order to get a discrete, sequential processing you will need a clock driven process.
    eko, Apr 23, 2008
    #2
    1. Advertising

  3. Neil

    Guest

    On Apr 23, 4:12 am, "Neil" <> wrote:
    > hi, all,
    >
    > I want to know some feathures of signal, so i just write a test design file
    > as follow to check
    > how the signal assignment works. but it doesn't work as I think.
    > In my opinion, finally, bOut should be 22, and aOut should be 11, since
    > there is a delta delay for the assignment of signal.
    > but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    > 11.
    > so what's wrong in my thought, can anyone explain it? thank you.
    >
    > library ieee;
    > use ieee.std_logic_1164.all;
    > use ieee.std_logic_unsigned.all;
    >
    > entity test is
    > port(
    > aOut : out integer range 0 to 100;
    > bOut : out integer range 0 to 100);
    > end entity test;
    >
    > architecture behave of test is
    > signal a: integer range 0 to 100 := 11; -- assign the initial values
    > signal b : integer range 0 to 100 := 22;
    > begin
    > process(a, b) -- the current value of a is 11 as default, and the b is
    > 22 as default
    > begin
    > a <= b; -- assign the current value of b to a, but not really
    > assigned yet
    > b <= a; -- assign the current value of a to b, but not really
    > assigned yet
    > aOut <= a; -- assign the current value of a to aOut, but not really
    > assigned yet
    > bOut <= b; -- assign the current value of b to bOut, but not really
    > assigned yet
    > end process; -- and now, all assignments take effect, and the value
    > of a is 22, the value b is 11
    > -- and with next process execution, the value of aOut
    > and bOut is 22 and 11 for each
    > end architecture behave;
    >
    > but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    > 11
    >
    > Best Regards!
    > -- Neil


    In Modelsim 6.0, I get an "iteration limit reached at time 0 ns".
    This makes sense; you're basically saying that you want signals a and
    b to exchange values every time the process executes, so you'll either
    have a steady-state with a=b (if they happen to be the same initial
    values), or a never-ending exchange (oscillation). Since there's no
    time parameter involved, this process executes at time 0, swaps the
    values, the drivers update, all delta cycles are finished, then the
    process gets put back on the ready queue (since a and b changed,
    that's your sensitivity list), but still at time 0. This happens
    forever, always at time 0, presumably until Modelsim decides to pull
    the plug.

    - Kenn
    , Apr 23, 2008
    #3
  4. Neil wrote:

    > so what's wrong in my thought, can anyone explain it? thank you.


    1. Your asynchronous process loops more than once.
    2. Signals always contain the value
    received in the *previous* loop.

    I prefer a synchronous process because
    it loops only once per rising_edge(clock).

    I prefer process variables because
    they always use the *present* value.

    I believe that this is more in line
    with what a new student of
    hardware description expects.

    -- Mike Treseler
    Mike Treseler, Apr 23, 2008
    #4
  5. Neil

    Duane Clark Guest

    Neil wrote:
    > hi, all,
    >
    > I want to know some feathures of signal, so i just write a test design file
    > as follow to check
    > how the signal assignment works. but it doesn't work as I think.
    > In my opinion, finally, bOut should be 22, and aOut should be 11, since
    > there is a delta delay for the assignment of signal.
    > but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    > 11.
    > so what's wrong in my thought, can anyone explain it? thank you.


    Stick a wait just before the end process, and you can see what is happening.

    wait for 1 us;
    end process;
    end architecture behave;
    Duane Clark, Apr 23, 2008
    #5
  6. Neil

    Duane Clark Guest

    Duane Clark wrote:
    >
    > wait for 1 us;
    > end process;
    > end architecture behave;


    And remove the sensitivity list...
    Duane Clark, Apr 23, 2008
    #6
  7. Neil

    jens Guest

    For something that may be more interesting and is a closer match to a
    real-world scenario, try this (and predict or figure out why the
    outputs are doing what they're doing):

    entity test is
    port
    (
    clk: in std_logic;
    input: in integer;
    output1: out integer;
    output2: out integer;
    output3: out integer;
    output4: out integer
    );
    end entity test;

    architecture behave of test is
    signal a1: integer;
    signal b1: integer;
    signal c1: integer;
    signal a2: integer;
    signal b2: integer;
    signal c2: integer;
    begin
    process(clk)
    variable a3: integer;
    variable b3: integer;
    variable c3: integer;
    variable a4: integer;
    variable b4: integer;
    variable c4: integer;
    begin
    if rising_edge(clk) then

    -- output1
    a1 <= input;
    b1 <= a1;
    c1 <= b1;
    output1 <= c1;

    -- output2
    output2 <= c2;
    c2 <= b2;
    b2 <= a2;
    a2 <= input;

    -- output3
    a3 := input;
    b3 := a3;
    c3 := b3;
    output3 <= c3;

    -- output4
    output4 <= c4;
    c4 := b4;
    b4 := a4;
    a4 := input;

    end if;
    end process;
    end architecture behave;
    jens, Apr 23, 2008
    #7
  8. jens wrote:
    > For something that may be more interesting and is a closer match to a
    > real-world scenario, try this (and predict or figure out why the
    > outputs are doing what they're doing):



    I'll bite, since your example is clean
    and includes an entity.
    I would recommend turning this job over to
    synthesis once the lesson is learned.

    > if rising_edge(clk) then
    >
    > -- output1
    > a1 <= input;
    > b1 <= a1;
    > c1 <= b1;
    > output1 <= c1;
    >
    > -- output2
    > output2 <= c2;
    > c2 <= b2;
    > b2 <= a2;
    > a2 <= input;


    The order of cascaded signal assignments makes no difference.
    Only the input has an immediate value.
    I'd expect four cascaded regs in either case:

    input-[a]--[c]-[o]-output


    Order matters with variables,
    and all values are immediate.

    A variable right before left
    *or* on the right of a port
    makes a reg.

    > -- output3
    > a3 := input; -- wire
    > b3 := a3; -- wire
    > c3 := b3; -- wire
    > output3 <= c3; -- reg


    input-----------[o]-output

    > -- output4
    > output4 <= c4; -- reg
    > c4 := b4; -- reg
    > b4 := a4; -- reg
    > a4 := input; -- reg


    input-[a]--[c]-[o]-output


    -- Mike Treseler
    Mike Treseler, Apr 23, 2008
    #8
  9. Neil

    Guest

    On 4ÔÂ23ÈÕ, ÏÂÎç10ʱ27·Ö, Duane Clark <> wrote:
    > Neil wrote:
    > > hi, all,

    >
    > > I want to know some feathures of signal, so i just write a test design file
    > > as follow to check
    > > how the signal assignment works. but it doesn't work as I think.
    > > In my opinion, finally, bOut should be 22, and aOut should be 11, since
    > > there is a delta delay for the assignment of signal.
    > > but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    > > 11.
    > > so what's wrong in my thought, can anyone explain it? thank you.

    >
    > Stick a wait just before the end process, and you can see what is happening.
    >
    > wait for 1 us;
    > end process;
    > end architecture behave;


    yeah, I try to add "wait for 50 ns", and it works to change the
    value...
    but I can't not simulate this in QuartusII, does QuartusII 7.2SP2 not
    support wait for statement? Analyzing is OK, but can't to generate the
    function netlist, it prompts:
    "Error (10533): VHDL Wait Statement error at test.vhd(23): Wait
    Statement must contain condition clause with UNTIL keyword"
    and even if I add the until condition, it still doesn't work.

    Regards!
    -- Neil
    , Apr 25, 2008
    #9
  10. Neil

    Guest

    On 4ÔÂ23ÈÕ, ÏÂÎç9ʱ44·Ö, Mike Treseler <> wrote:
    > Neil wrote:
    > > so what's wrong in my thought, can anyone explain it? thank you.

    >
    > 1. Your asynchronous process loops more than once.
    > 2. Signals always contain the value
    > received in the *previous* loop.
    >
    > I prefer a synchronous process because
    > it loops only once per rising_edge(clock).
    >
    > I prefer process variables because
    > they always use the *present* value.
    >
    > I believe that this is more in line
    > with what a new student of
    > hardware description expects.
    >
    > -- Mike Treseler


    thanks, Mike.

    it seems I almost know the why...
    , Apr 25, 2008
    #10
  11. Neil

    Guest

    On 4ÔÂ23ÈÕ, ÏÂÎç9ʱ44·Ö, Mike Treseler <> wrote:
    > Neil wrote:
    > > so what's wrong in my thought, can anyone explain it? thank you.

    >
    > 1. Your asynchronous process loops more than once.
    > 2. Signals always contain the value
    > received in the *previous* loop.
    >
    > I prefer a synchronous process because
    > it loops only once per rising_edge(clock).
    >
    > I prefer process variables because
    > they always use the *present* value.
    >
    > I believe that this is more in line
    > with what a new student of
    > hardware description expects.
    >
    > -- Mike Treseler


    but, one more problem:
    the assignment(changing) of a and b will always trigger the process,
    so the process will loop all the time until simulation time ends.
    if thinking in this way, the value of a and b will exchage all the
    time since all the statements in a process totally execute for each
    trigger. especially with following feature:
    > 2. Signals always contain the value
    > received in the *previous* loop.


    and at least, at the simulation time 0, the aOut shoule be the
    previous value of a which is 11, and the bOut should be the previous
    value of b which is 22.

    this makes me confusion again... thank you!

    Regards!
    -- Neil
    , Apr 25, 2008
    #11
  12. wrote:

    > yeah, I try to add "wait for 50 ns", and it works to change the
    > value...
    > but I can't not simulate this in QuartusII, does QuartusII 7.2SP2 not
    > support wait for statement? Analyzing is OK, but can't to generate the
    > function netlist, it prompts:
    > "Error (10533): VHDL Wait Statement error at test.vhd(23): Wait
    > Statement must contain condition clause with UNTIL keyword"
    > and even if I add the until condition, it still doesn't work.


    Adding the wait was a demonstration
    to answer your vhdl question,
    not a recommendation for synthesis code.

    I stand by my advice to vhdl novices
    to start with a synchronous process
    for synthesis code.

    Note also that the Altera-Modelsim
    simulator that comes with a quartus
    license is far superior to any
    of the 'free' simulators that
    I have tried.

    -- Mike Treseler
    Mike Treseler, Apr 25, 2008
    #12
  13. Neil

    Guest

    On 4ÔÂ23ÈÕ, ÏÂÎç8ʱ34·Ö, wrote:
    > On Apr 23, 4:12 am, "Neil" <> wrote:
    >
    >
    >
    >
    >
    > > hi, all,

    >
    > > I want to know some feathures of signal, so i just write a test design file
    > > as follow to check
    > > how the signal assignment works. but it doesn't work as I think.
    > > In my opinion, finally, bOut should be 22, and aOut should be 11, since
    > > there is a delta delay for the assignment of signal.
    > > but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    > > 11.
    > > so what's wrong in my thought, can anyone explain it? thank you.

    >
    > > library ieee;
    > > use ieee.std_logic_1164.all;
    > > use ieee.std_logic_unsigned.all;

    >
    > > entity test is
    > > port(
    > > aOut : out integer range 0 to 100;
    > > bOut : out integer range 0 to 100);
    > > end entity test;

    >
    > > architecture behave of test is
    > > signal a: integer range 0 to 100 := 11; -- assign the initial values
    > > signal b : integer range 0 to 100 := 22;
    > > begin
    > > process(a, b) -- the current value of a is 11 as default, and the b is
    > > 22 as default
    > > begin
    > > a <= b; -- assign the current value of b to a, but not really
    > > assigned yet
    > > b <= a; -- assign the current value of a to b, but not really
    > > assigned yet
    > > aOut <= a; -- assign the current value of a to aOut, but not really
    > > assigned yet
    > > bOut <= b; -- assign the current value of b to bOut, but not really
    > > assigned yet
    > > end process; -- and now, all assignments take effect, and the value
    > > of a is 22, the value b is 11
    > > -- and with next process execution, the value of aOut
    > > and bOut is 22 and 11 for each
    > > end architecture behave;

    >
    > > but the simulation in QuartusII 7.2, the results are: aOut and bOut are both
    > > 11

    >
    > > Best Regards!
    > > -- Neil

    >
    > In Modelsim 6.0, I get an "iteration limit reached at time 0 ns".
    > This makes sense; you're basically saying that you want signals a and
    > b to exchange values every time the process executes, so you'll either
    > have a steady-state with a=b (if they happen to be the same initial
    > values), or a never-ending exchange (oscillation). Since there's no
    > time parameter involved, this process executes at time 0, swaps the
    > values, the drivers update, all delta cycles are finished, then the
    > process gets put back on the ready queue (since a and b changed,
    > that's your sensitivity list), but still at time 0. This happens
    > forever, always at time 0, presumably until Modelsim decides to pull
    > the plug.
    >
    > - Kenn- Òþ²Ø±»ÒýÓÃÎÄ×Ö -
    >
    > - ÏÔʾÒýÓõÄÎÄ×Ö -


    hi, Kenn,

    thank you.

    so, that means, if the sensitivity list changes and there is no longer
    delay(which is much larger than delta) after all delta cycles
    finished, the process will be triggerd again immediately without push
    simulation time forward?
    but this should not make the values of aOut and bOut both 11 ... at
    least, at simulation time 0, the results of aOut and bOut should be 22
    and 11 each.
    , Apr 25, 2008
    #13
  14. Neil

    Duane Clark Guest

    wrote:
    >
    > but, one more problem:
    > the assignment(changing) of a and b will always trigger the process,
    > so the process will loop all the time until simulation time ends.
    > if thinking in this way, the value of a and b will exchage all the
    > time since all the statements in a process totally execute for each
    > trigger.


    In a synchronous process, you only have CLK in the sensitivity list, so
    that will not happen.
    Duane Clark, Apr 25, 2008
    #14
  15. Neil

    Andy Guest

    On Apr 23, 3:41 pm, Mike Treseler <> wrote:
    > Order matters with variables,
    > and all values are immediate.
    >
    > A variable right before left
    > *or* on the right of a port
    > makes a reg.


    To clarify, the assignment to the port in a clocked process,
    regardless of whether a variable or anything else appears on the
    right, is a register. If there is a reference to a variable on the
    right has not been written in that clock cycle, then that variable
    reference is also a register (two total).

    -- two registers between in_port and out_port
    if rising_edge(clk) then
    out_port <= var;
    var := in_port;
    end if;

    -- one register between in_port and out_port
    if rising_edge(clk) then
    var := in_port;
    out_port <= var;
    end if;

    Just remember that variables execute like software, and the synthesis
    tool will insert registers to make the cycle-cycle timing of the
    hardware match that of the process.

    Andy
    Andy, Apr 25, 2008
    #15
    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. Alex Rast
    Replies:
    3
    Views:
    661
  2. Michael Pronath
    Replies:
    1
    Views:
    1,166
    Diez B. Roggisch
    Jan 3, 2005
  3. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    463
    Jack Orenstein
    Sep 18, 2005
  4. Tim Frink

    Signal assignments

    Tim Frink, Nov 26, 2007, in forum: VHDL
    Replies:
    7
    Views:
    521
  5. mamu
    Replies:
    4
    Views:
    598
    Barry
    Dec 11, 2008
Loading...

Share This Page