Sequences sharing the same item type > Forums

Forums

Subject: Sequences sharing the same item type

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

vbdc_montu
Posts: 6
Online: User is Offline

4/07/2008 10:46 AM
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

thinkverification
Posts: 28
Online: User is Offline

4/08/2008 2:00 AM
Interesting... In what ways will the sequence drivers be different from each other?

Yaron Ilani VLSI Verification Specialist www.ThinkVerification.com

vbdc_montu
Posts: 6
Online: User is Offline

4/08/2008 4:48 AM
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.

thinkverification
Posts: 28
Online: User is Offline

4/08/2008 5:32 AM
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 :-)

Yaron Ilani VLSI Verification Specialist www.ThinkVerification.com

vbdc_montu
Posts: 6
Online: User is Offline

4/08/2008 6:21 AM
Hi Yaron, I think your solution can do the job. Thanks for the help!

thinkverification
Posts: 28
Online: User is Offline

4/08/2008 7:01 AM
My pleasure !

Yaron Ilani VLSI Verification Specialist www.ThinkVerification.com

ddmello
Posts: 15
Online: User is Offline

4/10/2008 4:59 PM
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 { <BR> keep in_unit (PORT1 my_agent) => kind in [KIND1, KIND2] // and/or could specify "not in" if that's more convenient <BR>}; 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

Posting to forums is available to community members only.
Login or Register

Forums > Functional Verification > e > Sequences sharing the same item type