Stats

  • Locked Locked
  • Replies 6
  • Subscribers 64
  • Views 14491
  • 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

Sequences sharing the same item type

archive

Hi,
 
I have problem when I try to declare two sequence struct and sequence drivers using the items of the same type:
 
sequence seq_A_s using
  item           = packet_s,
  created_driver = driver_A_u,
  created_kind   = seq_kind_A_t;
 
sequence seq_B_s using
  item           = packet_s,
  created_driver = driver_B_u,
  created_kind   = seq_kind_B_t;
 
 
This code leads to the following error message:
 
 
   *** Error: Cannot use item: `packet_s` in the sequence statement.
    it is already used in another sequence statement.
        at line 31 in ../env/seq.e
sequence sequence seq_B_s using
 
 
I can't find anything on the documentation that restricts the use of item types of sequences, nor restrictions on extension of any_sequence_item interface. I think that could be interesting to have two different sequence statements using the same item type on some environments in order to have sequence drivers with different behavior and sequences acting on the same kind of data. This seems to be the most direct approach and I can't find why it doesn’t work.
 
 
Thanks for any suggestion
 
Montu


Originally posted in cdnusers.org by vbdc_montu

  • Interesting...
    In what ways will the sequence drivers be different from each other?




    Originally posted in cdnusers.org by thinkverification

  • Well, the drivers will act on different BFMs, and the respective sequence structs have too little in common. In special, the sequence subtypes of one driver shouldn’t be driven by the other one. Therefore, in the case of a single sequence driver be instantiated twice, it would be necessary to specify different behaviors for their MAIN sequence in order to restrict the sequence subtypes generated by each one. I think that this will bring an unneeded extra complexity, and I think that would be easier to create different sequence drivers and sequence structs.


    Originally posted in cdnusers.org by vbdc_montu

  • Thanks for the explanation.
    I think that if you CAN use 2 instances of the same eVC and your only problem is restricting the MAIN sequence - then it's worth it. It should be fairly simple to create a list of "allowed" sequences and generate one of them at a time or you could have all this done in a dedicated sequence, using the respective eVC name as a subtype.

    For example -
    extend PORT1 MAIN sequence {
    keep seq.kind in [KIND1, KIND2..];
    };
    extend PORT2 MAIN sequence {
    keep seq.kind in [KIND3,KIND4...]
    };


    I believe the solution for reusing the same data item to drive 2 different physical interfaces would be to create a higher level generator as a standalone unit and and hook it up ("layer") to the BFM sequence driver. Here the lower level sequence will only act as a container, while the real data is requested from the generator.

    I hope this helps :-)


    Originally posted in cdnusers.org by thinkverification

  • Hi Yaron, I think your solution can do the job.

    Thanks for the help!


    Originally posted in cdnusers.org by vbdc_montu

  • My pleasure !


    Originally posted in cdnusers.org by thinkverification

  • Hi,

    If restricting the sequences under each of the instances of the sequence-driver is what you need, you might need to do more than constrain the field in the MAIN sequence.

    There is a pre-defined method "in_unit()" that you can use to constrain the kind of sequence generated under a unit (env/agent/driver as appropriate).  This is described in the e-Reference manual section "18.5.2 in_unit()" and might look similar to the example in the eRM Manual section"5.7.3.1 Unit IDs to constrain Sequences"

    Your code would look something like:

    extend my_sequence {
       keep in_unit (PORT1 my_agent) => kind in [KIND1, KIND2]; // and/or could specify "not in" if that's more convenient
    };

    Also, I would recommend that you keep the set of sequences for each port in a separate file so it is easy to find and maintain the sequence library associated with each instance.

    Hope that helps,
    Dean


    Originally posted in cdnusers.org by ddmello

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.