| Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
| |||
| |||
| Hi, I am required to use a Snooper module to test a Memory Controller. I basically require it to verify if the "data writes into the memory" & "data reads from the memory" are operating without errors in accordance with the correctness of the address & correctness of the data. To elaborate, I have the following scenario: CLIENT --------------- MEMORY CONTROLLER ------------ MEMORY WRITE: Client provides the data to the memory controller to be written into memory.It also provides the starting address from which data has to be written into the memory. READ: Client provides the starting address from which data has to be read from memory and passed along and returned to the client. But I couldn't find any relevant literature or Verilog Code examples to design snooper.My behavioral design describing the above process is ready with me.But I need to test it. Can anyone direct me somewhere (online links) or help me out with the purpose,design & effectiveness of Snoopers in testing & Verification. Regards, Gokul |
|
#2
| |||
| |||
| On Fri, 5 Sep 2008 03:40:46 -0700 (PDT), Gokul wrote: >Hi, >I am required to use a Snooper module to test a Memory Controller. [...] > CLIENT --------------- MEMORY CONTROLLER ------------ MEMORY > >WRITE: Client provides the data to the memory controller to be written >into memory.It also provides the starting address from which data has >to be written into the memory. > >READ: Client provides the starting address from which data has to be >read from memory and passed along and returned to the client. I really can't follow from your description what you mean by "snooper". But I think I do understand what you wish to do. You need to observe activity on both the client and the memory side of the controller, and feed both sets of observed activity to some kind of comparison module that will check they are the same. Yes? No? Most verification engineers would use the term "monitor" or "observer" to describe the block of code that watches the client-side or memory-side connection, and "comparator" or "end-to-end checker" to describe the block of code that compares the two monitors' observations to check whether the memory controller is doing its job correctly. The monitors are usually fairly straightforward to code, although they may be quite tedious if the bus protocols are complicated. The comparator may be quite simple, especially if the memory controller does not support overlapped or out-of-order memory access; but if there is any interleaving of accesses, it can get quite difficult. However, in Verilog there may be other possible approaches. How is your memory modelled? Is it something like a DDR memory for which commercial models exist, or are you creating your own model? You may be able to observe the modelled memory contents and check that they have been correctly updated or read by activity on the client side. That would save you the trouble of observing and interpreting the memory-side protocol, because the memory model has already done that work for you. Another useful idea is this: Write a snooper (monitor) for the client-side interface. Whenever you see a write transaction, update your snooper's own local copy of the expected memory contents with the written data. When you see a read transaction, compare the results that you see from the memory controller with the data that you have stored in your local memory copy. In that way, there is no need to monitor the memory-side interface at all, but you won't get such good debug of any errors in the memory controller - you'll just get an indication that it didn't work, possibly at a much later time than the actual occurrence of the error. HTH -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. |
![]() |
| Thread Tools | |
| Display Modes | |
In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.