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

[Zheyu.Gao]

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;

 

[jeppe]

Try this and let me know if its works - then I explain

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;

 

[Tricky]

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.

 

[Zheyu.Gao]

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.

 

[kennheinrich]

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).

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

 

[Tricky]

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).


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).

 

[Zheyu.Gao]

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).


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?

 

[KJ]

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

 

[Tricky]

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.

 

[Mike Treseler]

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

 

[kennheinrich]

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

 

[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 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

 

[kennheinrich]

I do. Many don't.


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

 

[Mike Treseler]

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

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]

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

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