Reply To: Custom VC for image-sensor interface

[Jim Lewis]

Hi Thomas,
I try to divide the concerns into what must be done for every transaction and what is stable for a long period of time. Things that are stable for a long period of time can be set with SetModelOptions.

The error injection probability is a candidate for SetModelOptions.

You may wish for things like Image Width, Height, Color Depth, Blanking time to be a long term setting and set it with SetModelOptions, it could also be passed with the Params field of the MIT, or you could create a custom transaction that passes the information.

For AxiStream, has the fields ID, Dest, User, and Last. We may want to either set these on a transaction by transaction basis or use default settings. The default settings are set by SetModelOptions (via an abstraction layer done in AxiStreamOptionsPkg.vhd).

On a transaction by transaction basis, these fields can also be set by using the Params field. Therefore the Params field must be setup to hold the concatenation of these fields. Fortunately they are a fixed size for a given interface, so this is straight forward to do. The values are put in the Params field in the order ID, Dest, User, Last.

In the call to Send, Params is an unconstrained std_logic_vector value. If not all values are specified, left hand values are filled in with a ‘-‘. In the verification component if a field is a ‘-‘, then the default value for that field (set by SetModelOptions) is used. This gives us a flexible setup – order the settings so that things that need to be specified most frequently are on the right.

Also with the burst mode on stream that supports putting a parameter value into the burst fifo (STREAM_BURST_WORD_PARAM_MODE). AxiStream uses this mode to specify the User field for every transaction of a burst.

The limitation to using the Params field is that each value must be converted to a std_logic_vector. Therefore things like image width need to be sized based on the maximum image width the VC will support.

With respect to checking and error injection, the checker will need to know when an error has been injected. This is a fundamental part of the stimulus generation. So it either the VC that does the error injection needs to push this into a scoreboard or a monitor VC needs to observe the stimulus being generated and push this into a scoreboard. The checker then would check against the scoreboard information that has the error injection information in it.

A mechanism that I have not explored yet, is to have the Image width, height, Color depth, and Horizontal blanking time be the first items in the burst FIFO and have the VC extract the information.

You could also create an overloaded version of send that accepts all the parameters you wish to have in the form that it is natural to handle them. This overloaded version of send could use the record fields as it wishes and your VC could interpret them. This issue with that is that the current transaction record only supports the fields that are currently there. Alternately the overloaded send could make several calls to SetModelOptions and then call the MIT version of send.

Long term, I am planning on extending the Params data structure used in the Axi4Manager VC to be a singleton data structure that can be passed in the transaction record. That would allow an overloaded version of Send to be able to set any parameter in the Params structure and then do the Send transaction.

This should give you some ideas. If you have more questions let me know. Then when you finish it, if you are happy with it, you can Guest Write a blog on OSVVM.org.

Cheers,
Jim