AMD: Speculation, Rumors, and Discussion (Archive)

[Kaotik]

Apparently. The tech report did a handy job of tracing the rumor back to it's supposed source on the s|a forums.

http://techreport.com/news/30113/rumor-amd-may-pull-vega-gpu-forward-for-an-october-launch

My apologies if this has already been posted. Always tricky to determine what has been posted where.

Actually the original poster at 3DCenter claimed that the S|A post is not related to his source

edit: (I think, no time to double check right now)

 

[Deleted member 2197]

The news arrived through Nordic Hardware saying that AMD's partners "won't have any new cards to display at Computex and the only Polaris cards promoted to them from AMD are R9 390/390X performance class but for a mid-range price. Reports say Polaris 10 can't hit 850 MHz reliably, whereas Nvidia already demoed the 2000 MHz marker with their GPUs.

A board partner response seem to be "as of now, no information".

Rumor indicates that this info is backed by a rather large AMD partner, that there will be no Polaris-based video cards from AMD partners at Computex. That means no Polaris on Computex and no availability of the cards shortly thereafter (if this is true).

If true, man can AMD please catch a break ...

http://www.guru3d.com/news-story/polaris-validation-failed-might-launch-in-october-now.html

 

[3dilettante]

While I agree wrt to the physical dimensions and it's implications to the interposer, I have a hard time remembering any largely functional difference from the JEDEC spec for HBM. Yes, for HBM gen2 running at full specified speed, you would probably re-optimize your controllers. But what else? Most things in HBM gen2 seem not to require much different controllers. Some options might, yes.

There is a separate pseudo channel mode that is used to split accesses between sub-banks, and the revision added some features like an additional signal that is used to access the upper half of HBM2's maximum capacity. There are a few other features added that were not mentioned for the original revision like a required thermal trip and redundant lines for fault recovery, and there were some deletions like an unelaborated low-frequency mode.

 

[CarstenS]

Yeah, I'm aware of that - and am under the impression that some of them still are optional or only required if you want to use 8-hi stacks. But still - thx.

 

[kalelovil]

(OT)
Sigh, is this what counts as news nowadays? Gather together a bunch of forum posts and other rumor articles and then prefix them with "Reports say", without providing any references or attribution.
At least this Anandtech forum poster is doing a better job of it: http://forums.anandtech.com/showthread.php?p=38218522

 

[CSI PC]

Yeah, I'm aware of that - and am under the impression that some of them still are optional or only required if you want to use 8-hi stacks. But still - thx.

Yeah there is also a legacy mode with the controller, I am being very slow today doh.
I linked some of the partner details controller spec in the past, the controller is design-manufactured by NorthWest Logic.
Their controller was used for Fiji, and they are also involved with other HBM solutions.
Specifically:
Supports HBM Gen2 pseudochannel and Gen1 legacy modes
Delivered fully integrated and verified with 3rd party ASIC PHY
Supports all defined HBM channel densities, from 1 Gb to 8 Gb, including 8-high stack HBM
Customization and Integration services available

http://nwlogic.com/products/docs/HBM_Controller_Core.pdf
http://nwlogic.com/products/docs/Start_Your_HBM_Design_Today.pdf
Cheers

 

[CarstenS]

And this is the one presumed in Fiji?

 

[3dilettante]

And with GDDR5X it is even more of a fudge to most when considering actual and effective clocks, considering the clock speed is identical (at max spec) between quad and dual mode support for the 110 and 120 products; this is made more complicated with the 100 (10Gb/s memory) is rated to have a slightly higher clock speed in DDR over QDR mode, 1375 against 1250.
The difference is not the clocks (excluding what they do with the PLL inside the frame) but the Gbps/pin doubled for GDDR5X.
This is going by the operating frequency of the clocks in the Micron technical brief-spec.
CK_t,CK_c,Command,Address,WCK_t,WCK_c,EDC are identical in both modes, only the DQ and DBI_n double up in quad GDDR5X mode.

Cheers

Discussions about connections that move data at multiples of a base clock can use transfers rather than clocks. The width of the connection itself would need to be known to calculate actual bandwidth, but it simplifies comparisons between methods that can vary in how they handle data and clock relationships.

 

[3dilettante]

Yeah, I'm aware of that - and am under the impression that some of them still are optional or only required if you want to use 8-hi stacks. But still - thx.

Some of them, like a codified set of redundant signals and the thermal fail-safe are not considered optional. There is a row hammer countermeasure that requires some setup, although I forget at the moment if it is optional. Whether the existing HBM1 hardware already had some of these items and it was omitted from the draft is unclear.

 

[CSI PC]

And this is the one presumed in Fiji?

Yes I am sure.
And just to add it involved Hynix/Amkor/Northwest Logic/cannot remember 4th partner involved in the AMD solution, but Northwest Logic are the ones with the HBM controller IP and design.

Edit:
This should also help to confirm if in doubt, news was dated 2015 and states:

Northwest Logic’s HBM Controller Core supports both Gen 2 (2 Gbit/s/pin) and Gen 1 (1 Gbit/s/pin). The core supports a range of user interfaces and operational modes include Gen 2 pseudo-channel support. As part of this demonstration, Northwest Logic created a complete FPGA design including the HBM Controller Core and FPGA PHY and memory test support. This design provided error-free writes and reads to the HBM device.

“We are excited to collaborate with eSilicon and SK Hynix to show a fully working HBM demonstration,” commented Brian Daellenbach, president of Northwest Logic, Inc. “We are seeing increasing interest in HBM applications. This demonstration shows that eSilicon, Northwest Logic and SK Hynix have the capabilities needed to enable a customer to implement an HBM ASIC.”

http://www.design-reuse.com/news/38...logic-sk-hynix-high-bandwidth-memory-hbm.html
Cheers

 

[CSI PC]

Discussions about connections that move data at multiples of a base clock can use transfers rather than clocks. The width of the connection itself would need to be known to calculate actual bandwidth, but it simplifies comparisons between methods that can vary in how they handle data and clock relationships.

Sorry not quite following.
I am basing the info in same way I follow other information-transmission theory/data transmission protocol.
I appreciate there is a relationship between frame-data-signal-clock, but not sure what this has to do with the fact QDR and DDR use the exact same spec for framing and transmission, only difference is an additional PLL solution for adding additional data within the same frame.
As I mentioned, MIcron specify only DQ and DBI_n change with QDR (lets say comparing 5gbps DDR to 10gbps QDR as would be for the 100 product), with also the PLL also only active for QDR.

Cheers

 

[silent_guy]

Yes I am sure.

I find this very hard to believe.

And just to add it involved Hynix/Amkor/Northwest Logic/cannot remember 4th partner involved in the AMD solution, but Northwest Logic are the ones with the HBM controller IP and design.

eSilicon.

Why would somebody like AMD would partner with eSilicon. It's a fabless design house. I don't think they have anything to offer that AMD doesn't already have.
And companies like NW typically deliver general purpose IP. You'd think that a GPU memory controller needs to be much more specialized.

And then there's the thing where AMD has a IP sharing deal of some sort with Synopsys, which would be a direct competitor of NW.

I'm a sceptic.

 

[CSI PC]

Good grief, you really are going to make me work to prove Northwest Logic did the controller used by Hynix-AMD

Edit.
BTW I am sure AMD Fury is mentioned in the more general paper I linked a little while ago, but my point was that it was Hynix/Northwest/Amkor involved in the AMD HBM solution, and I also thought a 4th.

I provided that news link to show the Northwest Logic controller existed back then and compatible for HBM1 and 2 as per the more recent paper I linked before that.

Cheers

 

[3dilettante]

If the question is how to discuss GDDR5 versus GDDR5X, where using one of multiple clocks would lead to confusion, other discussions have instead relied on the number of operations that transfer data per second, which does not depend on referencing a clock.

https://en.wikipedia.org/wiki/Transfer_(computing)

The wiki articles on hypertransport and DDR4 use MT/s, and other articles like Realworldtech's CPU articles use MT/s or GT/s when discussing socket interconnects.

 

[3dilettante]

Can we rely on announcement dates to establish IP use?
The FPGA-based demonstration unit's announcement and the GPU launch are at the far end of two development pipelines and motivations.
The demo unit was trying to sell a packaged deal and pipeline to new HBM customers, which AMD wouldn't be new to.

The GPU had to have been locked down design-wise for some time and probably physically existed 1-2 quarters prior to launch.

 

[silent_guy]

Good grief, you really are going to make me work to prove Northwest Logic did the controller used by Hynix-AMD

Oh, no. If you say that you have unambiguous information (public or not) that this is the case, then I'll take you at your word. It's just that the public information that I've seen (and there's not a lot of it) is not sufficient to take this as fact. It all sounds very unlikely, that is all.

BTW I am sure AMD Fury is mentioned in the more general paper I linked a little while ago, but my point was that it was Hynix/Northwest/Amkor involved in the AMD HBM solution, and I also thought a 4th.

Hynix and Amkor are obviously heavily involved no matter what. It's not as if AMD invented the core technologies of HBM.

I'm only questioning NW and eSilicon.

There's definitely an audience for an HBM solution that is not AMD and Nvidia, and that audience will lack the necessary resources to do it in their own. So I always assumed that the eSilicon/NW/... cooperation was targeted at those.

 

[CSI PC]

It is not a multiple clock though when differentiating between them, from a GDDR5X frame-frequency spec though.
As an example the 120 product uses 1500Mhz clock for both QDR and DDR; giving either 6gbps or 12gbps.
What changes is the prefetch and data to the same frequency ratio.
Context being the matching DDR to QDR.
But yeah just present as Micron does, the Gb/s for each product 10/11/12, just gets messy as we are saying when talking about in terms of clocking and effective clocks comparing between the two formats where mistakes seem to happen with some publications.

Cheers

 

[CSI PC]

I would not associate NW same as eSilicon.
NW are the ones with the HBM controller that Hynix needs to use.

Edit, the 4th company may had been Avery (confused it with ASE that was used); when I mentioned Hynix/Amkor/NorthWest.
Those Northwest documents go back to 2014 as well, should had mentioned that earlier.
Cheers

 

[Razor1]

http://nwlogic.com/products/docs/Start_Your_HBM_Design_Today.pdf

 

[Oj0]

No, he hasn't.
His account is a little over a year old, and out of the blue he's claiming that he used to own a hardware website that supposedly brought those leaks, but is pretty much gone from the Internet (no google cache, no archive.org, nothing).
Quite convenient.
He also said that several websites would start breaking the news "a couple of hours" after his post... 10 hours ago.


He could be right and that would be rather depressing for AMD (although they never promised both GPUs for Summer), but that 1 year-old forum account isn't a reputable source at all.

Oj010 from OCN here. My site certainly does exist on Internet Archive, at least a good part of it. Here's a snapshot http://web.archive.org/web/20120214070741/http://flyingsuicide.net/