verification of memory controller

N

Nisha_tm

Guest
Hello:

If you have a typical system in which the CPU
accesses the DRAM via a memory controller (present in
an ASIC), how do you make sure that the transactions
are going to the correct address in the memory.

For example if CPU is giving address A1, then the ASIC
is supposed to write to location A1. What if the ASIC
does a bad decoding and writes to address A2.

In a normal verification, when we do a write followed
by a read, we get back the correct data, since the
ASIC (mistakenly) wrote to A2 and read back from A2,
while the CPU wanted to write to A1 and read back from
A1.

One way I know is to put a monitor onthe
CPU<->ASIC bus and also on the ASIC<->memory bus and
compare the addresses of every transaction..
Is there any easier way?
Thank you for your help.
 
One way I know is to put a monitor onthe
CPU<->ASIC bus and also on the ASIC<->memory bus and
compare the addresses of every transaction..
Is there any easier way?
Click to expand...
What you are addressing with monitors is assertion-based verification (ABV)
which can be done with HDL, Open Verification Library (OVL), PSL, System
Verilog, Vera, ..

That would work.
----------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Using PSL/SUGAR with Verilog and VHDL
Guide to Property Specification Language for ABV, 2003 isbn 0-9705394-4-4
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
 
You can read/write the memory through "back-door" in Verilog.

For read test, you can first initialize the target address like this:
top.dram.mem[A1] = D1

then you read the address A1 through CPU and check if it returns D1.

For write test, you do the opposite: first write data to an address via CPU
i/f, then read the address and compare the result like this:
if (top.dram.mem[A2] == D2)

Jim Wu
jimwu88NOOOSPAM@yahoo.com
http://www.geocities.com/jimwu88/chips

stocker70@yahoo.com (Nisha_tm) wrote in message news:<e27aafef.0308291344.51eec20e@posting.google.com>...
Hello:

If you have a typical system in which the CPU
accesses the DRAM via a memory controller (present in
an ASIC), how do you make sure that the transactions
are going to the correct address in the memory.

For example if CPU is giving address A1, then the ASIC
is supposed to write to location A1. What if the ASIC
does a bad decoding and writes to address A2.

In a normal verification, when we do a write followed
by a read, we get back the correct data, since the
ASIC (mistakenly) wrote to A2 and read back from A2,
while the CPU wanted to write to A1 and read back from
A1.

One way I know is to put a monitor onthe
CPU<->ASIC bus and also on the ASIC<->memory bus and
compare the addresses of every transaction..
Is there any easier way?
Thank you for your help.
Click to expand...
 
stocker70@yahoo.com (Nisha_tm) wrote in message news:<e27aafef.0308291344.51eec20e@posting.google.com>...
Hello:

If you have a typical system in which the CPU
accesses the DRAM via a memory controller (present in
an ASIC), how do you make sure that the transactions
are going to the correct address in the memory.

For example if CPU is giving address A1, then the ASIC
is supposed to write to location A1. What if the ASIC
does a bad decoding and writes to address A2.

In a normal verification, when we do a write followed
by a read, we get back the correct data, since the
ASIC (mistakenly) wrote to A2 and read back from A2,
while the CPU wanted to write to A1 and read back from
A1.

One way I know is to put a monitor onthe
CPU<->ASIC bus and also on the ASIC<->memory bus and
compare the addresses of every transaction..
Is there any easier way?
Thank you for your help.
Click to expand...


One way to check the memory is to first fill the entire
memory with the value of the address.
And then read back, and immediately fill with the inverse
address value.
You should eventually catch any problems. Of course using
the "memory back door" in verilog as somebody else described,
will also help.

Regards,
rudi
--------------------------------------------------------
www.asics.ws --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores
 
russelmann@hotmail.com (Rudolf Usselmann) wrote in message news:<d44097f5.0308311028.71127ca1@posting.google.com>...
stocker70@yahoo.com (Nisha_tm) wrote in message news:<e27aafef.0308291344.51eec20e@posting.google.com>...
Hello:

If you have a typical system in which the CPU
accesses the DRAM via a memory controller (present in
an ASIC), how do you make sure that the transactions
are going to the correct address in the memory.

For example if CPU is giving address A1, then the ASIC
is supposed to write to location A1. What if the ASIC
does a bad decoding and writes to address A2.

In a normal verification, when we do a write followed
by a read, we get back the correct data, since the
ASIC (mistakenly) wrote to A2 and read back from A2,
while the CPU wanted to write to A1 and read back from
A1.

One way I know is to put a monitor onthe
CPU<->ASIC bus and also on the ASIC<->memory bus and
compare the addresses of every transaction..
Is there any easier way?
Thank you for your help.



One way to check the memory is to first fill the entire
memory with the value of the address.
And then read back, and immediately fill with the inverse
address value.
You should eventually catch any problems. Of course using
the "memory back door" in verilog as somebody else described,
will also help.

Regards,
rudi
--------------------------------------------------------
www.asics.ws --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores
Click to expand...

Hi,

Rudi has a good solution here and just what I had in mind. However,
you might want to encode and decode the address that you use as data.
The generated data may ensure byte lanes are not messed up and also
each bit is toggled.

Regards,

- Prasanna
 
rudi:
Can you please elaborate on this procedure?
For example, if I have two memory locations whose
addresses are A and B.
Whenver, CPU writes/reads to location A, the asic translates(unintentionally)
and performs the writes/reads to B.
Whenever CPU writes/read to location B, the asic translates(unintentionally)
and performs the writes/reads to A.

How does filling in the Address value as data and filling
in with the inverse address value, help detect this ASIC bug?

thank you

One way to check the memory is to first fill the entire
memory with the value of the address.
And then read back, and immediately fill with the inverse
address value.
You should eventually catch any problems. Of course using
the "memory back door" in verilog as somebody else described,
will also help.

Regards,
rudi
--------------------------------------------------------
www.asics.ws --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores
Click to expand...
 
stocker70@yahoo.com (Nisha_tm) wrote in message news:<e27aafef.0309031454.2edc12fe@posting.google.com>...
rudi:
Can you please elaborate on this procedure?
For example, if I have two memory locations whose
addresses are A and B.
Whenver, CPU writes/reads to location A, the asic translates(unintentionally)
and performs the writes/reads to B.
Whenever CPU writes/read to location B, the asic translates(unintentionally)
and performs the writes/reads to A.

How does filling in the Address value as data and filling
in with the inverse address value, help detect this ASIC bug?
Click to expand...
Basically what you do is something like:

1) Fill
for(n=0;n<final_addr;n++)
write(addr=n, data=n);

2) Read, verify Refill
for(n=0;n<final_addr;n++) {
check(data1=n, data2=read(addr=n) );
write(addr=n, data=!n);
}

3) Read, verify
for(n=0;n<final_addr;n++) {
check(data1=!n, data2=read(addr=n) );
}

The second fill and 3rd step ensure that the memory controller
does not destroy any data that is located above the current
location when it is doing a read and a write.

This is by far not complete, there are many other cases
you should probably add, but this will probably cover
about 90+%

thank you
Click to expand...
Best Regards,
rudi
========================================================
ASICS.ws ::: Solutions for your ASIC/FPGA needs :::
...............::: FPGAs * Full Custom ICs * IP Cores :::
FREE IP Cores -> http://www.asics.ws/ <- FREE EDA Tools
 
"Nisha_tm" <stocker70@yahoo.com> wrote in message
news:e27aafef.0309031454.2edc12fe@posting.google.com...

For example, if I have two memory locations whose
addresses are A and B.
Whenver, CPU writes/reads to location A, the asic translates
(unintentionally) and performs the writes/reads to B.
Whenever CPU writes/read to location B, the asic translates
(unintentionally) and performs the writes/reads to A.

How does filling in the Address value as data and filling
in with the inverse address value, help detect this ASIC bug?
Click to expand...
It doesn't, but then in many situations it's not a bug!!!!

If you test a read/write memory by ANY collection of reads and writes,
you will NEVER detect the bug you've described - because the (re-mapped)
memory is still performing correctly for the purpose you're verifying;
whenever you write a value V to location L, then at any future time
when you read location L you will get value V. That sounds like
good R/W memory behaviour to me. For many years, PCB layout
engineers have scrambled the address pins on RAM devices to simplify
PCB layout, knowing that it makes no difference to the RAM behaviour.

But if it's a video RAM, or anything with more functionality than
simple read-write, of course it DOES matter. So you must verify
the CONTENTS as well. Just like others have suggested to you.

The moral of the story is that you must verify the specifications
that you need to be valid. The specification of a simple read/write
memory says that you can read back whatever you wrote. Address
scrambling does not violate that specification; so there is
no need to verify whether it happens or not.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top