When did global signals become part of VHDL

[Tricky]

I was just wondering when global signals became part of VHDL, and
whether they should be synthesisable. Quartus wont synthesise the
following saying:

Error (10808): VHDL error at test_build.vhd(33): unsupported reference
to global signal or variable my_sig
Error (10784): HDL error at test_build.vhd(5): see declaration for
object "my_sig"


ibrary ieee;
use ieee.std_logic_1164.all;

package sig_p is
signal my_sig : std_logic;
end package sig_p;



library IEEE;
use IEEE.STD_LOGIC_1164.all;
use ieee.numeric_std.all;

use work.sig_p.all;

entity test_build is
port(
clk : in std_logic;
a : in std_logic;

b : out std_logic
);
end test_build;

architecture BEHAVIOR of test_build is
signal r : std_logic;
begin

process(clk)
begin
if rising_edge(clk) then
r <= a;
my_sig <= r;
b <= my_sig;
end if;
end process;


end BEHAVIOR;

 

[Alan Fitch]

Tricky wrote:

I was just wondering when global signals became part of VHDL, and
whether they should be synthesisable. Quartus wont synthesise the
following saying:

As far as I know, signals have been allowed in a package since "the dawn
of time" (i.e. VHDL 87!).

I've been told that Synplify synthesises them, but I must admit I
haven't tried it...

Alan

--
Alan Fitch
Doulos
http://www.doulos.com

 

[HT-Lab]

"Tricky" <Trickyhead@gmail.com> wrote in message
news:9e212068-112d-45d2-b4ec-0bfcf52eb4a4@w39g2000prb.googlegroups.com...

I was just wondering when global signals became part of VHDL, and
whether they should be synthesisable. Quartus wont synthesise the
following saying:

Error (10808): VHDL error at test_build.vhd(33): unsupported reference
to global signal or variable my_sig
Error (10784): HDL error at test_build.vhd(5): see declaration for
object "my_sig"

Same with Mentor's Precision, not supported.

Hans
www.ht-lab.com

ibrary ieee;
use ieee.std_logic_1164.all;

package sig_p is
signal my_sig : std_logic;
end package sig_p;



library IEEE;
use IEEE.STD_LOGIC_1164.all;
use ieee.numeric_std.all;

use work.sig_p.all;

entity test_build is
port(
clk : in std_logic;
a : in std_logic;

b : out std_logic
);
end test_build;

architecture BEHAVIOR of test_build is
signal r : std_logic;
begin

process(clk)
begin
if rising_edge(clk) then
r <= a;
my_sig <= r;
b <= my_sig;
end if;
end process;


end BEHAVIOR;

 

[Brian Drummond]

On Thu, 15 Jan 2009 03:01:48 -0800 (PST), Tricky <Trickyhead@gmail.com>
wrote:

I was just wondering when global signals became part of VHDL, and
whether they should be synthesisable. Quartus wont synthesise the
following saying:

Error (10808): VHDL error at test_build.vhd(33): unsupported reference
to global signal or variable my_sig

Been around for a long time; never intended to be synthesisable.
And rightly so IMO; too many possibilities for hard-to-track-down
problems as with a global variable in C code.

But it has potential uses, e.g. to examine signals anywhere deep in the
hierarchy in simulation, without bringing them out on ports.

The following is probably a safe usage with wide applicability.

package sig_p is
signal my_sig : std_logic;
end package sig_p;
....
process(clk)
begin
if rising_edge(clk) then
r <= a;
-- pragma translate off

if test_this_module then -- probably a generic

my_sig <= r;
end if;

-- pragma translate on

b <= my_sig;
end if;
end process;

for bonus points, use functions to minimise added crap to the real code,
and more flexible conditions to dynamically change the signals being
monitored...
.... having said all that, I confess I haven't played with the technique
much.

- Brian

 

[HT-Lab]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:tv7um45a97fu9altaqqa0cg2prk6os5q34@4ax.com...

On Thu, 15 Jan 2009 03:01:48 -0800 (PST), Tricky <Trickyhead@gmail.com
wrote:

I was just wondering when global signals became part of VHDL, and
whether they should be synthesisable. Quartus wont synthesise the
following saying:

Error (10808): VHDL error at test_build.vhd(33): unsupported reference
to global signal or variable my_sig

Been around for a long time; never intended to be synthesisable.
And rightly so IMO; too many possibilities for hard-to-track-down
problems as with a global variable in C code.

But it has potential uses, e.g. to examine signals anywhere deep in the
hierarchy in simulation, without bringing them out on ports.

If you have access to Modelsim then SignalSpy is easier IMHO. Of course this
will become somewhat obsolete when VHDL2008 becomes available.

Hans.
www.ht-lab.com

The following is probably a safe usage with wide applicability.

package sig_p is
signal my_sig : std_logic;
end package sig_p;
...
process(clk)
begin
if rising_edge(clk) then
r <= a;
-- pragma translate off
if test_this_module then -- probably a generic
my_sig <= r;
end if;
-- pragma translate on
b <= my_sig;
end if;
end process;

for bonus points, use functions to minimise added crap to the real code,
and more flexible conditions to dynamically change the signals being
monitored...
... having said all that, I confess I haven't played with the technique
much.

- Brian

 

[HT-Lab]

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:2db7eb4b-e26c-401e-9824-9127db3af48d@o40g2000yqb.googlegroups.com...
On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:

But it has potential uses, e.g. to examine signals anywhere deep in the
hierarchy in simulation, without bringing them out on ports.


Not sure I follow what use you have in mind. In simulation there is
no need to bring signals "deep in the hierarchy" up to ports...you
simply add them to the wave window. Even in code intended for
synthesis the need really isn't there for global signals for debug
since debug tools that let you bring out most any signal to some form
of logic analyzer port or via the JTAG interface.

Kevin Jennings

I agree with Brian that this is a very useful feature. I use SignalSpy to
connect a testbench bus monitor to signals deep in the hierarchy. The last
thing I want to do is to connect all those signal via portmaps/entities up
to the top level.

Hans
www.ht-lab.com

 

[KJ]

On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

But it has potential uses, e.g. to examine signals anywhere deep in the
hierarchy in simulation, without bringing them out on ports.

Not sure I follow what use you have in mind. In simulation there is
no need to bring signals "deep in the hierarchy" up to ports...you
simply add them to the wave window. Even in code intended for
synthesis the need really isn't there for global signals for debug
since debug tools that let you bring out most any signal to some form
of logic analyzer port or via the JTAG interface.

Kevin Jennings

 

[KJ]

On Jan 15, 8:52 am, KJ <kkjenni...@sbcglobal.net> wrote:

On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:



But it has potential uses, e.g. to examine signals anywhere deep in the
hierarchy in simulation, without bringing them out on ports.

Not sure I follow what use you have in mind. In simulation there is
no need to bring signals "deep in the hierarchy" up to ports...you
simply add them to the wave window. Even in code intended for
synthesis the need really isn't there for global signals for debug
since debug tools that let you bring out most any signal to some form
of logic analyzer port or via the JTAG interface.

Disregard previous post...in simulation you're probably referring to
getting communication between two separate models without the overhead
of bringing signals all the way up and down the chain which can be
useful for design verification purposes.

When you said 'examine signals' that through me off.

KJ

 

[Dave]

On Jan 15, 9:09 am, "HT-Lab" <han...@ht-lab.com> wrote:

"KJ" <kkjenni...@sbcglobal.net> wrote in message
news:2db7eb4b-e26c-401e-9824-9127db3af48d@o40g2000yqb.googlegroups.com....
On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:

But it has potential uses, e.g. to examine signals anywhere deep in the
hierarchy in simulation, without bringing them out on ports.

Not sure I follow what use you have in mind.  In simulation there is
no need to bring signals "deep in the hierarchy" up to ports...you
simply add them to the wave window.  Even in code intended for
synthesis the need really isn't there for global signals for debug
since debug tools that let you bring out most any signal to some form
of logic analyzer port or via the JTAG interface.

Kevin Jennings

I agree with Brian that this is a very useful feature. I use SignalSpy to
connect a testbench bus monitor to signals deep in the hierarchy. The last
thing I want to do is to connect all those signal via portmaps/entities up
to the top level.

Hanswww.ht-lab.com

I like the idea of synthesizing global signals for test port
connections. We use the free version of ISE and Modelsim XE, and don't
have access to SignalSpy or ChipScope. Yes, global signals could be
abused just like global variables in C, but I don't think that is a
reason to disallow it. And if global signals are dangerous, isn't
SignalSpy super-dangerous, since it essentially gives global scope to
all of your signals? I've never used SignalSpy, so I might have the
wrong idea of how it works.

Dave

 

[HT-Lab]

"Dave" <dhschetz@gmail.com> wrote in message
news:93cb20a4-5e88-4e14-a41c-a18b17050311@s9g2000prg.googlegroups.com...
On Jan 15, 9:09 am, "HT-Lab" <han...@ht-lab.com> wrote:

"KJ" <kkjenni...@sbcglobal.net> wrote in message
news:2db7eb4b-e26c-401e-9824-9127db3af48d@o40g2000yqb.googlegroups.com...
On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com
.....

I like the idea of synthesizing global signals for test port
connections. We use the free version of ISE and Modelsim XE, and don't
have access to SignalSpy or ChipScope.

Your Modelsim XE version should support SignalSpy, AFAIK it is only crippled
in performance and instance count.

Yes, global signals could be
abused just like global variables in C, but I don't think that is a
reason to disallow it. And if global signals are dangerous, isn't
SignalSpy super-dangerous, since it essentially gives global scope to
all of your signals?

Why would it be dangerous, it is not a global signal. It simply maps/mirrors
2 signals at different levels in the hierarchy.

I've never used SignalSpy, so I might have the
wrong idea of how it works.

Have a look at it, I think it is ideal for writing testbench monitors.

Hans
www.ht-lab.com

Dave

 

[Dave]

On Jan 15, 10:48 am, "HT-Lab" <han...@ht-lab.com> wrote:

"Dave" <dhsch...@gmail.com> wrote in message

news:93cb20a4-5e88-4e14-a41c-a18b17050311@s9g2000prg.googlegroups.com...
On Jan 15, 9:09 am, "HT-Lab" <han...@ht-lab.com> wrote:

"KJ" <kkjenni...@sbcglobal.net> wrote in message
news:2db7eb4b-e26c-401e-9824-9127db3af48d@o40g2000yqb.googlegroups.com....
On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com
....

I like the idea of synthesizing global signals for test port
connections. We use the free version of ISE and Modelsim XE, and don't
have access to SignalSpy or ChipScope.

Your Modelsim XE version should support SignalSpy, AFAIK it is only crippled
in performance and instance count.

Yes, global signals could be
abused just like global variables in C, but I don't think that is a
reason to disallow it. And if global signals are dangerous, isn't
SignalSpy super-dangerous, since it essentially gives global scope to
all of your signals?

Why would it be dangerous, it is not a global signal. It simply maps/mirrors
2 signals at different levels in the hierarchy.

I've never used SignalSpy, so I might have the
wrong idea of how it works.

Have a look at it, I think it is ideal for writing testbench monitors.

Hanswww.ht-lab.com



Dave

I misunderstood - I had the impression that SignalSpy would give you
that visibility for synthesis, not only simulation. My mistake.

Dave

 

[Brian Drummond]

On Thu, 15 Jan 2009 14:09:44 -0000, "HT-Lab" <hans64@ht-lab.com> wrote:

"KJ" <kkjennings@sbcglobal.net> wrote in message
news:2db7eb4b-e26c-401e-9824-9127db3af48d@o40g2000yqb.googlegroups.com...
On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:

But it has potential uses, e.g. to examine signals anywhere deep in the
hierarchy in simulation, without bringing them out on ports.


Not sure I follow what use you have in mind. In simulation there is
no need to bring signals "deep in the hierarchy" up to ports...you
simply add them to the wave window.

My interest is in having the testbench do the verification where
possible.
Of course you are right that you can manually inspect signals in the
wave window for debugging; but that's hardly a verification technique!

I agree with Brian that this is a very useful feature. I use SignalSpy to
connect a testbench bus monitor to signals deep in the hierarchy. The last
thing I want to do is to connect all those signal via portmaps/entities up
to the top level.

Can SignalSpy connect them back into a VHDL testbench, or do you port
the verification stuff into another language?

- Brian

 

[HT-Lab]

"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:dhfvm4pg49tkmipa1glanqp3eh4br788er@4ax.com...

On Thu, 15 Jan 2009 14:09:44 -0000, "HT-Lab" <hans64@ht-lab.com> wrote:


"KJ" <kkjennings@sbcglobal.net> wrote in message
news:2db7eb4b-e26c-401e-9824-9127db3af48d@o40g2000yqb.googlegroups.com...
On Jan 15, 6:50 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:
...

I agree with Brian that this is a very useful feature. I use SignalSpy to
connect a testbench bus monitor to signals deep in the hierarchy. The last
thing I want to do is to connect all those signal via portmaps/entities up
to the top level.

Can SignalSpy connect them back into a VHDL testbench, or do you port
the verification stuff into another language?

If you are asking if SignalSpy supports mixed languages than the answer is
yes, that is you can mirror a VHDL signal to say a Verilog net/register or a
SystemC signal and vice versa. SignalSpy also allows you to drive and force
a signal anywhere in the hierarchy.

Hans.
www.ht-lab.com

- Brian

 

[Brian Davis]

Dave wrote:

I like the idea of synthesizing global signals for test port
connections. We use the free version of ISE and Modelsim XE, and don't
have access to SignalSpy or ChipScope.

Note that XST's support of globals in synthesis is very
limited, so this won't work as an in circuit probe.

There was a thread about this over on comp.arch.fpga
last fall, summary post here:
http://groups.google.com/group/comp.arch.fpga/msg/59f20575a54da960

Brian

 

[Tricky]

On 18 Jan, 14:52, Brian Davis <brimda...@aol.com> wrote:

Dave wrote:

I like the idea of synthesizing global signals for test port
connections. We use the free version of ISE and Modelsim XE, and don't
have access to SignalSpy or ChipScope.

 Note that XST's support of globals in synthesis is very
limited, so this won't work as an in circuit probe.

 There was a thread about this over on comp.arch.fpga
last fall, summary post here:http://groups.google.com/group/comp.arch.fpga/msg/59f20575a54da960

Brian

Had a reply from Altera that basically on the lines of Brian
Drummond's post. They will not support it and do not recommend coding
in this way.