Hierarchical References out of generate block

[hssig]

Hi newsgroup,

I am trying to use VHDL-2008 Hierarchical References in the following way:



process(all)
begin
for k in 0 to 15 loop
tap_vec(k) <= << signal .tb.uut.g_GenArr(k).i_rx.tap_sig : std_logic >>;
end loop;
end process;


"g_GenArr" contains 16 components instantiated in a generate loop.

When compiling with Modelsim 10.1c I get the following error message:
(vcom-1303) An index in an external name must be a globally static expression.


How can I solve that problem?

Cheers, hssig

 

[HT-Lab]

On 06/11/2012 10:54, hssig wrote:

Hi newsgroup,

I am trying to use VHDL-2008 Hierarchical References in the following way:



process(all)
begin
for k in 0 to 15 loop
tap_vec(k) <= << signal .tb.uut.g_GenArr(k).i_rx.tap_sig : std_logic >>;
end loop;
end process;


"g_GenArr" contains 16 components instantiated in a generate loop.

When compiling with Modelsim 10.1c I get the following error message:
(vcom-1303) An index in an external name must be a globally static expression.


How can I solve that problem?

Cheers, hssig

Hi Hssig,

Don't forget the Modelsim verror command which can provide some extra info:

D:\hdl_designs>verror 1303

vcom Message # 1303:
Only a globally static expression is allowed as the index expression
in an indexed name in the pathname of an external name.
[DOC: IEEE Std 1076-2008 VHDL LRM - 8.7 External names]

Hans
www.ht-lab.com

 

[Alan Fitch]

On 06/11/12 10:54, hssig wrote:

Hi newsgroup,

I am trying to use VHDL-2008 Hierarchical References in the following way:



process(all)
begin
for k in 0 to 15 loop
tap_vec(k) <= << signal .tb.uut.g_GenArr(k).i_rx.tap_sig : std_logic >>;
end loop;
end process;


"g_GenArr" contains 16 components instantiated in a generate loop.

When compiling with Modelsim 10.1c I get the following error message:
(vcom-1303) An index in an external name must be a globally static expression.


How can I solve that problem?

Cheers, hssig

Replace your process with a generate, e.g.

g1: for k in 0 to 15 generate
tap_vec(k) <= << signal .tb.uut.g_GenArr(k).i_rx.tap_sig : std_logic >>;
end generate;

then k will be globally static,

Alan


--
Alan Fitch

 

[hssig]

Hi Alan,

replacing the process with a generate works! Fascinating ...

What is the difference between a for loop in a process and a generate loop regarding k being static?


Cheers,
hssig

 

[Andy]

On Wednesday, November 7, 2012 4:32:42 AM UTC-6, hssig wrote:

Hi Alan, replacing the process with a generate works! Fascinating ... What is the difference between a for loop in a process and a generate loop regarding k being static? Cheers, hssig

For loops are sequential statements, and the index is a variable (non-static).

For-generates are concurrent statements, and the index is globally static, similar to a generic. The value is set after compile (analysis), during elaboration (usually the very beginning of most simulators, but some tools have separate elaboration commands.)

The statements in a for-loop execute in sequential order in each iteration.

The concurrent statements in a for-generate execute concurrently. The for-generate is just instantiating the concurrent statements N times.

 

[Alan Fitch]

On 07/11/12 18:59, Andy wrote:

On Wednesday, November 7, 2012 4:32:42 AM UTC-6, hssig wrote:
Hi Alan, replacing the process with a generate works! Fascinating ... What is the difference between a for loop in a process and a generate loop regarding k being static? Cheers, hssig

For loops are sequential statements, and the index is a variable (non-static).

For-generates are concurrent statements, and the index is globally static, similar to a generic. The value is set after compile (analysis), during elaboration (usually the very beginning of most simulators, but some tools have separate elaboration commands.)

The statements in a for-loop execute in sequential order in each iteration.

The concurrent statements in a for-generate execute concurrently. The for-generate is just instantiating the concurrent statements N times.

I agree with Andy

In the standard, certain constructs are described as "dynamically
elaborated", i.e. they are evaluated out at runtime, not at
compile-time. These include (sequential) for loops, and procedure and
function calls.

Regarding globally and locally static - locally static means that a
constant object's value can be determined by compiling (and elaborating)
that one design unit. Globally static means that the whole model needs
to be elaborated to determine the constant value,

regards
Alan

--
Alan Fitch

 

[rickman]

On 11/7/2012 7:34 PM, Alan Fitch wrote:

On 07/11/12 18:59, Andy wrote:
On Wednesday, November 7, 2012 4:32:42 AM UTC-6, hssig wrote:
Hi Alan, replacing the process with a generate works! Fascinating ... What is the difference between a for loop in a process and a generate loop regarding k being static? Cheers, hssig

For loops are sequential statements, and the index is a variable (non-static).

For-generates are concurrent statements, and the index is globally static, similar to a generic. The value is set after compile (analysis), during elaboration (usually the very beginning of most simulators, but some tools have separate elaboration commands.)

The statements in a for-loop execute in sequential order in each iteration.

The concurrent statements in a for-generate execute concurrently. The for-generate is just instantiating the concurrent statements N times.


I agree with Andy

In the standard, certain constructs are described as "dynamically
elaborated", i.e. they are evaluated out at runtime, not at
compile-time. These include (sequential) for loops, and procedure and
function calls.

Regarding globally and locally static - locally static means that a
constant object's value can be determined by compiling (and elaborating)
that one design unit. Globally static means that the whole model needs
to be elaborated to determine the constant value,

I was just looking for some info on hierarchical references and found
this thread. Great info on the differences in "static", clearing up
some of my "static".

Thanks,

Rick