Label is required when instantiating a component

[Christiano]

When using process, the label is optional.
Is there any justification for the the label is required when instantiating a component?

Thank you!

 

[GaborSzakacs]

Christiano wrote:

When using process, the label is optional.
Is there any justification for the the label is required when instantiating a component?

Thank you!

What would you expect the instance name for a component to be if you
don't give it a label? Suppose this was legal. Imagine that the
tools just assigned a name like $I265 to some component. Then you
make a change to the design and next time around the component is
called $I267. How are you going to deal with the changing names
in your hierarchy when you need to tell the back-end tools some
attribute like placement?

By the way, this is just the sort of thing that happens in automatically
generated code like schematics translated to VHDL, or System Generator.

Also other places that control hierarchical naming like generate
statements require a label.

--
Gabor

 

[alb]

On 08/08/2013 16:18, GaborSzakacs wrote:

Christiano wrote:
When using process, the label is optional.
Is there any justification for the the label is required when
instantiating a component?

Thank you!

What would you expect the instance name for a component to be if you
don't give it a label? Suppose this was legal. Imagine that the
tools just assigned a name like $I265 to some component. Then you
make a change to the design and next time around the component is
called $I267. How are you going to deal with the changing names
in your hierarchy when you need to tell the back-end tools some
attribute like placement?

Well, why the changing name should bother me? Maybe it can facilitate
waveform tracing, but in the end I wouldn't give a care if my component
is called $I275 or $I1232, since I never refer to that label in my design.

By the way, this is just the sort of thing that happens in automatically
generated code like schematics translated to VHDL, or System Generator.

As long as it is correctly generated, why should I care? (BTW I never
use schematics anyway)

Also other places that control hierarchical naming like generate
statements require a label.

Funny enough though I haven't find any place in the LRM a note or clause
or sentence regarding 'required labels'. It then must be something about
the tool. Maybe I should read harder...

 

[Jim Lewis]

@Christiano

Is there any justification for the the label is required when
instantiating a component?
In the language, anything that creates a level of hierarchy requires a label. Hence, component instances, blocks, generates all require a label. I try to create these algorithmically based on the component name. So for a component named comp, I use comp_1 as its label.

Processes do not create a level of hierarchy, so the name is not required. I name longer processes with starting and ending labels (end process _myProc_) when they span most of a screen or page.

Note I followed a convention like this even in the old days when we did schematic capture. The reason comes back to what @alb noted, when you trace signals through a design, it helps to have these named. Before I used this convention for gate-level designs, I used lots of post-it notes to remember the component names.

I suppose the language could let tools do this, but it does not - after all, gate-level tools did figure this out. Of all the things in the language that need to evolve, this is would be low, low priority. From a business perspective, every language change costs EDA vendors money to implement it - this is one that I do not think is worth the cost.

from @alb
Funny enough though I haven't find any place in the LRM a note or clause
or sentence regarding 'required labels'. It then must be something about
the tool. Maybe I should read harder...
You must read between the text - ie: the BNF.

From IEEE-2008, 11.7.1, P176:
component_instantiation_statement :: instantiation_label :
instantiated_unit
[ generic_map_aspect ]
[ port_map_aspect ] ;

You will note that "instantiation_label" is not surrounded by "[]", and hence, is required.

Jim

 

[Jim Lewis]

@Christiano

Is there any justification for the the label is required when
instantiating a component?
In the language, anything that creates a level of hierarchy requires a label. Hence, component instances, blocks, generates all require a label. I try to create these algorithmically based on the component name. So for a component named comp, I use comp_1 as its label.

Processes do not create a level of hierarchy, so the name is not required. I name longer processes with starting and ending labels (end process myProc) when they span most of a screen or page.

Note I followed a convention like this even in the old days when we did schematic capture. The reason comes back to what @alb noted, when you trace signals through a design, it helps to have these named. Before I used this convention for gate-level designs, I used lots of post-it notes to remember the component names.

I suppose the language could let tools do this, but it does not - after all, gate-level tools did figure this out. Of all the things in the language that need to evolve, this is would be low, low priority. From a business perspective, every language change costs EDA vendors money to implement it - this is one that I do not think is worth the cost.

from @alb
Funny enough though I haven't find any place in the LRM a note or clause
or sentence regarding 'required labels'. It then must be something about
the tool. Maybe I should read harder...
You must read between the text - ie: the BNF.

From IEEE-2008, 11.7.1, P176:
component_instantiation_statement :: instantiation_label :
instantiated_unit
[ generic_map_aspect ]
[ port_map_aspect ] ;

You will note that "instantiation_label" is not surrounded by "[]", and hence, is required.

Jim

 

[Andy]

On Thursday, August 8, 2013 10:07:33 AM UTC-5, alb wrote:

Well, why the changing name should bother me? Maybe it
can facilitate waveform tracing, but in the end I wouldn't
give a care if my component is called $I275 or $I1232,
since I never refer to that label in my design.
....
As long as it is correctly generated, why should I care?
(BTW I never use schematics anyway)

There are other important uses of component instance names besides waveforms and schematics.

For example, some constraints can/should be handled in a constraint file, instead of in the source, especially if the constraints are specific to a tool or target device.

To make constraint files work reliably, you need the design hierarchy to remain stable, preferably even if the design code does not. Allowing the tool to automatically generate instance names often causes seemingly unrelated code modifications to change implied instance labels, invalidating any constraints that reference the instances or any other instances below them.

If a process declares a variable that is implemented as a register, then it is a good idea to label the process.

Also, if you ever use 2008's hierarchical references to access internal signals from a testbench (e.g. white-box testing), you will also need to make sure the hierachical references don't change unexpectedly.

Andy