So the L0 cache that appeared in other slides really is micro-op cache after all, and its functionality resembles the same micro-op cache as Intel has been using since Haswell.
I am drawing a blank on slides for an L0 cache for Zen.
Historically, I've seen more about an L0 operand cache or stack cache--which is the wrong cache type for where the only L0 reference is listed.
As an Icache TLB, the L0 TLB might not be tied to a cache AMD calls an L0, since TLBs in prior CPUs have multiple levels hanging off of the L1.
It might be a micro-TLB used for way prediction or reducing the number times the core needs to check tags. That's where I've seen mentions of the term "microtag" that showed up in the expanded error reporting.
That might also be expanded to serve as a uop-cache hit check, if it shares Intel's constraint that the uop cache map to the L1.
The oddity with the FMA FP0+FP3 FP1+FP3 pipe sharing was dropped, although why it was mentioned in the first place is curious. It seems elaborate for a typo.
If FP0 and FP1 are FMA pipes, it might explain why IADD is possible on them as well as FP3.
I tried looking up the context of the error reporting for shadow tag ECC errors. At least one instance I found it mentioned was a paper on non-uniform cache allocations, where shadow tags are used to determine which cores' workloads would benefit most from expanding the "local" allocation given to them from a last-level cache. That leads to lower latency within the local partition and not having to check across all the tags in the common case.
The error reporting for multi-way hits in the L3 and L2 is something I am not familiar enough about to know if this is something peculiar to a segmented L3, or a possible transient state in the long memory pipeline that could happen but has not been subject to reporting.
The error-reporting and checkpointing functionality in general seems to tie into Zen's server focus. The error reporting is something that is either not going to be in all new CPUs, or something that can be toggled.