By: juanrga (nospam.delete@this.juanrga.com), November 3, 2015 3:42 am
Room: Moderated Discussions
Matthias Waldhauer (M.Waldhauer.delete@this.youknowwhattodo.gmx.de) on November 2, 2015 1:26 pm wrote:
> juanrga (nospam.delete@this.juanrga.com) on October 31, 2015 6:20 am wrote:
> > I will try again to explain my argument.
> >
> > Skybridge was AMD project for pin and inside compatibility between ARM and x86 products. Pin
> > compatibility would produce a socket compatible for both the ARM and the x86 SoCs from AMD.
> >
> > Inside compatibility would produce a set of ARM and x86 cores easily interchangeable
> > inside the SoC for simplifying AMD business (specially the semicustom division).
> > You can get the concept on this diagram applied to 'small' cores
> >
> > Same about 'big' cores, indeed Zen was presented as the "sister core" of K12.
> >
> > AMD couldn't release a K12 core with 128bit SIMD units and a Zen core with 256bit SIMD units
> > within the Skybridge project, because that hypothetical Zen would require wider datapaths,
> > wider memory units, higher cache throughput,... ruining the lego-like replacement.
> >
> > But Skybridge was finally canceled. Thus maybe the reason for Zen
> > having 128bit units is some of those other reasons mentioned above.
>
> There are two ways to bend this:
>
> 1. As (likely) Hiroshige Goto's picture has shown, the cores would have been replaced in compute
> units of n cores, 4 in these 2 examples. Nobody said that a Zen based compute unit needs to contain
> 4 cores (8 threads). It could also just contain 2 Zen cores (like one XV module), this time supporting
> 4 threads, which is the same number as on 4 K12 cores. (just as an example)
Skybridge compatibility was defined at core level, not at "compute unit" level.
> 2. The "inside" part could go even further - by using microarchitectural components below the L2 cache
> level, for example by creating a uop representation, which has room to support both involved ISAs and
> their specialities (flag handling, reg numbers, etc.). Or at least components like a L1 cache or a branch
> prediction might be reused. This is only an option, if taken care of from the beginning.
>
> Matt
> juanrga (nospam.delete@this.juanrga.com) on October 31, 2015 6:20 am wrote:
> > I will try again to explain my argument.
> >
> > Skybridge was AMD project for pin and inside compatibility between ARM and x86 products. Pin
> > compatibility would produce a socket compatible for both the ARM and the x86 SoCs from AMD.
> >
> > Inside compatibility would produce a set of ARM and x86 cores easily interchangeable
> > inside the SoC for simplifying AMD business (specially the semicustom division).
> > You can get the concept on this diagram applied to 'small' cores
> >
> > Same about 'big' cores, indeed Zen was presented as the "sister core" of K12.
> >
> > AMD couldn't release a K12 core with 128bit SIMD units and a Zen core with 256bit SIMD units
> > within the Skybridge project, because that hypothetical Zen would require wider datapaths,
> > wider memory units, higher cache throughput,... ruining the lego-like replacement.
> >
> > But Skybridge was finally canceled. Thus maybe the reason for Zen
> > having 128bit units is some of those other reasons mentioned above.
>
> There are two ways to bend this:
>
> 1. As (likely) Hiroshige Goto's picture has shown, the cores would have been replaced in compute
> units of n cores, 4 in these 2 examples. Nobody said that a Zen based compute unit needs to contain
> 4 cores (8 threads). It could also just contain 2 Zen cores (like one XV module), this time supporting
> 4 threads, which is the same number as on 4 K12 cores. (just as an example)
Skybridge compatibility was defined at core level, not at "compute unit" level.
> 2. The "inside" part could go even further - by using microarchitectural components below the L2 cache
> level, for example by creating a uop representation, which has room to support both involved ISAs and
> their specialities (flag handling, reg numbers, etc.). Or at least components like a L1 cache or a branch
> prediction might be reused. This is only an option, if taken care of from the beginning.
>
> Matt
