How do you handle build variants in VHDL?

I'm doing a project in Lattice ISPLever ( which bears uncanny similarities to Xilinx ISE), which may
end up having several product variants, and was wondering how people typically handle compile-time
build variants for different product functionalities?

The sort of thing that if it was C software, you'd do it easily with #includes, #defines and
#ifdefs, but for reasons I can't understand, VHDL doesn't have anything like these simple
preprocessor functions. 
Although HDLs are very different from programming languages, a preprocessor would be equally useful
& it seems ridiculous that nobody thought to include one in the standard.

Is there a simple way to 'add' a C style preprocessor to the build process?

Hi!

What I usually do is to write a package that I include with "use" in all 
my VHDL code files. The package contains constants (for instance natural 
numbers) that determine the functionality of the model. In the VHDL 
model itself you then have to write something like

label_1: if USE_THIS_FEATURE = 0 generate

end generate;

label_2: if USE_THIS_FEATURE = 1 generate

end generate;

and so on. Synthesis and simulation will only include the statements you 
want.

Matthias




Mike Harrison schrieb:
> I'm doing a project in Lattice ISPLever ( which bears uncanny similarities to Xilinx ISE), which may
> end up having several product variants, and was wondering how people typically handle compile-time
> build variants for different product functionalities?
> 
> The sort of thing that if it was C software, you'd do it easily with #includes, #defines and
> #ifdefs, but for reasons I can't understand, VHDL doesn't have anything like these simple
> preprocessor functions. 
> Although HDLs are very different from programming languages, a preprocessor would be equally useful
> & it seems ridiculous that nobody thought to include one in the standard.
> 
> Is there a simple way to 'add' a C style preprocessor to the build process?

"Mike Harrison" <mike@whitewing.co.uk> wrote in message 
news:2lb865tncrvum6jn7uu24ohop7ruatvaiq@4ax.com...
> I'm doing a project in Lattice ISPLever ( which bears uncanny similarities 
> to Xilinx ISE), which may
> end up having several product variants, and was wondering how people 
> typically handle compile-time
> build variants for different product functionalities?
>
> The sort of thing that if it was C software, you'd do it easily with 
> #includes, #defines and
> #ifdefs, but for reasons I can't understand, VHDL doesn't have anything 
> like these simple
> preprocessor functions.
> Although HDLs are very different from programming languages, a 
> preprocessor would be equally useful
> & it seems ridiculous that nobody thought to include one in the standard.
>
> Is there a simple way to 'add' a C style preprocessor to the build 
> process?

Hi Mike,

I think VHDL does have these things, and they're called generics, used along 
with generate, but I wouldn't claim any expertise in VHDL so you could try 
asking over on comp.lang.vhdl . I'm sure Jonathan, Mike et al will give you 
good advice.

HTH., Syms. 

On Jul 20, 4:51=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
> I'm doing a project in Lattice ISPLever ( which bears uncanny similaritie=
s to Xilinx ISE), which may
> end up having several product variants, and was wondering how people typi=
cally handle compile-time
> build variants for different product functionalities?
>

With generics and constants in packages.

> The sort of thing that if it was C software, you'd do it easily with #inc=
ludes, #defines and
> #ifdefs, but for reasons I can't understand, VHDL doesn't have anything l=
ike these simple
> preprocessor functions.

Because they're not needed.

> Although HDLs are very different from programming languages, a preprocess=
or would be equally useful
> & it seems ridiculous that nobody thought to include one in the standard.
>

Design parameters are handled quite well without any pre-processor.

> Is there a simple way to 'add' a C style preprocessor to the build proces=
s?

I'm sure there is...but try using the facilities of the language first
and then come back with examples of something that can be done only
with a pre-processor

KJ

Mike Harrison schrieb:
> I'm doing a project in Lattice ISPLever ( which bears uncanny similarities to Xilinx ISE), which may
> end up having several product variants, and was wondering how people typically handle compile-time
> build variants for different product functionalities?
> 

Hi Mike,

I have had to do this in a number of situations. Typical case: if I do a
PCIe design for a customer, I evaluate on the the Lattice PCIe Demo
board (ECP2M/50) but the customer often uses a different device
(ECP2M/20 or ECP2M/35)

I haven't found a way of assigning top-level generics at synthesis time
in ispLever (I'm not saying there isn't a way). So I do all the
configuration one level below. Each 'variant' has it's own top-level
entity and architecture, everything else is common. I generate the
project files (*.syn) under Linux (java script) so it's very easy to
keep them all in sync if I change the structure a bit during
development. Essentially, the *.syn files differ only in the package
chosen and in the files read in as top-level entity/architecture. I put
the pinning as 'LOC' attributes in the top-level entity btw.

The top-level entity/architecture has all busses split into single
signals and takes care of any polarity inversion for active-low signals,
enables for bidirectionals etc. The only module instanced in the
top-level architecture is my 'core' unit. It is essentially the same as
the top-level unit except:

- input / output polarity is always active high (makes viewing of
simulation traces easier - if it's true it's a one)

- no bidirectional ports

- busses are declared as std_logic_vector, occasionally as records

- contains generic ports passed into the design below. I use these to
configure things like FIFO sizes, no. of DMA channels, whatever

If needed, I have a separate constraint file for each variant. Each
variant has it's own script sub-directory (if there are differences). To
synthesise, I just copy the project (*.syn), constaint (*.lpf), ispVM
(*.xcf) and possibly environment (*.sty) into my ispLever work directory
and let it run. Works a treat.

Mike Harrison wrote:

> The sort of thing that if it was C software, you'd do it easily with #includes, #defines and
> #ifdefs, but for reasons I can't understand, VHDL doesn't have anything like these simple
> preprocessor functions. 

Plain vhdl constants work fine for this.
I put them in a package.

  -- Mike Treseler

On Jul 20, 10:19=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
> Mike Harrison wrote:
> > The sort of thing that if it was C software, you'd do it easily with #i=
ncludes, #defines and
> > #ifdefs, but for reasons I can't understand, VHDL doesn't have anything=
 like these simple
> > preprocessor functions.
>
> Plain vhdl constants work fine for this.
> I put them in a package.
>
> =A0 -- Mike Treseler

I combine a package and generics. Define a record type for the
generics I will need in a package. Every entity has one generic of
that record type. If I need to add a generic at the top, that only
gets used down deep in the hierarchy, I only have to add it to the
record, define it at the top, and extract it down where it is needed.
No additional plumbing modifications are necessary.

The package of constants works almost as well, except the only way to
change the value(s) is to edit (or swap) the package file. Generics
can be changed by the synthesis or simulation tool. Using a record
simplifies the generic "plumbing" almost as well as a package of
constants, while keeping the tool-based flexibility of the generics.
Depending on the complexity of your project, either a record of
generics or a package of constants may work just as well, and be
simpler to implement.

Andy

Symon wrote:
>> The sort of thing that if it was C software, you'd do it easily with 
>> #includes, #defines and
>> #ifdefs, but for reasons I can't understand, VHDL doesn't have anything 
>> like these simple
>> preprocessor functions.
>> Although HDLs are very different from programming languages, a 
>> preprocessor would be equally useful
>> & it seems ridiculous that nobody thought to include one in the standard.
>>

A number of people explained how to use the VHDL's native constructs.

>> Is there a simple way to 'add' a C style preprocessor to the build 
>> process?
> 
Yes. Use a "C" pre-processor. I didn't try it myself in part because
I don't use VHDL and Verilog has "`include", "`define", etc.
A lot of people use cpp to pre-process for example
assembly sources. Why not VHDL? It should handle the #includes, 
#defines, etc. and leave the rest intact.

-Alex.

On Jul 20, 10:38=A0am, Charles Gardiner <inva...@invalid.invalid> wrote:
> Mike Harrison schrieb:
>
> > I'm doing a project in Lattice ISPLever ( which bears uncanny similarit=
ies to Xilinx ISE), which may
> > end up having several product variants, and was wondering how people ty=
pically handle compile-time
> > build variants for different product functionalities?
>
> Hi Mike,
>
> I have had to do this in a number of situations. Typical case: if I do a
> PCIe design for a customer, I evaluate on the the Lattice PCIe Demo
> board (ECP2M/50) but the customer often uses a different device
> (ECP2M/20 or ECP2M/35)
>
> I haven't found a way of assigning top-level generics at synthesis time
> in ispLever (I'm not saying there isn't a way).

I have gotten that to work, but only with integers.  It definitely
does not work with enumerated and I don't recall if it will work with
SLV and I know I haven't tried that.  The nice thing about doing at
the top is that you don't need to edit any files if you are using
configuration control.


> So I do all the
> configuration one level below. Each 'variant' has it's own top-level
> entity and architecture, everything else is common. I generate the
> project files (*.syn) under Linux (java script) so it's very easy to
> keep them all in sync if I change the structure a bit during
> development. Essentially, the *.syn files differ only in the package
> chosen and in the files read in as top-level entity/architecture. I put
> the pinning as 'LOC' attributes in the top-level entity btw.
>
> The top-level entity/architecture has all busses split into single
> signals and takes care of any polarity inversion for active-low signals,
> enables for bidirectionals etc. The only module instanced in the
> top-level architecture is my 'core' unit. It is essentially the same as
> the top-level unit except:
>
> - input / output polarity is always active high (makes viewing of
> simulation traces easier - if it's true it's a one)
>
> - no bidirectional ports
>
> - busses are declared as std_logic_vector, occasionally as records
>
> - contains generic ports passed into the design below. I use these to
> configure things like FIFO sizes, no. of DMA channels, whatever
>
> If needed, I have a separate constraint file for each variant. Each
> variant has it's own script sub-directory (if there are differences). To
> synthesise, I just copy the project (*.syn), constaint (*.lpf), ispVM
> (*.xcf) and possibly environment (*.sty) into my ispLever work directory
> and let it run. Works a treat.

On Jul 20, 4:51=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:
> I'm doing a project in Lattice ISPLever ( which bears uncanny similaritie=
s to Xilinx ISE), which may
> end up having several product variants, and was wondering how people typi=
cally handle compile-time
> build variants for different product functionalities?
>
> The sort of thing that if it was C software, you'd do it easily with #inc=
ludes, #defines and
> #ifdefs, but for reasons I can't understand, VHDL doesn't have anything l=
ike these simple
> preprocessor functions.
> Although HDLs are very different from programming languages, a preprocess=
or would be equally useful
> & it seems ridiculous that nobody thought to include one in the standard.
>
> Is there a simple way to 'add' a C style preprocessor to the build proces=
s?

You should also look up GENERATE.  That is how to do actual code
"defines".  GENERICS only get you parameters.

Rick