How can we verify a memory whose address location is swapped

UVM
,
1

lets say we are writing to address location 0x20
but due to bug… 0x20 is mapped to 0x40
so, whenever we try to read and write from 0x20, it will read and write from 0x40
so fetched data will always be right
but there exists a bug.
How to find it?

2

In reply to debashis_paul:

I would say there are two test scenarios where this bug would be revealed:

1- You can implement a task that accesses the memory array itself (through the hierarchical path of the RTL) and checks its content after each read/write operation versus an expected data array in the testcase

2- After each write operation you should read back the whole memory array using the same interface and make sure that the data is written only in 0x20, not 0x20 & 0x40… Of course in your scenario this will not detect that 0x20 was never written. It will just raise an alarm that 0x40 was unnecessarily written.

3

In reply to debashis_paul:

You can fill up entire memory with address as data pattern and read back entire memory with return data as address value

so have test list this

Address value Data value
0x0 → 0x0
0x1 → 0x1
0x20 → 0x20

and so on.

your read data will mismatch and catch this issue.

1 Like
4

In reply to RonakShah:

In reply to debashis_paul:
You can fill up entire memory with address as data pattern and read back entire memory with return data as address value
so have test list this
Address value Data value
0x0 → 0x0
0x1 → 0x1
0x20 → 0x20
and so on.
your read data will mismatch and catch this issue.

Still in this algorithm, since the address location is swapped, we will get the data that we have written … so when we right 'h20 to address 0x20, it will write in 0x40, and when we read from 0x20, it will read from 0x40, but data will be same as 20, so it will match.

5

In reply to debashis_paul:

I agree with paul statement …

6

In reply to debashis_paul:

If you write them all first then read them all you’ll read 0x40 from 0x20 (unexpected).

7

In reply to dee-2:

Hi Dee-2,
if you even write all the location and read back you will not find the bug…

lets take 2 location “x01 and x02”

   now in the RTL xo1 got connected to x02 location of the actual memory and
        in the RTL xo2 got connected to x01 location of the actual memory.

In the above case both address location got swapped.
so if you write and read the location in any order you will not find the bug , because you will read the same value what you have written in the address location x01 and x02.

I hope you understood the problem…

8

In reply to sumit089:

Yes the problem still exists … This bug cannot be found by simply writing and reading all locations …

9

How about Pre-loading entire memory with pre-defined data using System Verilog function $readmemb or $readmemh ?

After that just read need to be done ?

10

In reply to debashis_paul:

I have a question to you Debashish:

When you say the 0x20 is swapped with 0x40, what would happen when you do any write to 0x40 ? Will it hit 0x20 or will it stay at 0x40 ?

If by swapping you actually mean, 0x20 is swapped with 0x40, i.e. all writes and reads to 0x20 would hit 0x40 and all writes and reads to 0x40 would hit 0x20. This would still be a valid memory operation right ? There is no issue here as long as the 2 addresses are not conflicting with each other right ?

11

In reply to RonakShah:

I agree with that, it goes along with the first test scenario that I suggested: you need to find out the hierarchical path of the RTL memory array and use it in your testcase. Whether to preload defined data using $readmemh, or to check on already written data by an if statement in your SV testcase. Ex:

if (Design.Memarray[20] != 'h20) $error();

12

In reply to Ashith:

In reply to debashis_paul:
I have a question to you Debashish:
When you say the 0x20 is swapped with 0x40, what would happen when you do any write to 0x40 ? Will it hit 0x20 or will it stay at 0x40 ?
If by swapping you actually mean, 0x20 is swapped with 0x40, i.e. all writes and reads to 0x20 would hit 0x40 and all writes and reads to 0x40 would hit 0x20. This would still be a valid memory operation right ? There is no issue here as long as the 2 addresses are not conflicting with each other right ?

Yes, you are right Ashith. writing to 0x20 will hit at 0x40. and yes, it is valid memory operation. But i was trying to find out a pattern/algorithm to find such a fault in memory.

13

Hi debashis_paul,

I think Backdoor and frontDoor read/write will catch this type of Bug.
What i understand is that “Memory address swap” mean some problem with the address encoder/decoder ?
correct ???
So in that case different read-write from backdoor and frontdoor will get this issue.As data will not match in that case.

Thanks
Anu

14

In reply to anu.anu:

Yes Using RAL concept this issue can be caught,
Writing 0X20 data to 0X20 address via frontdoor will actually go and sit in 0X40
Reading 0X20 via backdoor will not give 0X20 thus implying that something is wrong .

Regards
Girisha

1 Like
15

In reply to debashis_paul:

I can think of an inefficient method of doing this - but please let me know your thoughts/suggestions.

If there is an address decoding problem, lets say there are 10 locations, we can write all 0s to 9 locations and a known pattern to one location,0x20(at a time). Then, when we do a read of all locations, if there is address swap, then 0x40/any other addr will read the value that we wrote instead of showing 0s.

Will this work? But this means that we have to iterate through every address.

Thanks

16

In reply to Girisha A B:

Yes, I guess RAL model is the right way to catch this issue.

17

I dont think this qualifies as bug if both locations are swapped.
In fact i have worked on Some designs where we have such swapable locations available to bypass memory manufacturing faults.

18

Hello.

If i understand the problem correct. The address 0x20 is mapped on 0x40, but 0x40 isn’t mapped on 0x20. If i understand the correctly the problem an robust testbench will catch the bug, if some write operations occured on 0x20 and affter on 0x40 (no read between the writes), on comparation there will be a missmatch. If i didn’t understand correctly the problem and the address 0x20 is mapped on 0x40 and vice-versa. I don’t know if this is a functional bug and i think RAL can solve the problem.

19

I think this will solve the issue if there is a bug in the testbench connection or mapping RAL model to DUT memory

20

I would say writing an simple small scoreboard of writing data to the address and checking the results use and condition compilation `ifdef and error bit so that when .error bit is begin raised that exact location will be detected. no matter wheather its an 0x20 or an 0x40 or 0xFF. if the data is not begin matched the error is raised.