Infineon Extended I/O (x16) 1.8V Hyperram - FBGA 49-ball - Now Sampling (Datasheet and a Surprise!)
Yanomani
Posts: 1,524
Found it yesterday, afterhours, just when my eyes were urgeing me: it was bed time...
As posted on May 04,2022, the following blog entry...
... led me to the following datasheet...
Everything seemed utterly normal (CK/CK#, two RWDS [1:0], and so on) untill I started perusing the Read and Write transactions, as depicted at figures 1, 2 and 3, then hit "3 Signal description", on page 9 of 48...
Holly Hacker's Mother Dearing!!!
(Verbatim, from datasheet):
"Data Input/Output. DQ[7:0] to transmit command and address during command/address (CA) period and lower byte of 16-bit data word during read and write transactions. DQ[15:8] to transmit upper byte of 16-bit data word during read and write transactions. Host has to drive DQ[15:8] all to “H” or “L” during the CA period. Floating is not allowed."
IOW, CA-phase is exactly the same as x8 Hypers; DQ[15:8] isn't used, even when writing to the internal configuration registers!!!
They'll sure are used during internal configuration register reads, and all data I/O transactions, whose destiny/source is within main memory array.
Food for thought...
Comments
Keeping the DQ[15:8] fixed during CA phase probably makes interworking with the prior 8 bit systems easier. My own driver code for example could keep doing what it does and would just change the streamer bus width to 16 bits during the data phase. Probably not too hard a change, apart from extra RWDS logic. Pity it's only 1.8V not 3.3V. Only adds two more pins vs 16 bit PSRAM if you use a single ended clock, but could theoretically double the performance offered.
My first toughts were targeted towards your exccellent work...
And then another image comes to mind (related to your previous work): "seesaw-alike"-accesses, using two Cog/Streamers (synced), transfering 2x16-bits from/to a pair of independent Hub-residing buffers: dealing with odd/even pixels (for those Analog Devices/Texas Instruments controllers) just a snap...
In the past years, much has been said about adjusting CK (and CK#) towards the center of data eye window...
Nowadays, there are many more ways of dealing with mono/bidirectional voltage translation between 3.3 V and 1.8 V.
Perhaps a good revisit on all of that, and understanding that delaying the intrinsicly bidirectional data and RWDS lanes even more than the ways it was thought before, while keeping the monodirectional translation of clock(s) as fast as possible, could be the way of achieving the desired centering/phase alignment.
Conceptually, the "next" clock could be exactly what is needed, so let data pass slowlly, and "shoot" them with faster clocks, "right between the eyes"...