signal sig_s2 can not be assigned, what is wrong with the code?

Discussion in 'VHDL' started by Zheyu.Gao@googlemail.com, Jan 9, 2009.

  1. Guest

    library ieee;
    use ieee.std_logic_1164.all;

    entity sig_test is
    port( d1, d2, d3: in std_logic;
    res1, res2: out std_logic);
    end sig_var;

    architecture behv of sig_var is

    signal sig_s1: std_logic;
    signal sig_s2: std_logic;


    begin

    sig_s1<=d1; -- 1 delta
    sig_s2<=sig_s1; -- 2 delta

    proc2: process(d1,d2,d3)
    begin
    sig_s1 <= d1 ; -- 1 delta
    sig_s2 <= sig_s1; -- 2 delta
    end process;

    end behv;
    , Jan 9, 2009
    #1
    1. Advertising

  2. jeppe

    Joined:
    Mar 10, 2008
    Messages:
    348
    Location:
    Denmark
    Try this and let me know if its works - then I explain

    Code:
    library ieee;
    use ieee.std_logic_1164.all;
    
    entity sig_test is
         port( d1, d2, d3: in std_logic;
                 res1, res2: out std_logic);
    end sig_var;
    
    architecture behv of sig_var is
       signal sig_s1: std_logic;
       signal sig_s2: std_logic;
    begin
       --sig_s1<=d1; -- 1 delta
       --sig_s2<=sig_s1; -- 2 delta
    
    proc2: process(d1,d2,d3,  sig_s1)
    begin
        sig_s1 <= d1 ; -- 1 delta
        sig_s2 <= sig_s1; -- 2 delta
    end process;
    
    end behv;
    jeppe, Jan 9, 2009
    #2
    1. Advertising

  3. Tricky Guest

    On 9 Jan, 07:02, "" <>
    wrote:
    > library ieee;
    > use ieee.std_logic_1164.all;
    >
    > entity sig_test is
    > port(   d1, d2, d3:     in std_logic;
    >         res1, res2:     out std_logic);
    > end sig_var;
    >
    > architecture behv of sig_var is
    >
    >   signal sig_s1: std_logic;
    >   signal sig_s2: std_logic;
    >
    > begin
    >
    >   sig_s1<=d1;    -- 1 delta
    >   sig_s2<=sig_s1; -- 2 delta
    >
    >   proc2: process(d1,d2,d3)
    >   begin
    >         sig_s1 <= d1 ;    -- 1 delta
    >         sig_s2 <= sig_s1; -- 2 delta
    >   end process;
    >
    > end behv;


    You have sig_s1 and sig_s2 assigned in 2 places. You cant do that in
    VHDL. you probably get away with sig_s1 because you're actually
    assigning it the same thing twice.

    With sig_s2, where it is assigned outside the process, it will take
    the value of sig_s1 1 delta after sig_s1 changes.
    Inside the process, it will only take the value of sig_s1 when d1, d2
    or d3 change due to your sensitivity list.

    Remedy: remove the assignments outside the process or the process
    itself.
    Tricky, Jan 9, 2009
    #3
  4. Guest

    On Jan 9, 8:44 am, Tricky <> wrote:
    > On 9 Jan, 07:02, "" <>
    > wrote:
    >
    >
    >
    > > library ieee;
    > > use ieee.std_logic_1164.all;

    >
    > > entity sig_test is
    > > port(   d1, d2, d3:     in std_logic;
    > >         res1, res2:     out std_logic);
    > > end sig_var;

    >
    > > architecture behv of sig_var is

    >
    > >   signal sig_s1: std_logic;
    > >   signal sig_s2: std_logic;

    >
    > > begin

    >
    > >   sig_s1<=d1;    -- 1 delta
    > >   sig_s2<=sig_s1; -- 2 delta

    >
    > >   proc2: process(d1,d2,d3)
    > >   begin
    > >         sig_s1 <= d1 ;    -- 1 delta
    > >         sig_s2 <= sig_s1; -- 2 delta
    > >   end process;

    >
    > > end behv;

    >
    > You have sig_s1 and sig_s2 assigned in 2 places. You cant do that in
    > VHDL. you probably get away with sig_s1 because you're actually
    > assigning it the same thing twice.
    >
    > With sig_s2, where it is assigned outside the process, it will take
    > the value of sig_s1 1 delta after sig_s1 changes.
    > Inside the process, it will only take the value of sig_s1 when d1, d2
    > or d3 change due to your sensitivity list.
    >
    > Remedy: remove the assignments outside the process or the process
    > itself.


    Thanks Tricky, I have figured it out now, I think it's because the
    sig_s2 update value of d1 at 1 delta outside the process, but the at
    the same time, sig_s2 update value of sig_s1 at 1 delta which is
    undefined at 0 delta. so last one take effect, that's why sig_s2 is
    undefined during simulation.
    , Jan 9, 2009
    #4
  5. Guest

    On Jan 9, 4:30 am, ""
    <> wrote:
    > On Jan 9, 8:44 am, Tricky <> wrote:
    >
    >
    >
    > > On 9 Jan, 07:02, "" <>
    > > wrote:

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

    >
    > > > entity sig_test is
    > > > port(   d1, d2, d3:     in std_logic;
    > > >         res1, res2:     out std_logic);
    > > > end sig_var;

    >
    > > > architecture behv of sig_var is

    >
    > > >   signal sig_s1: std_logic;
    > > >   signal sig_s2: std_logic;

    >
    > > > begin

    >
    > > >   sig_s1<=d1;    -- 1 delta
    > > >   sig_s2<=sig_s1; -- 2 delta

    >
    > > >   proc2: process(d1,d2,d3)
    > > >   begin
    > > >         sig_s1 <= d1 ;    -- 1 delta
    > > >         sig_s2 <= sig_s1; -- 2 delta
    > > >   end process;

    >
    > > > end behv;

    >


    Actually, when I compile this, all I get is the message pointing out
    that labels on the entity declaration are mismatched (should both be
    sig_var, not sig_var and sig_test).

    > > You have sig_s1 and sig_s2 assigned in 2 places. You cant do that in
    > > VHDL.


    Beg to differ. You can do that quite happily in VHDL as long as the
    signal has a resolved type. Each process creates a driver for each
    signal that gets assigned within that process. Then the resolution
    function runs to, well, resolve what the final "winner" state should
    be from all the drivers on the same signal. This is how std_logic tri-
    state busses work.

    - Kenn
    , Jan 9, 2009
    #5
  6. Tricky Guest

    On 9 Jan, 09:54, wrote:
    > On Jan 9, 4:30 am, ""
    >
    >
    >
    > <> wrote:
    > > On Jan 9, 8:44 am, Tricky <> wrote:

    >
    > > > On 9 Jan, 07:02, "" <>
    > > > wrote:

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

    >
    > > > > entity sig_test is
    > > > > port(   d1, d2, d3:     in std_logic;
    > > > >         res1, res2:     out std_logic);
    > > > > end sig_var;

    >
    > > > > architecture behv of sig_var is

    >
    > > > >   signal sig_s1: std_logic;
    > > > >   signal sig_s2: std_logic;

    >
    > > > > begin

    >
    > > > >   sig_s1<=d1;    -- 1 delta
    > > > >   sig_s2<=sig_s1; -- 2 delta

    >
    > > > >   proc2: process(d1,d2,d3)
    > > > >   begin
    > > > >         sig_s1 <= d1 ;    -- 1 delta
    > > > >         sig_s2 <= sig_s1; -- 2 delta
    > > > >   end process;

    >
    > > > > end behv;

    >
    > Actually, when I compile this, all I get is the message pointing out
    > that labels on the entity declaration are mismatched (should both be
    > sig_var, not sig_var and sig_test).
    >
    > > > You have sig_s1 and sig_s2 assigned in 2 places. You cant do that in
    > > > VHDL.

    >
    > Beg to differ. You can do that quite happily in VHDL as long as the
    > signal has a resolved type. Each process creates a driver for each
    > signal that gets assigned within that process. Then the resolution
    > function runs to, well, resolve what the final "winner" state should
    > be from all the drivers on the same signal. This is how std_logic tri-
    > state busses work.
    >
    >  - Kenn


    My Bad.

    I must have been thinking about unresolved types (but its generally
    not a good idea to have internal tri-states in FPGAs).
    Tricky, Jan 9, 2009
    #6
  7. Guest

    On Jan 9, 9:54 am, wrote:
    > On Jan 9, 4:30 am, ""
    >
    >
    >
    > <> wrote:
    > > On Jan 9, 8:44 am, Tricky <> wrote:

    >
    > > > On 9 Jan, 07:02, "" <>
    > > > wrote:

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

    >
    > > > > entity sig_test is
    > > > > port(   d1, d2, d3:     in std_logic;
    > > > >         res1, res2:     out std_logic);
    > > > > end sig_var;

    >
    > > > > architecture behv of sig_var is

    >
    > > > >   signal sig_s1: std_logic;
    > > > >   signal sig_s2: std_logic;

    >
    > > > > begin

    >
    > > > >   sig_s1<=d1;    -- 1 delta
    > > > >   sig_s2<=sig_s1; -- 2 delta

    >
    > > > >   proc2: process(d1,d2,d3)
    > > > >   begin
    > > > >         sig_s1 <= d1 ;    -- 1 delta
    > > > >         sig_s2 <= sig_s1; -- 2 delta
    > > > >   end process;

    >
    > > > > end behv;

    >
    > Actually, when I compile this, all I get is the message pointing out
    > that labels on the entity declaration are mismatched (should both be
    > sig_var, not sig_var and sig_test).
    >
    > > > You have sig_s1 and sig_s2 assigned in 2 places. You cant do that in
    > > > VHDL.

    >
    > Beg to differ. You can do that quite happily in VHDL as long as the
    > signal has a resolved type. Each process creates a driver for each
    > signal that gets assigned within that process. Then the resolution
    > function runs to, well, resolve what the final "winner" state should
    > be from all the drivers on the same signal. This is how std_logic tri-
    > state busses work.
    >
    >  - Kenn


    I agree with you. Kenn, buy the way, what simulator are you using for
    VHDL, I am using modelsim, is there one can show synthesised circuit?
    , Jan 9, 2009
    #7
  8. KJ Guest

    "Tricky" <> wrote in message
    news:...
    <snip>
    > You have sig_s1 and sig_s2 assigned in 2 places. You cant do that in
    > VHDL. you probably get away with sig_s1 because you're actually
    > assigning it the same thing twice.


    And Zheyu has also provided a good example for why one should use std_ulogic
    type rather than std_logic for signals that are intended to have only one
    driver (see other thread titled 'bit, std_logic, std_ulogic'). Using
    std_ulogic, the compiler would immediately flag the offending lines and say
    there is an error. Using std_logic type you need to debug to find the
    problem.

    Kevin Jennings
    KJ, Jan 9, 2009
    #8
  9. Tricky Guest

    On 9 Jan, 10:48, "" <>
    wrote:
    > On Jan 9, 9:54 am, wrote:
    >
    >
    >
    > > On Jan 9, 4:30 am, ""

    >
    > > <> wrote:
    > > > On Jan 9, 8:44 am, Tricky <> wrote:

    >
    > > > > On 9 Jan, 07:02, "" <>
    > > > > wrote:

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

    >
    > > > > > entity sig_test is
    > > > > > port(   d1, d2, d3:     in std_logic;
    > > > > >         res1, res2:     out std_logic);
    > > > > > end sig_var;

    >
    > > > > > architecture behv of sig_var is

    >
    > > > > >   signal sig_s1: std_logic;
    > > > > >   signal sig_s2: std_logic;

    >
    > > > > > begin

    >
    > > > > >   sig_s1<=d1;    -- 1 delta
    > > > > >   sig_s2<=sig_s1; -- 2 delta

    >
    > > > > >   proc2: process(d1,d2,d3)
    > > > > >   begin
    > > > > >         sig_s1 <= d1 ;    -- 1 delta
    > > > > >         sig_s2 <= sig_s1; -- 2 delta
    > > > > >   end process;

    >
    > > > > > end behv;

    >
    > > Actually, when I compile this, all I get is the message pointing out
    > > that labels on the entity declaration are mismatched (should both be
    > > sig_var, not sig_var and sig_test).

    >
    > > > > You have sig_s1 and sig_s2 assigned in 2 places. You cant do that in
    > > > > VHDL.

    >
    > > Beg to differ. You can do that quite happily in VHDL as long as the
    > > signal has a resolved type. Each process creates a driver for each
    > > signal that gets assigned within that process. Then the resolution
    > > function runs to, well, resolve what the final "winner" state should
    > > be from all the drivers on the same signal. This is how std_logic tri-
    > > state busses work.

    >
    > >  - Kenn

    >
    > I agree with you. Kenn, buy the way, what simulator are you using for
    > VHDL, I am using modelsim, is there one can show synthesised circuit?


    No simulator will show you the synthesized version of the code,
    because the simulator does not synthesise your code, just simulate it.
    That means you can do alot of stuff in simualatiib you couldnt or
    wouldnt do in real hardware.

    You'll need a synthesiser for that. You could get the Quartus Webpack
    and I think Xilinx offer a similar package for free. Not sure if they
    allow RTL/technology view though without a paid for licence.
    Tricky, Jan 9, 2009
    #9
  10. KJ wrote:

    > And Zheyu has also provided a good example for why one should use std_ulogic
    > type rather than std_logic for signals that are intended to have only one
    > driver (see other thread titled 'bit, std_logic, std_ulogic'). Using
    > std_ulogic, the compiler would immediately flag the offending lines and say
    > there is an error. Using std_logic type you need to debug to find the
    > problem.


    Yes, std_ulogic is satisfactory in all cases except
    that of a top level, tristate port.
    std_ulogic interfaces directly with std_logic without conversion.

    -- Mike Treseler
    Mike Treseler, Jan 10, 2009
    #10
  11. Guest

    On Jan 9, 11:02 pm, Mike Treseler <> wrote:
    > KJ wrote:
    > > And Zheyu has also provided a good example for why one should use std_ulogic
    > > type rather than std_logic for signals that are intended to have only one
    > > driver (see other thread titled 'bit, std_logic, std_ulogic').  Using
    > > std_ulogic, the compiler would immediately flag the offending lines and say
    > > there is an error.  Using std_logic type you need to debug to find the
    > > problem.

    >
    > Yes, std_ulogic is satisfactory in all cases except
    > that of a top level, tristate port.
    > std_ulogic interfaces directly with std_logic without conversion.
    >
    >   -- Mike Treseler


    This raises an interesting point. While it appears that many of the
    recent posters agree that std_ulogic is safer (i.e. guaranteed not to
    generate unexpected internal tristate busses, and able to force
    compiler errors when multiple drivers wired together) than std_logic
    inside a chip, how many of you guys actually do that as a matter of
    course inside your designs?

    I can't remember the last time I saw a publicly available module (like
    from Xilinx XAPPs, or some of the open source cores) that used
    std_ulogic ports. I can also guarantee that there are some very large
    industrial code bases that don't have a single occurrence of the word
    "std_ulogic" in them.

    - Kenn
    , Jan 10, 2009
    #11
  12. > On Jan 9, 11:02 pm, Mike Treseler <> wrote:
    >> Yes, std_ulogic is satisfactory in all cases except
    >> that of a top level, tristate port.
    >> std_ulogic interfaces directly with std_logic without conversion.


    wrote:
    > This raises an interesting point. While it appears that many of the
    > recent posters agree that std_ulogic is safer (i.e. guaranteed not to
    > generate unexpected internal tristate busses, and able to force
    > compiler errors when multiple drivers wired together) than std_logic
    > inside a chip, how many of you guys actually do that as a matter of
    > course inside your designs?


    I do. Many don't.

    > I can't remember the last time I saw a publicly available module (like
    > from Xilinx XAPPs, or some of the open source cores) that used
    > std_ulogic ports. I can also guarantee that there are some very large
    > industrial code bases that don't have a single occurrence of the word
    > "std_ulogic" in them.


    So it goes.
    It probably doesn't matter much except to novices,
    and to the readers of recurring threads such as this one.
    Once I have learned that only one process can
    drive an signal/port, I just don't do it anymore.

    -- Mike Treseler
    Mike Treseler, Jan 10, 2009
    #12
  13. Guest

    On Jan 10, 10:27 am, Mike Treseler <> wrote:
    > > On Jan 9, 11:02 pm, Mike Treseler <> wrote:
    > >> Yes, std_ulogic is satisfactory in all cases except
    > >> that of a top level, tristate port.
    > >> std_ulogic interfaces directly with std_logic without conversion.

    > wrote:
    > > This raises an interesting point. While it appears that many of the
    > > recent posters agree that std_ulogic is safer (i.e. guaranteed not to
    > > generate unexpected internal tristate busses, and able to force
    > > compiler errors when multiple drivers wired together) than std_logic
    > > inside a chip, how many of you guys actually do that as a matter of
    > > course inside your designs?

    >
    > I do. Many don't.
    >
    > > I can't remember the last time I saw a publicly available module (like
    > > from Xilinx XAPPs, or some of the open source cores) that used
    > > std_ulogic ports. I can also guarantee that there are some very large
    > > industrial code bases that don't have a single occurrence of the word
    > > "std_ulogic" in them.

    >
    > So it goes.
    > It probably doesn't matter much except to novices,
    > and to the readers of recurring threads such as this one.
    > Once I have learned that only one process can
    > drive an signal/port, I just don't do it anymore.
    >
    >              -- Mike Treseler


    Corollary: has anyone who's used std_ulogic found any mixed-language
    (verilog) problems? I know *in theory* they're effectively the same,
    but that's not always enough :-( There was a time when we found we had
    to treat any interface that potentially had to interoperate with
    verilog with kid gloves: std_logic only, and integer generics only.
    Even boolean generics didn't map properly with verilog parameters with
    all tools. It was kind of frustrating: we could do all this neat
    record-passing and fancy type-checked parametrization inside the pure
    VHDL code, but then had to write a wrapper for everything that "dumbed-
    down" the interface to make it instantiable from verilog.

    - Kenn
    , Jan 10, 2009
    #13
  14. > On Jan 10, 10:27 am, Mike Treseler <> wrote:

    >> It probably doesn't matter much except to novices,
    >> and to the readers of recurring threads such as this one.
    >> Once I have learned that only one process can
    >> drive an signal/port, I just don't do it anymore.

    -----
    (where "do it" = drive from multiple processes)

    wrote:
    > Corollary: has anyone who's used std_ulogic found any mixed-language
    > (verilog) problems?


    Not with std_ulogic.
    I often write vhdl tests for verilog modules.

    > There was a time when we found we had
    > to treat any interface that potentially had to interoperate with
    > verilog with kid gloves: std_logic only, and integer generics only.
    > Even boolean generics didn't map properly with verilog parameters with
    > all tools. It was kind of frustrating: we could do all this neat
    > record-passing and fancy type-checked parametrization inside the pure
    > VHDL code, but then had to write a wrapper for everything that "dumbed-
    > down" the interface to make it instantiable from verilog.


    I might consider "smartening" the verilog module with a vhdl wrapper.

    -- Mike Treseler
    Mike Treseler, Jan 10, 2009
    #14
  15. > On Jan 10, 10:27 am, Mike Treseler <> wrote:

    >> It probably doesn't matter much except to novices,
    >> and to the readers of recurring threads such as this one.
    >> Once I have learned that only one process can
    >> drive an signal/port, I just don't do it anymore.

    -----
    (where "do it" = drive from multiple processes)

    wrote:
    > Corollary: has anyone who's used std_ulogic found any mixed-language
    > (verilog) problems?


    Not with std_ulogic.
    I often write vhdl tests for verilog modules.

    > There was a time when we found we had
    > to treat any interface that potentially had to interoperate with
    > verilog with kid gloves: std_logic only, and integer generics only.
    > Even boolean generics didn't map properly with verilog parameters with
    > all tools. It was kind of frustrating: we could do all this neat
    > record-passing and fancy type-checked parametrization inside the pure
    > VHDL code, but then had to write a wrapper for everything that "dumbed-
    > down" the interface to make it instantiable from verilog.


    I might consider "smartening" the verilog module with a vhdl wrapper.

    -- Mike Treseler
    Mike Treseler, Jan 10, 2009
    #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. Replies:
    0
    Views:
    461
  2. =?iso-8859-15?Q?Fabr=EDcio_de_Novaes_Kucinskis?=

    Session Variables assigned to the wrong session?

    =?iso-8859-15?Q?Fabr=EDcio_de_Novaes_Kucinskis?=, Jan 20, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    709
    Alvin Bruney [MVP]
    Jan 20, 2005
  3. Robert Faulkner
    Replies:
    0
    Views:
    877
    Robert Faulkner
    Jan 28, 2005
  4. Nicolas Moreau
    Replies:
    9
    Views:
    3,126
  5. elin05
    Replies:
    7
    Views:
    1,412
    joris
    Jul 21, 2010
Loading...

Share This Page