Selecting an Architecture to Instantiate

[Gary Pace]

Hi :

I have a component that has more than one architecture where the best
architecture to use depends on the value of the generic parameters.

In this case it's a combinatorial unsigned normalize and prioritize where if
the width is 2^N I can do simple bit slices, but otherwise I need to do
something more complex and less efficient.

I know I can directly instance an entity and specify the architecture, but I
would like to make this decision within "component.vhd" based upon the
generics found during elaboration, so that higher level entities that use
the function are not involved in the decision.

Is this possible ?

Thanks
Gary

 

[Charles Gardiner]

Haven't tried it myself, but as long as you don't have to be compatible
to VHDL '87, I expect you can. Use direct instantiation and something
like the following:

Architecture ....
....
Begin ...

UG1:
if (generic_1 = constant_1) generate
U1: entity work.entity_name(arch1)
port map(....
end generate;

UG2:
if (generic_1 = constant_2) generate
U1: entity work.entity_name(arch2)
port map(....
end generate;


Gary Pace schrieb:

Hi :

I have a component that has more than one architecture where the best
architecture to use depends on the value of the generic parameters.

In this case it's a combinatorial unsigned normalize and prioritize where if
the width is 2^N I can do simple bit slices, but otherwise I need to do
something more complex and less efficient.

I know I can directly instance an entity and specify the architecture, but I
would like to make this decision within "component.vhd" based upon the
generics found during elaboration, so that higher level entities that use
the function are not involved in the decision.

Is this possible ?

Thanks
Gary

 

[Gary Pace]

Thanks Charles.
I was hoping to avoid direct instantiation, so that level of the hierachy
that uses (for example) Normalize would look like this :

architecture A of FPU
begin
NormalizeShort : Normalize -- Defined as a component in a package
generic map ( W => 16 ,
PW => 4 )
port map (In => ShortX,
Eq0 => ShortZeroFlag,
Norm => ShortNorm,
Priority => ShortPriority ) ;

NormalizeIntermediate : Normalize -- Defined as a component in a package
generic map ( W => 24 ,
PW => 5)
port map (In => InterX,
Eq0 => InterZeroFlag,
Norm => InterNorm,
Priority => InterPriority ) ;
......
end architecture A ;

So the entity FPU has no concept of how many architectures are present in
Normalize or which will be used and why.

I finally did this in a similar way to your suggestion, but I embedded the
generic test inside the only process within the only architecture :

architecture A of Normalize
begin
process Implement
begin
if (LOG2(W) - 1 = LOG2(W-1)) THEN
-- Process in slices
else
-- Process bit by bit
end if ;
end process Implement ;
end architecture A ;



"Charles Gardiner" <invalid@invalid.invalid> wrote in message
news:gj3r1j$aaq$00$1@news.t-online.com...

Haven't tried it myself, but as long as you don't have to be compatible
to VHDL '87, I expect you can. Use direct instantiation and something
like the following:

Architecture ....
....
Begin ...

UG1:
if (generic_1 = constant_1) generate
U1: entity work.entity_name(arch1)
port map(....
end generate;

UG2:
if (generic_1 = constant_2) generate
U1: entity work.entity_name(arch2)
port map(....
end generate;


Gary Pace schrieb:
Hi :

I have a component that has more than one architecture where the best
architecture to use depends on the value of the generic parameters.

In this case it's a combinatorial unsigned normalize and prioritize where
if
the width is 2^N I can do simple bit slices, but otherwise I need to do
something more complex and less efficient.

I know I can directly instance an entity and specify the architecture,
but I
would like to make this decision within "component.vhd" based upon the
generics found during elaboration, so that higher level entities that use
the function are not involved in the decision.

Is this possible ?

Thanks
Gary

 

[Thomas Stanka]

Hi,

On 26 Dez., 23:55, "Gary Pace" <a...@def.com> wrote:

would like to make this decision within "component.vhd" based upon the
generics found during elaboration, so that higher level entities that use
the function are not involved in the decision.

Is this possible ?

I would use configurations for this task. The decision is taken in the
configuration of the next higher hierachy than the entity that has
several architectures.

bye Thomas

 

[Gary Pace]

"Thomas Stanka" <usenet_nospam_valid@stanka-web.de> wrote in message
news:086bc067-bf6d-42e6-bcbf-630ac22a3296@r15g2000prd.googlegroups.com...

Hi,

On 26 Dez., 23:55, "Gary Pace" <a...@def.com> wrote:
would like to make this decision within "component.vhd" based upon the
generics found during elaboration, so that higher level entities that use
the function are not involved in the decision.

Is this possible ?

I would use configurations for this task. The decision is taken in the
configuration of the next higher hierachy than the entity that has
several architectures.

bye Thomas

Thomas :
Thanks.
I considered this, but it was rather the opposite of the encapsulation I was
trying to achieve.
The engineer working on the higher level entity would need to know the
details of the implementation of the component they were using in order to
make the right choice of architecture.
I wanted the component itself to instantiate the optimal structure based on
the parameters.
I have done it with IF-THEN-ELSE in the process(es) of the component
architecture, but this does "mix up" the alternate implementations, whereas
I wanted the clear separation of alternate architectures provided by a
configuration.
Regards
Gary

 

[KJ]

"Gary Pace" <abc@def.com> wrote in message
news:u_ydnSAkzOuuU8rUnZ2dnUVZ_jSdnZ2d@giganews.com...

"Thomas Stanka" <usenet_nospam_valid@stanka-web.de> wrote in message
news:086bc067-bf6d-42e6-bcbf-630ac22a3296@r15g2000prd.googlegroups.com...
Hi,

On 26 Dez., 23:55, "Gary Pace" <a...@def.com> wrote:
would like to make this decision within "component.vhd" based upon the
generics found during elaboration, so that higher level entities that
use
the function are not involved in the decision.

Is this possible ?

I would use configurations for this task. The decision is taken in the
configuration of the next higher hierachy than the entity that has
several architectures.

bye Thomas

Thomas :
Thanks.
I considered this, but it was rather the opposite of the encapsulation I
was trying to achieve.
The engineer working on the higher level entity would need to know the
details of the implementation of the component they were using in order to
make the right choice of architecture.
I wanted the component itself to instantiate the optimal structure based
on the parameters.
I have done it with IF-THEN-ELSE in the process(es) of the component
architecture, but this does "mix up" the alternate implementations,
whereas I wanted the clear separation of alternate architectures provided
by a configuration.

So what was wrong with Charles' suggestion which does what it seems like
what you had asked? Your reply to him said you did it similar to the way he
suggested (but not really since you instead copied the code from the old
architectures into a brand new one and added code to select between them)
but now in your reply here to Thomas you say you want a clear separation of
alternate architectures...which is what Charles' suggested you do.

Personally what I do when I have one architecture already done and working
and 'things change' so I want a different architecture and a way to select
between them via generics I follow the following basic flow:
1. Create the new architecture that implements things the new way, so now I
have basically 'arch1' and 'arch2'.
2. Create another wrapper architecture that instantiates all of the
individual ones (i.e. arch1 and arch2) and selects the appropriate set of
output signals to use based on the generic.

Some of the details may be different from how Charles' suggested, but the
bottom line is they are basically the exact same approach and it both
preserves and reuses the existing architecture as well as allowing for
selection based on generics. By copying code as you did, you're risking
spreading of latent bugs that may be still lurking in the original
architecture that you just haven't run across yet.

Kevin Jennings

 

[Gary Pace]

So what was wrong with Charles' suggestion which does what it seems like
what you had asked? Your reply to him said you did it similar to the way
he suggested (but not really since you instead copied the code from the
old architectures into a brand new one and added code to select between
them) but now in your reply here to Thomas you say you want a clear
separation of alternate architectures...which is what Charles' suggested
you do.

Personally what I do when I have one architecture already done and working
and 'things change' so I want a different architecture and a way to select
between them via generics I follow the following basic flow:
1. Create the new architecture that implements things the new way, so now
I have basically 'arch1' and 'arch2'.
2. Create another wrapper architecture that instantiates all of the
individual ones (i.e. arch1 and arch2) and selects the appropriate set of
output signals to use based on the generic.

Some of the details may be different from how Charles' suggested, but the
bottom line is they are basically the exact same approach and it both
preserves and reuses the existing architecture as well as allowing for
selection based on generics. By copying code as you did, you're risking
spreading of latent bugs that may be still lurking in the original
architecture that you just haven't run across yet.

Kevin Jennings

Kevin :
The problem with Charles' suggestion was that I didn't understand it - I
first saw VHDL about two weeks ago and this middle aged dog is beginning to
struggle with new tricks.
I was unhappy with my solution for exactly the reason you alluded to - I was
mixing solutions in a way that was asking for future problems.
Your approach is exactly what I was looking for.
One more question : does the IF-GENERATE construct allow for an ELSE clause
so I can instantiate a dumb-but-always-works option ?
This whole move to VHDL is proving quite challenging - I have created
numerous embedded software systems, have designed dozens of PCB's with DSP,
PowerPC, microcontroller systems and designed lots of FPGA solutions in
schematic. This led me to have distinct hardware and software heads
(structure or algorithm if you like). I had assumed that HDL would be
somewhere in between - but I'm learning that it's a whole new way of
thinking about functionality.
Expect to see many more "just isn't getting it" posts here in the next
months
Thanks
Gary

 

[Brian Drummond]

On Sun, 28 Dec 2008 23:14:54 -0600, "Gary Pace" <abc@def.com> wrote:

Kevin :
The problem with Charles' suggestion was that I didn't understand it - I
first saw VHDL about two weeks ago and this middle aged dog is beginning to
struggle with new tricks.
I was unhappy with my solution for exactly the reason you alluded to - I was
mixing solutions in a way that was asking for future problems.
Your approach is exactly what I was looking for.
One more question : does the IF-GENERATE construct allow for an ELSE clause
so I can instantiate a dumb-but-always-works option ?

Unfortunately not.

Best way is to wrap the test in a function, e.g. "condition" and use two
Generate statements, "if condition generate" and "if not condition
generate"...

This led me to have distinct hardware and software heads
(structure or algorithm if you like). I had assumed that HDL would be
somewhere in between - but I'm learning that it's a whole new way of
thinking about functionality.

It'll only resemble software if you're used to writing parallel
processing software; e.g. in Occam, or using Ada tasks, and languages
with rigorous type systems and scope rule. All of which is looking more
and more like a lost art.

Suggesting a recent graduate declare a function local to another one, he
thought I meant to expand the function body inside the other function;
he had completed a CS degree but never even seen a local function! They
simply don't exist in the languages taught today.

He took an elective VHDL course but that apparently assumed knowledge of
programming language basics which are no longer mentioned.

Sigh.

- Brian

 

[Andy]

I handle it similarly to KJ, except I use if-generate statements to
instantiate only the entity/architecture I want based on generics.

At the point when I decide there needs to be additional architectures,
I rename the original (assuming it will be one of the choices), and re-
write the original architecture to if-generate the choice
architectures. That way, calling code that instantiated the original
entity/architecture does not have to change.

In other words, if I started out with one architecture named "rtl",
and decided I also needed an "rtl_a", I would rename "rtl" to "rtl_b",
then re-write "rtl" to conditionally generate instantiation(s) of
"rtl_a" and "rtl_b". So code that already instantiates "my_entity
(rtl)" will still work fine, and even take advantage of the choice
automatically (assuming there was enough information in the original
instantiation to drive the choice; i.e. an existing generic, the width
of signals tied to unconstrained ports, etc.)

I rarely use configurations any more, since that ends up driving the
creation of so many component declarations, not to mention the
configuration code itself. If I need "compile-time" configurability, I
drive it with top level generics set on the command line. Those
generics get passed down and drive if-generate structures at the
appropriate places.

Andy