Zen2 L1I cache and few architecture questions

[liad]

Hey all newbie here (3rd year ece),


So I've wondered why would AMD reduced the L1I cache. And have few options in mind , but I would love the be corrected.

1. the Mop cache isn't big enough for large L1I cache so it's (mop cache) get filled , and stuff just seating around [Does AMD have this thing intel have where they have two execution pipelines one [faster] from mop cache and one from L1I cache? ]. That's assuming the decoders are fast enough. For evidence, they did double the Mop cache.

2. if the decoders aren't fast enough , the L1 cache could be waiting for instructions to be decode while taking up place where needed? (let's say more mop cache)

So my questions =

1.If 1 is true , wouldn't it be better for instructions to wait in L1 to save L2 fething time? I guess it is but the trade off smaller mop cache isn't worth it considering power/silicon constraints.

2.The decoders should be really fast as they have to fill Mop cache fast enough and still dill with branches/long instructions and such. Does it mean the BPU should have the lowest latency , then decoders and then cache ?

3. The reorder buffer before the back-end is basically there to 'hide' front end latency? [or back-end execution latency so the from end would not stop?]


Cheers.

 

[naukkis]

It's about associativity. When they increased MOP-cache 4 way associative L1i cache hit rate probably get bigger conflict rate(from there's already 4 similar addresses in MOP cache) and worse hit rates so they did double the associativity and reduce cache size to have same L1 access times and better hit rate.

 

[naukkis]

Other explanation might be side-channel vulnerabilities. Zen L1 cache is virtually accessed via microtags and they do raise a exception when find that L1i microtags did not match physical tags, so they can prevent brute-force attacks. But that isn't 100% sure, so they might want to revert back to VIPT L1i cache to get physical tags checked faster.

 

[liad]

It's about associativity. When they increased MOP-cache 4 way associative L1i cache hit rate probably get bigger conflict rate(from there's already 4 similar addresses in MOP cache) and worse hit rates so they did double the associativity and reduce cache size to have same L1 access times and better hit rate.

Oh interesting. So making it 8 way associative will make it slower to search specific cache line because there are double the sets?
If so , how can you make the L1 bigger and keep same timing?

 

[liad]

Other explanation might be side-channel vulnerabilities. Zen L1 cache is virtually accessed via microtags and they do raise a exception when find that L1i microtags did not match physical tags, so they can prevent brute-force attacks. But that isn't 100% sure, so they might want to revert back to VIPT L1i cache to get physical tags checked faster.

"tags each cacheline with the linear address that was used to access the cacheline initially " from amd documentation.

If I understand correctly- the l1i is virtually accessed via a micro-tag that generate when needed [where? mop miss?] then it gets checked via the physical tag on the l1 itself to prevent unwanted access to cache.

Who can access l1i? Is only when instructions need to be decoded? Does the branch predictor results are fetched to l1i?

BTW thank a lot! Still learning about this kind of stuff.