Friday, November 21, 2008     Register | Login | Search | Contact Us
     
   
     
     

Many of you already received communications about the move of the Cadence user community into cadence.com. And many of you have already joined, with over 4000 registrations in the first two weeks.

The new Cadence Community enhances the ability of Cadence users to connect and collaborate. In addition to moving the community into cadence.com -- enabling single sign-on for community, Sourcelink and Cadence events -- the new site is organized around nine technology segments, giving you easy access to product information, training, forums and blogs. Some of the new features include:
  • Ability to respond to posts via e-mail
  • Technology-specific blogs
  • Latest Web 2.0 social networking capabilities
  • Public profile options
  • Private messaging
  • Friends lists
Visit the new Cadence Community today at www.cadence.com/community and join the discussions!

Registration note: Due to the scope of the enhancements and the new SSO registration system, we were not able to migrate existing cdnusers.org member accounts. So new registrations are required, but this enables a broader set of functionality we think you'll enjoy.

Forum note: Under the guidance of forum moderators, we have taken the 20+ cdnusers.org forums and consolidated them into 11 forums on the new site. Posts have been brought over so you can leverage that posting history. CDNusers forums will be set to read only starting 7/30, and cdnusers.org will be redirected to the new community on 8/4.

Best regards,
Mike and Tom

Michael A. Catrambone - Steering Committee Chairman
Distinguished Engineer
PCB/Mechanical
UTStarcom, Inc.

Tom Diederich
Cadence Community Manager
Home
Forums
Forums > Functional Verification > SystemVerilog

Subject: Intelligent sequence driver
Posting to forums is available to community members only.
Login or Register
Rate this topic:
   
Author Messages
weberrm
Posts: 0
Online: User is Offline
9/13/2007 7:28 AM  
Instead of a sequence driver randomly creating simple sequences like READ and WRITE, I need something with a little more intelligence.

Consider 3 functions, FUNCA, FUNCB, and FUNCC that operate on an address, addr. FUNCA and FUNCC can always randomly occur to any addr. FUNCB can only operate on an addr between the time FUNCA has operated on that addr and FUNCC has operated on the addr. Basically FUNCA to addr=N enables FUNCB to addr=N and FUNC to addr=N disables FUNCB to addr=N.

A sequence like the following can occur: 

FUNCC, addr=K 
FUNCA, addr=N  // Enables FUNCB to addr=N
FUNCA, addr=K  // Enables FUNCB to addr=K
FUNCA, addr=N  // N already enabled
FUNCB, addr=N  // FUNCB operating on addr=N 
FUNCB, addr=K  // FUNCB operating on addr=K
FUNCB, addr=N  // FUNCB again operating on addr=N
FUNCC, addr=N  // FUNCB to addr=N disabled
FUNCA, addr=N  // FUNCB to addr=N enabled again
FUNCB, addr=N
FUNCC, addr=K
FUNCC, addr=N

I'm new to SystemVerilog and URM so my questions are the following:

Does the code to keep this state around go in the driver?

Assuming the answer is yes, what are some recommendations on how to create these sequences?

Some ideas I've been given…
Create a list of "legal FUNCB addresses" where:

FUNCA randomly picks an address and adds to the list (if the addr is not in the list already)

FUNCC randomly picks an address and pulls off the list (it wouldn't do anything if the addr was not in the list)

FUNCB counts the length of the list and then randomly chooses a spot in the list to select out the address.

Any other ideas?

Any suggestions for how to code up the idea I've been given?

Thanks,

Ross
pjigar
Posts: 22
Online: User is Offline
9/14/2007 7:17 AM  

The solution you described is the one I would use. Basically, any information that "leaves" throughout the simulation should go in to structural elements such as sequence driver. Any temporary data strcutures that only apply to a particular trasnsaction or a series of transactions should go in to disposible elements such as a sequence.

You should maintain a dynamic array of addresses in the driver which get updated by FUNCA and FUNCC to add and remove an (randomly generated) address respectively. FUNCB will generate a random address keeping it inside dynamic array in the driver.

While we are talking about transaction history topic, I would like to add one more point: The sequence driver is capable of maintaining the history of past sequences as well. You can query the sequence history if there are lots of dependencies between sequences. Your case is simple and generic enough to "all" the sequences and hence I would not pick the "sequence history" route. Being said that, sequence history can be useful in some other cases.
Jigar Patel
Lead Consulting Engineer
Cadence Design Systems
jigar@cadence.com
weberrm
Posts: 0
Online: User is Offline
9/14/2007 8:12 AM  
Thanks for the response.  I would like to complicate the scenario a little more...

Assume that the interface this UVC is connected to is a processor-like interface.  The UVC is driving out requests to certain addresses and responses to those reqeusts are later returned.  Also, reqeusts are coming into the UVC and it has to respond to those requests appropriately.  The requests being made by the UVC are dependent on the state of the UVC (kind of like my original post).  However, how the UVC responds to requests is also dependent on the state of the UVC.

My questions are:

I'm having troubles mapping these sub-interfaces, request out (RQo), response in (RSi), request in (RQi), response out (RSo) to either the master or slave agent in the UVC.  Should the master agent interact with the RQo and RSi interfaces and the slave agent interact with the RQi and RSo interfaces?  Should there be multiple UVCs for this interface?  I don't really know.

Another issue is that if the sub-interfaces are mapped to different agents or UVCs, they need to base the transactions they are driving out on some of the same state information.  For instance, if the UVC makes a request for an address on the RQo interface and then before it receives a response to that request, receives an input request on the RQi interface, the response it generates needs to be based on the fact that the UVC has a request outstanding that hasn't yet been responded to.  This example is just one of many similar examples.

Thanks again!
Posting to forums is available to community members only.
Login or Register
Forums > Functional Verification > SystemVerilog > Intelligent sequence driver


ActiveForums 3.6
     
Copyright 2006 Cadence Design Systems, Inc.