global shared resources

[Ed J]

Is there a way in VHDL for two separate modules to share signals without
having to declare them as input and/or output ports? The only way I know
how to do it is to explicitly declare the ports in both modules, and tie the
signals together through a common ancestor in the VHDL hierarchy. Is there
a way around that? I'm hoping for some kind of support for "global signals"
that infer connectivity by nature of a common name.

Ed

 

[Mike Treseler]

Ed J wrote:

Is there a way in VHDL for two separate modules to share signals without
having to declare them as input and/or output ports?

The vhdl language and simulation
tools allow packaged signals to be
used like that. Most synthesis
tools do not support this usage.

Processes within the same architecture
can access the same signals. All can
read, only one can drive.

Procedures within the same process can share
the same local process variables.

-- Mike Treseler

 

[Ralf Hildebrandt]

Ed J wrote:

Is there a way in VHDL for two separate modules to share signals without
having to declare them as input and/or output ports?

You may use:
shared variable

Note: As this is a variable, it is updated immediately when a process
executes and modifies it. So don't test for rising_edge / falling_edge
of this shared variable as this may result in a race condition.

(As you name the VHDL components "modules" I guess you are a Verilog
user: shared variable have similar behavior to blocked signal
assignments. (And also blocked signal assignments should not be used
inside sequential statements.))


Remember: For synthesis a normal signal (fed through via input / output)
is the best choice in most cases.

Ralf

 

[Barry Brown]

<biau@altavista.com> wrote in message
news:1106203853.859668.275330@z14g2000cwz.googlegroups.com...

Not all tools are compliant with this VHDL usage, however, and, as Mike
pointed out, synthesis tools are frequent offenders. About two years
ago I tried this and found that Synplify Pro did not allow signals in
packages but Xilinx XST did. So, don't try "global" signals without
checking compatibility with the VHDL tools that you are using or likely
to port to.

I checked the Synplify Pro 7.5 Ref manual, and it says that global signals
in packages are supported (page 10-3).

 

That is good news. It was probably Synplify Pro 6 or earlier that I
tried back then.

 

[Charles Bailey]

Also, all processes with the same architecture can read or write shared
variables.

Charles Bailey

 

<<The only way I know
how to do it is to explicitly declare the ports in both modules, and
tie the
signals together through a common ancestor in the VHDL hierarchy. >>

That is the normal--and one might say--clean way to do it.

<<Is there
a way around that? I'm hoping for some kind of support for "global
signals"
that infer connectivity by nature of a common name.>>

As Mike Tressler pointed out, you can declare the global signals in a
package, which makes them global to all architectures (modules) that
care to reference them--provided that the architecture takes care to
make the library where the package is declared visible through a
library clause and the package and signals visible through use clauses.

One situation where this might make sense is when "debug" signals are
needed. Putting in temporary port signals to carry debug signals
through the hierarchy is somewhat of a pain in the neck.

Not all tools are compliant with this VHDL usage, however, and, as Mike
pointed out, synthesis tools are frequent offenders. About two years
ago I tried this and found that Synplify Pro did not allow signals in
packages but Xilinx XST did. So, don't try "global" signals without
checking compatibility with the VHDL tools that you are using or likely
to port to.