I am looking at using OVM for some of my projects. What I didn’t get out of the online seminar or other materials is a good approach for handling verification of a DSP Model. For some of our tasks, our Systems Engineers create a Matlab model with vectors for certain block outputs. Our previous testbenches would pull those signals our and compare the results against the Matlab vector output files. How best would I approach this with the OVM? Would I use an analysis port for internal signal access and then a verification component that would read the vector file to use for comparisons? Thanks for any direction on this.
Bill
I understand your comments, and can agree with the direction. Reality is, I need to baby step the rest of the team in that direction. We are a big cruise ship, not a speed boat in this organization. That said, I need to show value and be able to integrate their existing methods into the “new” verification approach with the goal of going to what you have stated. Does this make sense?
Bill,
You have your work cut out for you. Leveraging the old ways is the correct first step. I have built several environments and the design team ALWAYS wants there file input and output to work (usually first). Once I have that working not by doing it directed but by making a random environment which takes in files as necessary (takes more time and work so be ready for some ribbing).
After that you are ready to do what Amal suggested. I could see you driving the Matlab model with random created data; the same data that goes into the DUT. Then taking the Matlab output into a scoreboard and the DUT data into a scoreboard and comparing.
Don’t be surprised if they don’t match and the Matlab model is at fault - this has happened to me more than once when verifying DSP engines. As before you team has relied on the Matlab model as golden, you are also. But now you can generate more interesting data than what the System Engineers provided and provide a level of hardware variability that will catch bugs. This is a win-win situation. And if in fact you work for a cruise ship you have time on your side :-)
Good Luck,
TomT…
Bill,
I’m in a similar “cruise ship” and looking to migrate to ovm.
We have a vector_file type which is an ovm_transaction extension. It contains a queue and filehandle-like methods for loading a txt file into the queue and then accessing the queue. We choose to load the entire txt file into the queue in one shot but a guy could just as easily load a line/portion at a time.
An ovm_component (likely your scoreboard in this case) would make an instance of the vector_file, hit the load method, and then access the contents.
Ideally, you could take a step further and feed the queue into an unpack method (assuming the data in the vector files has some sort of formatting… however simple) and then you’d have a “real” transaction. This would be a good example to get your systems guys thinking in terms of transaction-level modeling which really is the point when moving toward ovm (avm/vmm/rvm/etc).
Neil