Re: in the absence of a pre-processor...

Discussion in 'VHDL' started by Jonathan Bromley, Aug 12, 2010.

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

    >I have a bunch of constants that can change from build to build


    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
     
    Jonathan Bromley, Aug 12, 2010
    #1
    1. Advertising

  2. On 8/12/10 6:14 AM, Jonathan Bromley wrote:
    > - 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.


    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;
     
    Jeff Cunningham, Aug 12, 2010
    #2
    1. Advertising

  3. Jonathan Bromley

    Andy Guest

    On Aug 12, 5:14 am, Jonathan Bromley <>
    wrote:
    > On Thu, 12 Aug 2010 12:51:34 +1000, Mark McDougall wrote:
    > >I have a bunch of constants that can change from build to build

    >
    > 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


    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
     
    Andy, Aug 12, 2010
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christopher Benson-Manica

    system() in the absence of a command processor

    Christopher Benson-Manica, Sep 19, 2006, in forum: C Programming
    Replies:
    9
    Views:
    283
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=
    Oct 3, 2006
  2. brahatha
    Replies:
    1
    Views:
    665
  3. Mike Treseler
    Replies:
    0
    Views:
    508
    Mike Treseler
    Aug 12, 2010
  4. KJ
    Replies:
    2
    Views:
    559
  5. Thomas Stanka
    Replies:
    1
    Views:
    608
    Thomas Stanka
    Aug 17, 2010
Loading...

Share This Page