Custom VC for image-sensor interface

Why OSVVM™? › Forums › OSVVM › Custom VC for image-sensor interface

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • December 1, 2022 at 09:28 #2107
    Thomas
    Member

    Hi,

    we’re currently looking for a verification methodology to integrate into our VHDL-based FPGA flow. I’m interested in how to create stimulus for custom chip interfaces, in this case an image sensor with a proprietary serial interface with multiple LVDS lanes. The interface module translates the LVDS input into an AXI-Stream packet with video data.

    I want to be able to call a procedure that creates an entire video frame and the LVDS stimulus. Ths number of LVDS channels is a generic. The frame data depends, among others, on the following parameters:

    – Image width
    – Image height
    – Color depth
    – Horizontal blanking time
    – Pixel data contents

    It probably doesn’t make sense to specify the entire frame data, so there should be a sensible way to produce data that can be recreated by a checker. Maybe a simple counter or random values with a specific seed.

    I also want to be able to inject errors, e.g., inject bit errors in the LVDS streams with a given probability.

    I’m guessing that this doesn’t map to the MIT model, so I’d have to create a custom transaction and driver for this. I’d like to get a feeling for what would be a good/canonical way to go about this.

    – Should I create a Send() procedure that takes all of the values listed above as parameters?
    – Or should I create a mechanism to set some of these as “model options”?

    I guess this depends on which values I want to vary frame-by-frame that a checker needs to know about (definitely random seed), and which parameters remain mostly fixed during a test. I’m also unsure how to model the error injection in a sensible way.

    These are my thougths so far. I’d appreciate any input.

    Thomas

    December 1, 2022 at 15:40 #2108
    Jim Lewis
    Member

    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

    December 11, 2022 at 03:00 #2118
    fpgaphreak
    Member

    My question would be what the intention is in detail: Typically sensor interfaces are simulated and tested independently from the image content. Therefore I produced a test package capeable of driving various signal schemes and bahaviour into the lvds lines which can be simulated and also synthesized into an FPGA for real investigations of eye patterns.

    The other issue is the image content like defective pixels, stuck-at pixel and the typical fixed pattern / non uniformity issues which require various runs of simulation which at the time can be done with compiled simulations only (HDL Coder) with the full image.

    I wonder if there is a possible approach to simplify this by an intelligent frame work leaving out the fields without interest, or reveals already processed data respectively.
    ?

    December 13, 2022 at 09:07 #2121
    Thomas
    Member

    Hi Jim,

    thanks, I appreciate your detailed response. I have started implementing the VC with most parameters as model options. Originally I wanted to create a custom transaction type, but for now I am using the Stream MIT. I use the data parameter of Send() to pass the seed for pixel-data generation and generate a complete frame. This doesn’t seem to fit exactly to the intended purpose of the Stream-Send() (sending a single data word), but it does the job.

    One reason I was looking for a framework with some existing VC/BFMs was the possibility to create sensor stimulus and, in parallel, access control and status registers through the AXI interface. This also works nicely.

    One problem I see with your suggestion to have Send() call SetModelOptions() automatically is that I somehow have to synchronize the parameters for the driver and checker, so that the checker parameters aren’t changed while a frame is still in flight through the DUT.

    Anyway, I’ll experiment a bit more with this and add a checker/scoreboard. I’ll post an update when I have made more progress.

    Thanks,
    Thomas

    December 13, 2022 at 09:35 #2122
    Thomas
    Member

    Hi fpgaphreak,

    I have two main goals with this test bench:

    – Check that pixel values generated on the sensor input appear in the appropriate form on the AXI-Stream output, and completion interrupts and status registers are set correctly
    – Check that the interface logic is well-behaved in the case of errors on the LVDS inputs, i.e., no FSM deadlocks, well-formed output, and correct error interrupts and status registers

    December 13, 2022 at 20:15 #2123
    fpgaphreak
    Member

    So it seems more check for implementation issues rather than functional.(?)
    I wonder how and in wich way one could alternatively simulation LVDS issues. Foussing on driever behavior?

  • Author
    Posts
Viewing 6 posts - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.