Stats

  • Locked Locked
  • Replies 3
  • Subscribers 64
  • Views 13688
  • 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

Intelligent sequence driver

archive

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


Originally posted in cdnusers.org by weberrm
Parents

  • 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.


    Originally posted in cdnusers.org by pjigar
Reply

  • 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.


    Originally posted in cdnusers.org by pjigar
Children
No Data

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.