configurable VHDL configuration

Altera_Forum · ‎08-14-2012

Hi all,

My current design targets two vendors, Altera and ...:evil:

Vendor specific parts have been seperated in different architectures.

By configuration I can choose which architectures to use.

This works so far, but there are a lot of statements like:

use entity work.modul_name1(ARCH_ALTERA);

And I have to replace all architecure names.

Great would be something like:

constant VENDOR : string := "ARCH_ALTERA" ;

use entity work.modul_name1(VENDOR);

To get a main switch. But the architecture name must be static.

Any ideas?

Altera_Forum · ‎08-14-2012

use generates to act on the constant and select the architecture at instantiation using direct instantitation. No Components or configurations needed


Altera_gen : if VENDOR = "ARCH_ALTERA" generate
  mod_inst : entity work.modul_name1(arch_altera)
  generic map (
  .....
end generate altera_gen;
other_gen : if VENDOR = "SOMEONE_ELSE" generate
   .....
--etc

if you use VHDL 2008, you can use if/elsif/else generate.

Altera_Forum · ‎08-14-2012

Here's some code snippets using generate statements and generics.

You can also use VHDL configurations to get similar results, i.e., define a generic counter interface and then use a configuration to define the vendor specific implementation (mapping between a real component and the interface).

See this thread for vhdl_configurations.zip

http://www.alteraforum.com/forum/showthread.php?t=30414&page=2

That should give you some ideas.

Cheers,

Dave

Altera_Forum · ‎08-15-2012

Thanks for these very high speed responses.

The design contains many generic parameterizable modules. Nearly all parameterization is done at configuration level. This is clearly arranged, but means that I can't follow the generate suggestion without moving all generic mapping from configuration to instantiation. Otherwise I would get configuration statements for non-existing modules (excluded by generate statement). Except I could exclude the not used configuration statement by generate also. I'm not sure if this is possible.

At the moment I have two different configuration files, one for each vendor, which isn't really fail-safe.

Altera_Forum · ‎08-15-2012

--- Quote Start ---

Thanks for these very high speed responses.

The design contains many generic parameterizable modules. Nearly all parameterization is done at configuration level. This is clearly arranged, but means that I can't follow the generate suggestion without moving all generic mapping from configuration to instantiation. Otherwise I would get configuration statements for non-existing modules (excluded by generate statement). Except I could exclude the not used configuration statement by generate also. I'm not sure if this is possible.

At the moment I have two different configuration files, one for each vendor, which isn't really fail-safe.

--- Quote End ---

I would recommend trying a few ideas in Modelsim.

I'm pretty sure that so long as you have a component definition, you do not need the backing entity definition *unless* your design actually uses that code path, eg., you can simulate the Altera design, without compiling the Xilinx component entities, since they would not be used in that design.

Once you get stuck, then post the code, as is much easier to discuss code.

Cheers,

Dave

Altera_Forum · ‎08-16-2012

ok, here is some example code:

entity top is
port (...);
end top;
component mod1_name
end component;
...
architecture arch_top of top is
    inst1: mod1_name
    port map (...);
    ...
end arch_top;
-----------------------------------------------------------
entity mod1_name is
generic (...);
port (...);
end mod1_name;
architecture ARCH_ALTERA of mod1_name is
begin
...
end ARCH_ALTERA;
architecture ARCH_VENDOR2 of mod1_name is
begin
...
end ARCH_VENDOR2;
-----------------------------------------------------------
configuration cfg1_top is
    for arch_top
        for inst1: mod1_name
            use entity work.mod1_name (ARCH_ALTERA)
            generic map (...);
        end for;
    end for;
end configuration cfg1_top;
-----------------------------------------------------------
-- and with generate suggestion
-----------------------------------------------------------
entity top is
port (...);
end top;
...
architecture arch_top of top is
    G1: if VENDOR = "ARCH_ALTERA" generate
        inst1: entity work.mod1_name(ARCH_ALTERA)
        port map (...);
    end generate G1;
    G2: if VENDOR = "ARCH_VENDOR2" generate
        inst1: entity work.mod1_name(ARCH_VENDOR2)
        port map (...);
    end generate G2;
    ...
end arch_top;
-- What to do, if generic mapping should remain in configuration?
configuration cfg1_top is
    for arch_top
        for inst1: mod1_name
            use entity work.mod1_name (ARCH_ALTERA)
            generic map (...);
        end for;
        for inst1: mod1_name
            use entity work.mod1_name (ARCH_VENDOR2)
            generic map (...);
        end for;
    end for;
end configuration cfg1_top;
-- doesn't work, but maybe:
GC1: if VENDOR = "ARCH_ALTERA" generate
    configuration cfg_mod1_name is
        for ARCH_ALTERA
        end for;
    end configuration cfg_mod1_name;
end generate GC1;
GC2: if VENDOR = "ARCH_VENDOR2" generate
    configuration cfg_mod1_name is
        for ARCH_VENDOR2
        end for;
    end configuration cfg_mod1_name;
end generate GC2;
configuration cfg1_top is
    for arch_top
        for inst1: mod1_name
            use configuration work.cfg_mod1_name
            generic map (...) ;
        end for;
    end for;
end configuration cfg1_top;
-- but it would take me days for a complete redesign

So, I am still looking for an easy way to switch between vendors at configuration level.

Altera_Forum · ‎08-16-2012

According to my Doulos quick reference (which is pretty comprehensive), it makes no mention of the option for conditional configuration. In my head, the configuration is meant to be fixed, so you would have 2 configs, one for Altera and one for VENDOR2, and you just load the appropriate one when you include the design files.

I know the reference is about 10 yrs old, and some of it may be a little out of date, but these is what it says under under the "synthesis" heading for configurations:

"although configurations are relevant and useful for selecting which entities and architectures make up the design hierarchy, many synthesis tools do not support them. instead, write a script to synthesisze the correct architectures"

And in the configutation Specification section:

"configuration specifications are inflexible, because changing the configuration requires editing the architecture containing the configuration. it is usually better to use separate configuration declarations.".

Configurations are a little used part of VHDL. And now with direct instantiation (hardly new, it came in in 1993), nearly obsolete.

Unless you are using a 3rd party synthesis tool, why do you need a reconfigurable configuration?

Altera_Forum · ‎08-16-2012

Another thought - are these things that are changing fairly generic, like RAMS? why not make an entity called "generic_ram" and so you just instantiate it that all over the code, and the only place the architectural changes have to occur are inside the "generic_ram" entity.

ie. try and hide the changes as much as possible.

Altera_Forum · ‎08-16-2012

Hi Tricky,

The simulator agrees with you, conditional configuration is not possible.

Two different configurations is what I have now. And I've been quite comfortable with that, until I changed one without changing the other, leading to a lot of waisted time for finding the difference and breeding the desire for one configuration with a main switch.

For a new design I would trace the multi-vendor approach with the use of generates and instantiate the generics by constants defined in a global package.

Altera_Forum · ‎08-16-2012

--- Quote Start ---

Two different configurations is what I have now. And I've been quite comfortable with that, until I changed one without changing the other, leading to a lot of waisted time for finding the difference and breeding the desire for one configuration with a main switch.

--- Quote End ---

If you create a Modelsim testbench for each vendor design, and run every testbench on every component during testing, then its much easier to catch these types of "I forgot ..." errors.

Its possible to setup a makefile so that you can run a "make check" just like you would during software development.

Cheers,

Dave

Altera_Forum · ‎08-17-2012

Hi Dave,

Unfortunately my testbenches didn't cover the misadjustment of a generic port.

I'm not sure if that's what you've meant, but I've just added some statements to my simulation script that simply check the values of all generic ports.

This is very easy and an improvement of my design process.

It has been nice discussing with you.

Altera_Forum · ‎08-17-2012

You can check generic values with asserts inside VHDL too. This can stop or simulation and even synthesis if values are wrong.

Altera_Forum · ‎08-17-2012

--- Quote Start ---

Unfortunately my testbenches didn't cover the misadjustment of a generic port.

I'm not sure if that's what you've meant, but I've just added some statements to my simulation script that simply check the values of all generic ports.

This is very easy and an improvement of my design process.

It has been nice discussing with you.

--- Quote End ---

I use both Tcl and VHDL checks for the testbenches, eg., all of my simulation scripts create Tcl procedures with the same name as each testbench and arguments that set the values of generics, if some of the generics are related, eg., maximum address and address width, then the Tcl checks those related generics (or calculates the derived generics). The VHDL code also has assertions for valid values.

Your testbenches should ideally test a number of generic values to ensure that the design functionality is correct. Over time, you begin to appreciate having a testbench for each component that you reuse on a regular basis, as it is very useful in detecting bugs (or detecting them early!).

Cheers,

Dave

Altera_Forum · ‎10-01-2013

Too bad there doesn't seem to be a way to use generics for selecting the architecture. I also have an entity with two architectures. Depending on the generic one of the architectures should be used: My current code looks like this:

gen_arch_a: IF G_USE_A = true GENERATE
  inst_my_comp_a: ENTITY work.my_ent(arch_a)
  port map
  (
    i_sig => sig_raw,
    o_sig => sig_filtered
  )
END GENERATE;
gen_arch_a: IF G_USE_A = false GENERATE
  inst_my_comp_b: ENTITY work.my_ent(arch_b)
  port map
  (
    i_sig => sig_raw,
    o_sig => sig_filtered
  )
END GENERATE;

Now if I modify sig_raw and assign it to a new signal:

sig_mod <= sig_raw....;

it's easy to overlook to replace both of the signals in the generate statements:

gen_arch_a: IF G_USE_A = true GENERATE
  inst_my_comp_a: ENTITY work.my_ent(arch_a)
  port map
  (
    i_sig => sig_mod, -- <- updated signal name
    o_sig => sig_filtered
  )
END GENERATE;
gen_arch_a: IF G_USE_A = false GENERATE
  inst_my_comp_b: ENTITY work.my_ent(arch_b)
  port map
  (
    i_sig => sig_raw, -- <- forgot to update signal name in this case
    o_sig => sig_filtered
  )
END GENERATE;

Something like this:


...
generic
(
  G_USE_ARCH : string := "arch_b"
);
...
inst_my_comp_b: ENTITY work.my_ent(G_USE_ARCH)

as proposed in the first post would solve this problem.

Altera_Forum · ‎10-01-2013

Look at the link to the VHDL configurations thread that I posted earlier in this thread.

Cheers,

Dave

Altera_Forum · ‎10-07-2013

My knowledge of configurations is limited but I think they are not best choice in this case for me. If I use a generic one can decide during instantiation which architecture should be used (direct instantiation like shown above). If I used configurations wouldn't one have to include the correction configuration file to project? So I would need two write different configuration files for different architectures. If that's so I think I'll stick to the if-generate statements in this case.

Regards

Martin

Altera_Forum · ‎10-07-2013

Hi Martin,

--- Quote Start ---

My knowledge of configurations is limited but I think they are not best choice in this case for me. If I use a generic one can decide during instantiation which architecture should be used (direct instantiation like shown above). If I used configurations wouldn't one have to include the correction configuration file to project? So I would need two write different configuration files for different architectures. If that's so I think I'll stick to the if-generate statements in this case.

--- Quote End ---

I think you're right.

Keep in mind that if you are driving your synthesis and simulation via a Tcl script that you could always include the appropriate file, eg., have a file with the my_ent entity definition, and two separate files with the two different architectures. Based on a Tcl variable, you can include the desired architecture.

Cheers,

Dave

Altera_Forum · ‎10-07-2013

Thanks for your advice! Glad you understood what I was writing about. Just saw that I made quite a few typos in my previous post...

Altera_Forum · ‎10-07-2013

--- Quote Start ---

Thanks for your advice! Glad you understood what I was writing about.

--- Quote End ---

You're welcome. I find that it sometimes helps to look at alternative solutions ... sometimes it gives you an idea for an even better solution.

Cheers,

Dave