Stats

  • Locked Locked
  • Replies 1
  • Subscribers 65
  • Views 13555
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Specman e: Configurable bus width and transfer generation

Steff

Hi all,

I'm currently developing a bus UVC which shall support configurable bus widths (8, 16, 32, 64 bits).

For the configurable bus width I use the approach as described by StephenH on Verification Guild:
http://verificationguild.com/modules.php?name=Forums&file=viewtopic&p=8967

In short, I'm using defines for the maximum supported width and have a configuration parameter for the agent which contains the actual width.

Now my problem is that the struct containing the physical fields (e.g. address, data, size, byte strobes) doesn't know anything about the actual configured data width.

Example struct:
type xyz_bus_address_t : uint(bits:MAX_ADDRESS_BUS_WIDTH);
type xyz_bus_data_t : uint(bits:MAX_DATA_BUS_WIDTH);
type xyz_bus_size_t : [BYTE=0, HALF_WORD=1, WORD=2, DOUBLE_WORD=3] (bits:MAX_DATA_SIZE_WIDTH);

struct xyz_bus_data_item_s like any_sequence_item {
    %address : xyz_bus_address_t;
    %data : xyz_bus_data_t;
    %size : xyz_bus_size_t;

    -- Access to address offset +0 => byte, half word, word, double word
    -- No constraint for address offset +0
    -- Access to address offset +1,+3,+5,+7 => byte
    keep address[0:0] == 1 => size == BYTE;
    -- Access to address offset +2,+6 => byte, half word
    keep address[1:0] == 2 => size in [BYTE,HALF_WORD];
    -- Access to address offset +4 => byte, half word, word
    keep address[2:0] == 4 => size in [BYTE,HALF_WORD,WORD];
    ...
};

The constraining of the size done above is only valid in case a 64 bit bus is configured as a double word access might be generated randomly even if the bus is configured for a smaller width.

Now I'm not sure what to do.
Does the struct needs to get the actual bus width as a virtual field? I think this is ugly as the user always has to provide the actual size to a method when generating a transfer.
Or should I leave the physical fields in the struct without constraints (for use in a monitor) and generate the values of the actual transfer e.g. in the BFM on the fly as it knows the actual width?

Can you suggest me a best practice how to solve this problem?

Best regards,
Stefan
P.S.: I'm a beginner in Specman e so please be patient with me :-)

  • Hi Stefan.

    Welcome to the world of Specman! :-)

    What I typically do is to have an enumerated type for the bus instance name, e.g.
    type xyz_bus_name_t : [XYZ0, XYZ1];

    The agent, montior, BFM and sequence driver would all be sub-typed using this enum, so that you can extend them by kind.
    The same applies to the sequence item. You can then put a constraint in the base sequence to constrain the item's bus_name to match the driver's bus_name.

    struct xyz_bus_data_item_s like any_sequence_item {
      bus_name : xzy_bus_name_t;
    };

    extend xyz_bus_data_item_s {
      when BUS0 {
        keep size in {BYTE;HALF_WORD};
      };
      when BUS1 {
        keep size in {WORD};
      };
    };

    There may be other, better, ways to do this, but this works for me.

    Regarding randomising in the BFM, I would not recommend this; try to keep all the randomisation in the sequences if possible, otherwise you lose the controlability that sequences give you, and test writing becomes very difficult.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.