Records in vhdl

Discussion in 'VHDL' started by Dave, Nov 26, 2007.

  1. Dave

    Dave Guest

    I am currently using records to group signals together in some
    synthesizable VHDL code, for readability as much as anything else. The
    signals within the record are driven by one of three processes, with
    each element of the record having only one driver. This synthesized
    fine in ISE 9.2, but now that I want to simulate it, the ISE Lite
    simulator is complaining about a signal having multiple drivers. Does
    anyone know what the LRM says here? I know that the record is,
    overall, decared as a signal, and could be seen as having multiple
    drivers, but I'm finding this interpretation rather inconvenient right
    now... and am surprised that the synthesizer and simulator aren't on
    the same page with this.

    Example code:

    type recType is record
    a: std_logic;
    b: std_logic;
    end record;

    signal rec : recType;

    process(clk)
    if rising_edge(clk) then
    rec.a <= input_1;
    end if;
    end process;

    process(clk)
    if rising_edge(clk) then
    rec.b <= input_2;
    end if;
    end process;
     
    Dave, Nov 26, 2007
    #1
    1. Advertising

  2. Dave

    Andy Guest

    On Nov 26, 2:32 pm, Dave <> wrote:
    > I am currently using records to group signals together in some
    > synthesizable VHDL code, for readability as much as anything else. The
    > signals within the record are driven by one of three processes, with
    > each element of the record having only one driver. This synthesized
    > fine in ISE 9.2, but now that I want to simulate it, the ISE Lite
    > simulator is complaining about a signal having multiple drivers. Does
    > anyone know what the LRM says here? I know that the record is,
    > overall, decared as a signal, and could be seen as having multiple
    > drivers, but I'm finding this interpretation rather inconvenient right
    > now... and am surprised that the synthesizer and simulator aren't on
    > the same page with this.
    >
    > Example code:
    >
    > type recType is record
    > a: std_logic;
    > b: std_logic;
    > end record;
    >
    > signal rec : recType;
    >
    > process(clk)
    > if rising_edge(clk) then
    > rec.a <= input_1;
    > end if;
    > end process;
    >
    > process(clk)
    > if rising_edge(clk) then
    > rec.b <= input_2;
    > end if;
    > end process;


    Every process that drives any element of the record needs to drive
    EVERY element of the record. With resolved data types (SLV),
    "undriven" elements can be driven with 'Z'. I find it best to declare
    a constant of that type with the type declaration, and that constant
    defines every element to 'Z'. Assign the signal with the constant at
    the top of each process that drives any part of the signal, and you're
    done. Not very simulation efficient, but until we get user defined
    modes for record type ports, I don't know of another way, except to
    break out different parts of the record as separate signals/ports.
    Note that continuous assignments to 'Z' are optimized out in
    synthesis.

    Andy
     
    Andy, Nov 26, 2007
    #2
    1. Advertising

  3. Dave

    Dave Guest

    On Nov 26, 4:17 pm, Andy <> wrote:
    > On Nov 26, 2:32 pm, Dave <> wrote:
    >
    >
    >
    >
    >
    > > I am currently using records to group signals together in some
    > > synthesizable VHDL code, for readability as much as anything else. The
    > > signals within the record are driven by one of three processes, with
    > > each element of the record having only one driver. This synthesized
    > > fine in ISE 9.2, but now that I want to simulate it, the ISE Lite
    > > simulator is complaining about a signal having multiple drivers. Does
    > > anyone know what the LRM says here? I know that the record is,
    > > overall, decared as a signal, and could be seen as having multiple
    > > drivers, but I'm finding this interpretation rather inconvenient right
    > > now... and am surprised that the synthesizer and simulator aren't on
    > > the same page with this.

    >
    > > Example code:

    >
    > > type recType is record
    > > a: std_logic;
    > > b: std_logic;
    > > end record;

    >
    > > signal rec : recType;

    >
    > > process(clk)
    > > if rising_edge(clk) then
    > > rec.a <= input_1;
    > > end if;
    > > end process;

    >
    > > process(clk)
    > > if rising_edge(clk) then
    > > rec.b <= input_2;
    > > end if;
    > > end process;

    >
    > Every process that drives any element of the record needs to drive
    > EVERY element of the record. With resolved data types (SLV),
    > "undriven" elements can be driven with 'Z'. I find it best to declare
    > a constant of that type with the type declaration, and that constant
    > defines every element to 'Z'. Assign the signal with the constant at
    > the top of each process that drives any part of the signal, and you're
    > done. Not very simulation efficient, but until we get user defined
    > modes for record type ports, I don't know of another way, except to
    > break out different parts of the record as separate signals/ports.
    > Note that continuous assignments to 'Z' are optimized out in
    > synthesis.
    >
    > Andy- Hide quoted text -
    >
    > - Show quoted text -


    This makes sense. I left out the fact that some of the elements are of
    integer type, and this seems important because there's no resolution
    function for that type. If everything were based on std_logic, I think
    I'd be fine.
     
    Dave, Nov 26, 2007
    #3
  4. Dave

    Jim Lewis Guest

    Dave,
    > This makes sense. I left out the fact that some of the elements are of
    > integer type, and this seems important because there's no resolution
    > function for that type. If everything were based on std_logic, I think
    > I'd be fine.


    For integers, you can use something like the following. I have
    only used this for records in testbenches and not RTL code. I
    always thought this is a testbench only thing, but some of Andy's
    comments got me thinking. In my testbenches, I initialize all
    resolved integers to 0 at the point of signal declaration or on
    the port. Since synthesis mostly ignores initialization, it may
    squeek by, but I would caution you that even if it works on one
    synthesis tool, it may not work on others.

    Cheers,
    Jim
    SynthWorks VHDL Training


    package ResolutionPkg is

    type integer_array is array (natural range <>) of integer ;
    function summing ( s : integer_array ) return integer ;
    function resolved ( s : integer_array ) return integer ;
    subtype resolved_integer is resolved integer ;

    end ResolutionPkg ;

    package body ResolutionPkg is

    function resolved ( s : integer_array ) return integer is
    variable result : integer := 0 ;
    begin
    for i in s'RANGE loop
    if s(i) /= 0 then
    if result /= 0 then
    report "Multiple driving signals on integer" severity error ;
    end if ;
    result := s(i) ;
    end if ;
    end loop ;
    return result ;
    end resolved ;
    end ResolutionPkg ;
     
    Jim Lewis, Nov 26, 2007
    #4
  5. Dave

    Jim Lewis Guest

    P.S.
    In the previous post, delete the line:
    > function summing ( s : integer_array ) return integer ;


    I got caught extracting things from an existing file.
    "Summing" is another resolution function I have toyed around
    with, but would not recommend at all for your application.
     
    Jim Lewis, Nov 27, 2007
    #5
  6. On Mon, 26 Nov 2007 13:25:56 -0800 (PST), Dave <>
    wrote:

    >On Nov 26, 4:17 pm, Andy <> wrote:
    >> On Nov 26, 2:32 pm, Dave <> wrote:


    >> > I am currently using records to group signals together in some
    >> > synthesizable VHDL code, for readability as much as anything else. The
    >> > signals within the record are driven by one of three processes, with
    >> > each element of the record having only one driver.

    >> Every process that drives any element of the record needs to drive
    >> EVERY element of the record. With resolved data types (SLV),
    >> "undriven" elements can be driven with 'Z'.

    >This makes sense. I left out the fact that some of the elements are of
    >integer type, and this seems important because there's no resolution
    >function for that type. If everything were based on std_logic, I think
    >I'd be fine.


    The simplest answer is to use the IEEE.numeric_std library, and use
    unsigned (or signed) for any integers you need to share in this way.
    This is pretty close to basing everything on std_logic.

    It will simulate (marginally) slower but IMO it's easier than writing
    resolution functions for integer, and it is fully supported for synth
    and sim.

    Converting to/from integer needs conversion functions (to_integer and
    to_unsigned) but you can freely mix integer and unsigned in arithmetic
    (the result of any mixed expression is unsigned).

    - Brian
     
    Brian Drummond, Nov 27, 2007
    #6
  7. Dave

    Dave Guest

    On Nov 27, 11:02 am, Brian Drummond <>
    wrote:
    > On Mon, 26 Nov 2007 13:25:56 -0800 (PST), Dave <>
    > wrote:
    >
    > >On Nov 26, 4:17 pm, Andy <> wrote:
    > >> On Nov 26, 2:32 pm, Dave <> wrote:
    > >> > I am currently using records to group signals together in some
    > >> > synthesizable VHDL code, for readability as much as anything else. The
    > >> > signals within the record are driven by one of three processes, with
    > >> > each element of the record having only one driver.
    > >> Every process that drives any element of the record needs to drive
    > >> EVERY element of the record. With resolved data types (SLV),
    > >> "undriven" elements can be driven with 'Z'.

    > >This makes sense. I left out the fact that some of the elements are of
    > >integer type, and this seems important because there's no resolution
    > >function for that type. If everything were based on std_logic, I think
    > >I'd be fine.

    >
    > The simplest answer is to use the IEEE.numeric_std library, and use
    > unsigned (or signed) for any integers you need to share in this way.
    > This is pretty close to basing everything on std_logic.
    >
    > It will simulate (marginally) slower but IMO it's easier than writing
    > resolution functions for integer, and it is fully supported for synth
    > and sim.
    >
    > Converting to/from integer needs conversion functions (to_integer and
    > to_unsigned) but you can freely mix integer and unsigned in arithmetic
    > (the result of any mixed expression is unsigned).
    >
    > - Brian


    That was what I meant - anything based on std_logic (which signed and
    unsigned are) gets resolved. Unfortunately, one of the elements of the
    record was a memory (array of std_logic), so the assign-high-impedance
    trick causes ISE to no longer be able to infer the block RAM the way I
    want, so I think I've got no choice but to break up the record into
    individual signals.
     
    Dave, Nov 27, 2007
    #7
    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. ALuPin

    Records in VHDL

    ALuPin, Apr 15, 2004, in forum: VHDL
    Replies:
    2
    Views:
    9,882
    Michael JB
    Apr 19, 2004
  2. Luke Airig
    Replies:
    0
    Views:
    816
    Luke Airig
    Dec 31, 2003
  3. afd
    Replies:
    1
    Views:
    8,493
    Colin Paul Gloster
    Mar 23, 2007
  4. Dan

    Delete records or update records

    Dan, May 10, 2004, in forum: ASP General
    Replies:
    1
    Views:
    480
    Ray at
    May 10, 2004
  5. Replies:
    3
    Views:
    695
    Anthony Jones
    Nov 2, 2006
Loading...

Share This Page