Cached Pflash vs NonCached Pflash

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User19868
Level 1
Level 1
what Is the difference between cached program flash address space and noncached program flash address space, it seems in the datasheet for TC3xx both got same size 6MB divided into 2 banks, so I am missing the cache term here, if the cache memory space is already equal to the original flash, why both of them exist? I understand there definetly must be one physical PFLASH, then what is exactly happening here?
0 Likes
15 Replies
Darren_Galpin
Employee
Employee
First solution authored First like received
The same physical flash exists in both cached and non-cached space. The difference is in how the CPU accesses them. If accessed via a cached address, then the data once fetched is stored in the CPU cache, and any subsequent accesses will use the data from the cache rather than physically reading the flash. If the address used is non-cached, then the read is always physically done. The risk in using cached data of course is that you could change the underlying data in the flash, but this wouldn't be in the cache, but it allows for faster program execution by the CPU.
User19868
Level 1
Level 1
so if I am going to implement a safety mechanism for the flash I should do the check over the noncached flash and not the cached one or it doesn't matter since the values are the same in both cached and noncached?
how can the data change in the noncached during runtime? arent flash is written by erasing and reflashing?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
It would be better to do the check over the non-cached flash as you ensure that the read actually happens.

The flash is written and erased by reflashing. But the writing/erasing is done via command sequences in the DMU. Hence if the CPU has read data from the flash into its cache, something then reflashes the PFlash, you would end up with different data in the CPU cache to the pflash. Reflashing takes a lot of time, so the likelihood is that when exercising code the CPU would try and get something else to load into the cache and notice that the flash isn't available as it is being changed, and you would hope that the software programmer doing this would put some checking in place, but it is possible.
0 Likes
User19868
Level 1
Level 1
Thank you, Darren, you've been a great help ! just one last question, so if I am sure the PFLASH won't get reflashed during runtime under any circumstances if the command sequence in the DMU is not done at any time, implementing the safety mechanism on the cached would be the better option here for speed, correct? or refreshing using the DMU is a standard procedure that must take place cause I don't know much about it to be honest.
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Your safety mechanism would be wanting to check the safety of the flash data I would guess? Hence if you ran it from cached addresses, if the data was in the cache already all you would be doing is checking that the cache contents were correct - you wouldn't be checking the safety of the path to the flash itself. You would have proven that the path was ok when the data went into the cache, but not what happens after. If the data has to be fetched because it is not in the cache yet, then you won't get a speed up anyway as you still have to get the data.

So in summary, for a safety mechanism I would use the non-cached addresses, to make sure that we really are testing the safety of the path we are interested in.

The DMU would be used for reprogramming the flash as and when needed, so it shouldn't be running during standard operation.
0 Likes
User19868
Level 1
Level 1
yes the safety mechanism is to specifically check for ECC in a word line to check if reflashing is needed due to corrupt data in flash, but still, there is something missing here for me I guess, shouldn't I be checking for the integrity of the cached address space as well for ECCs? arent both vulnerable for ECCs? and during runtime the cached address space could get corrupt as well?
Edit:: The safety mechanism is to check periodically during runtime if any corruption in flash data occurs, not only after fetching data from non cached to cached
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
When the data is stored in the cache, it should be ECC protected (the ECC value is stored with the data). Hence when it is read from the cache, the CPU will check the ECC and flag an error if there is a mismatch, so the data in the cache is protected.
0 Likes
User19868
Level 1
Level 1
great yes, if you are familiar with the safety mechanism ESM[SW]:NVM.PFLASH:WL_FAIL_DETECT, it is required once such an error occurs, when the ECC is checked by CPU and the flag is raised, to read 10 pages in the same word line at which the previous error occurred, to verify the integrity of that word line and if multiple bit error flag is raised the word line is marked corrupted and refreshing is needed, so for such a use case, shouldn't the mechanism be ran on the cached where the CPU flagged the error after checking the ECC to check for ECC in the same word line?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
This ESM is intended to check the contents of the PFlash - if you are getting the contents from the cache, then your safety mechanism is no longer testing the PFlash, you are just rereading the contents of the cache each time, assuming that all of the data was there.

Hence if you read repeatedly out of the cache, you can see if you have an error in the cache which is either permanent or not, but you wouldn't mark the PFlash as corrupted and refresh/replace a wordline. To ensure that you really are testing the PFlash, I think that the ESM has to use non-cached addresses. This ensures that you really are seeing if the PFlash itself is corrupted, and you can then use the results to see if you need to swap out /refresh the flash.
0 Likes
User19868
Level 1
Level 1
I see your point and it seems to be what needs to be done, however, I just thought the flash physically exists in both address spaces cached and non-cached, regardless of the contents of the CPU cache itself, but the last question is how the caching works for the flash in such context? does the CPU fetch for example the start address from cached address space and then keeps incrementing by its step? or it keeps on fetching new data from the cached address space
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
The flash is physically the same. So when the CPU reads using cached addresses it will check the cache contents first, and if it gets a hit will return the data from there. If not, it then does a 256 bit (BTR4) read from PFlash, and stores the contents in the cache. If it is sequentially executing a orogram it will most likely then go and read the next 256 bits from flash. Note also that PFlash has a prefetch mechanism built in - it will go and fetch the next 256 bits anyway assuming that this is what the CPU will want.

If you access from non-cached addressing, then the cache will not be checked, and it will do the access from PFlash. However, it will fetch the data it wants, rather than always doing a BTR4/256 bits. To maintain performance the PFI interface to the PFlash will store the 256 bits it has read from PFlash in a local buffer and serve fetches from that until the address goes into the next 256 bits, when it will fetch that (although if there is a spare prefetch buffer it may go and fetch the next 256 bits anyway).

Whether the CPU keeps stepping through and fetching will depend on the program and what it predicts it will need next.

So you are correct in that the flash physically exists in both address spaces, and the cache is there to speed up the CPU. However, your safety mechanism is there to test the actual PFlash, hence why using the non-cached address is a better idea, as then you are sure that you are testing what you intend to test. And by fetching 10 pages, you are also sure that you have flushed all of the possible buffers and have really returned data from the flash.
0 Likes
User19868
Level 1
Level 1
so we could say about the cached address space its more of virtual addresses that direct the CPU fetch to the cache not directly to the physical flash, and the non-cached address space is just explicitly the physical flash itself so any access to it is direct access to the physical flash, would my understanding be correct?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
Yes, you can think of it that way.
0 Likes
FD_aurix
Level 5
Level 5
100 sign-ins 100 replies posted 5 solutions authored
Hi
I'm trying to figure out what is the difference between cached and non-cached flash.

Reading the user manual, architecture manual and the post above I've understood that in both cases a pre-fetch sequence on 256 bit is performed. In case of non cached flash the pre-fetch is performed on the non-cached flash addresses (range 0xA). In case of cached the pre-fetch is perfromed on the cached addresses 0x8 ( in reality I think is phisically performed on the PCACHE).

What I can't understand is how phisically it works in a different way the two addressing methods, why the cached address should be faster than the non cached. Where I can find some reference on how does it works (maybe here 5.3.6.3 Program Memory Interface (PMI))?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
The PMI chapter would be the place in the user manual to start for this.

There is no physical difference at the PFlash itself when using cached or non-cached addresses - the difference is in how the CPU handles it. When using cached addresses, the data is returned to the CPU and stored in the local cache - new accesses to the same address will return the data from the cache, saving cycles (it will take several cycles or more to return data from the PFlash, the cache can return the data immediately). If you use a non-cached address, then the CPU has to go to the PFlash and fetch the data, even if it is the same address. The PFlash itself doesn't know whether an address is cached or not, as it does not use the full 32 bit address for internal accessing.
0 Likes