in the absence of a pre-processor...

Thu Aug 12, 2010 3:51 am   

Hi gurus,

I have a bunch of constants that can change from build to build, depending
on what I'm targeting. Right now I'm simply commenting/out a whole set of
lines each time. eg:

--constant A : std_logic_vector(3 downto 0) := X"0";
--constant B : std_logic_vector(3 downto 0) := X"1";
--constant C : std_logic_vector(3 downto 0) := X"2";
--constant D : std_logic_vector(3 downto 0) := X"3";

constant A : std_logic_vector(3 downto 0) := X"3";
constant B : std_logic_vector(3 downto 0) := X"4";
constant C : std_logic_vector(3 downto 0) := X"5";
constant D : std_logic_vector(3 downto 0) := X"6";

Short of diving into configurations etc, does anyone have a handy trick
they use in these sorts of situations? The idea is to be able to
change/comment only 1/2 lines to achieve the above...

I can think of some rather horrible & convoluted ways that might work
with, say, std_logic_vector using and/or, but it's not pretty...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Aug 12, 2010 5:45 am   

On 8/11/2010 7:51 PM, Mark McDougall wrote:


I would declare an array: bunch_o_constants_t
That might give me only one line to comment.

If the values are computable from a parameter,
as in the example, I might use a function on the right side.

-- Mike Treseler

Thu Aug 12, 2010 8:18 am   

On Aug 11, 10:51 pm, Mark McDougall <ma...@vl.com.au> wrote:

Define a type which contains the set of things that you'll be
selecting from (i.e. A, B, C, D each of type std_logic_vector)

type t_abcd is record
a: std_logic_vector(3 downto 0);
b: std_logic_vector(3 downto 0);
...
end record;

Next define a type that is an array of that type
type arr_t_abcd is array (natural range<>) of t_abcd;

And now a constant array of the universe of those choices...
constant All_abcds: arr_t_abcd x"0", x"1"..., x"3"),
(x"3", x"4"..., x"6");

Now have either a generic input to the entity or a constant in the
architecture to select which set you want to use for a particular
build and define the A, B, C, D constants like this...
constant A: std_logic_vector(3 downto 0) := All_abcds(Sel).A;
constant B: std_logic_vector(3 downto 0) := All_abcds(Sel).B;
....

None of your code that right now refers to A, B, C, D needs to change
since you still eventually end up with those constants defined. The
top level generic can be selected at build time, or simply defined as
a constant in the architecture. Either way you only change one thing,
either the top level generic or the selection constant in the code.

Kevin Jennings

Thu Aug 12, 2010 11:14 am   

On Thu, 12 Aug 2010 12:51:34 +1000, Mark McDougall wrote:


Great advice from Mike and KJ.

A couple of other thoughts:

- Kevin's "universe of possible sets of values" could
possibly be a moving target as you port the design
to a big variety of platforms. Using a function to
construct the record, and passing some interesting
selector values to that function, may be a cleaner
approach if you can compute your constants based on
the value of a few vital statistics of the platform.

- If the set of constants truly is a horrible
platform-specific mishmash of values, it may be
cleaner *not* to maintain one big collection of
them, but rather to create a collection of package
files each of which defines the same-named package,
which contains all your constants. Each file
is then the description of a single platform,
and by compiling the correct file you get the
correct values in your platform descriptor package.
Now you can adjust the platform-specific build
simply by writing a new package file, and
tweaking your build script to use that file.

- Oftentimes it is quite sucky to be forced to
use std_logic_vector values for these constants.
Don't be ashamed of using integer constants in
the package, and then constructing s-l-v
constants from them using a function in the
architecture. I've often done this when
describing, for example, the layout of a bunch
of registers in an address space - it's far
easier to describe the addresses using integers,
and then fabricate appropriate vector values
from those integers for use in the decoder or
whatever logic.

--
Jonathan Bromley

Thu Aug 12, 2010 11:36 am   

On Wed, 11 Aug 2010 21:45:41 -0700, Mike Treseler <mtreseler_at_gmail.com> wrote:


I've used this for an array of constants defining LUT widths and internal word
widths. The index came from an integer subrange denoting the precision I wanted
to achieve.


The same index controlled functions to truncate the LUT entries to the correct
size to initialise the LUTs themselves.

One design created a family of function generators with tunable precision and
resource usage.

I should have made it a generic, but in this instance I didn't bother.

- Brian

Thu Aug 12, 2010 5:06 pm   

On 8/12/10 6:14 AM, Jonathan Bromley wrote:

I've done a similar thing but using a single package file with deferred
constant types. This works great with modelsim and synplicity but not
XST. Funny thing is, it used to work with XST then back around version 7
or 8 of the tools it suddenly broke. When I opened a webcase on it I was
told it was my fault for using "illegal syntax".
-Jeff


library ieee;
use ieee.std_logic_1164.all;

package datapathSetup is

-- enumerate the different datapath configurations.
type t_datapath_configuration is (
toolkit,
gen3
);

-- select a datapath configuration:
constant datapath_configuration: t_datapath_configuration := toolkit;

-- constants I want to be a function of datapath configuration
constant WORDS_PER_SORT: integer;
constant SORTS_PER_RASTER: integer;
constant BURSTS_PER_MODULE: integer;

end datapathSetup;

package body datapathSetup is

function get_words_per_sort (mode: t_datapath_configuration) return
integer is
begin
case mode is
when toolkit=> return 16;
when gen3=> return 19;
end case;
end get_words_per_sort;
constant WORDS_PER_SORT: integer :=
get_words_per_sort(datapath_configuration);

function get_sorts_per_raster (mode: t_datapath_configuration) return
integer is
begin
case mode is
when toolkit=> return 1;
when gen3=> return 1;
end case;
end get_sorts_per_raster;
constant SORTS_PER_RASTER: integer :=
get_sorts_per_raster(datapath_configuration);

function get_bursts_per_module (mode: t_datapath_configuration)
return integer is
begin
case mode is
when toolkit=> return 2;
when gen3=> return 3;
end case;
end get_bursts_per_module;
constant BURSTS_PER_MODULE: integer :=
get_bursts_per_module(datapath_configuration);

end datapathSetup;

Thu Aug 12, 2010 5:36 pm   

Mike Treseler wrote:


I should've used a better example. There's a mixture of types involved.


Nope, not in this case.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Aug 12, 2010 5:44 pm   

KJ wrote:


This I like, except for one thing. It groups values for each constant
together in the source, which wouldn't be a problem except I need to be
able to see the relationship between some of the constants for a given
"configuration". In the example above, you can easily see 0 goes with 3, 1
goes with 4 etc, but when you have different types and longer names, it
makes it quite difficult... :(

eg.

constant All_acbds: arr_t_abcd :=
( some_value_for_type_a, another_value_for_type_a,
yet_another_value_for_type_a...and_finally_another_for_type_a),
( true, true, false...true),
( a_value_of_c, another_value_of_c, yet_another_value_of_c...
and_a_last_value_for_c_which_has_a_long_name),

etc...

But food for thought... thanks!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Aug 12, 2010 5:50 pm   

Jonathan Bromley wrote:


Good idea for some applications, but see my comments in response to
Kevin's - and this is one step worse again. :(


Heh, this is exactly what I do *as well*, one step up the ladder of
'abstraction'. The constants I have are a mish-mash, but even within the
same project there are several build options. But I see where you're
coming from.


Don't worry, I've never been afraid to use integers or other non-slv
types. I frequently use integer subtypes for counters, for example.

Thanks guys for your tips. Much appreciated!

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Aug 12, 2010 5:55 pm   

Mark McDougall wrote:


FWIW I suspect my situation is a little different than most!?! I have a
collection of projects that all build on a cross-section of hardware
targets. And each project itself may have different build options for each
hardware target. So I'm trying to manage 'p' projects on 't' targets with
'b' build options... pxtxb=arrghh!!! ;)

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Aug 12, 2010 5:57 pm   

Thomas Stanka wrote:


Generics won't solve my problem. Just move it.

Configurations - I've never been able to get them to solve this problem.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Thu Aug 12, 2010 7:45 pm   

On Aug 12, 5:14 am, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

Integers and other types work especially well to provide some built-in
sanity checking, such as limiting a constant's value to between 1 and
100 (decimal). Or a color to be red, blue, green, etc. Sure these
checks can be handled with extra functions called by extra assertion
statements, but you get it for free by constraining the type/subtype
etc. SLV works well when you are trying to describe a set of digital
electronic signals, not so well when you want to describe information
(e.g. add some context to the signals).

Andy

Thu Aug 12, 2010 7:53 pm   

On 12 Aug., 04:51, Mark McDougall <ma...@vl.com.au> wrote:

Is there a reason why you don't want to solve this with generics or
configurations?
I've seen that Synplicty even allows you to pass generics in the
synthesis you need no top level wrapper, that you would use otherwise.

bye Thomas

Thu Aug 12, 2010 8:51 pm   

On Fri, 13 Aug 2010 02:44:52 +1000, Mark McDougall wrote:


I'm not sure you and KJ are on the same page here.

Kevin's idea (as I read it) is to construct a type that is
a record, collecting all the assorted constants relating to
a single build. And then an array of those records, one
array element for each possible build.

So each record, written as an aggregate expression,
clearly shows "what goes with what". I don't really
understand why that presents the problem I think you're
describing. But I could have missed the point - it
wouldn't be the first time :-)

Regardless of the details (and point taken about your
rather large configuration space) it should be possible
to build a data structure that clearly captures the
set of constants that define a build. Once that's done,
you can create an array of those things and choose
one of them by a suitable index, or write a function
that constructs such an object from argument values
that specify the build's properties.
--
Jonathan Bromley

Thu Aug 12, 2010 8:59 pm   

On 8/11/2010 7:51 PM, Mark McDougall wrote:

Put each set of constants in their own file, give them all the same
package name, and make your Makefile responsible for picking which of
the files to actually include in the build?

--
Rob Gaddi, Highland Technology
Email address is currently out of order