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