Recent discussions
Hi,
we are using two S27KS0642 as ping-pong buffers for a USB3 application (commercial temperature)
We will be driving them to their performance limits (so the full 3.2Gbit/s).
In order to achieve the maximum performance and reduce complexity we would like to violate the Tcsm.
(I understand, that this should be possible as long as we ensure the refresh of all cells)
Our major scenario will be the following:
1. Write the complete memory
2. Read the complete memory within 40ms maximum
3. (Possibly) read the complete memory again within 40ms maximum
As far as I understand the behavior of the memory it should be fine to violate Tcsm as long as we ensure, that the complete memory is read/written within 64ms.
Am I correct with that assumption or are there any problems to expect?
We have a second scenario (USB2.0/1.0 fallback) that will be:
1. Write the complete memory (ignoring Tcsm)
2. Read the complete memory in smaller junks honoring Tcsm
I would assume, that writing the complete memory will cause a complete refresh and that afterwards the self refresh operation will start running as before?
Best regards
Bernhard Wörndl-Aichriedler
Hello,
We are using the STM32L4R5 (Nucleo-144, L4R5ZI-P) to implement HyperRAM memory (S27KL0642) under hyperbus protocol. There is a problem between OCTOSPI and serial communication. Sometimes, when the OCTOSPI is being activated the serial port doesn't work.
Any help will be appreciated.
Show Less
We are using a Cypress/Infineon HyperRAM, part number S70KS1281DPBHV020, driven by the Cypress/Infineon Hyperbus Controller on a Xilinx FPGA (xc7k160t-2ffg676) at 100 MHz. On said FPGA is also a soft-microcontroller (MicroBlaze) that uses the HyperRAM as instruction memory.
We have issues with erratic behaviour of the MicroBlaze after some time passes, usually several days. When we read back the processor’s instruction memory we see that entire blocks have been corrupted. We see that the corrupt blocks are 1024 bytes in size and are located at offsets of 1024 bytes as well. According to the HyperRAM component’s datasheet, the RAM is organized in 16384 rows of 1024 bytes. It appears that the corrupt memory blocks all contain the same data after the fact.
We have ensured that no write access has taken place to the instruction memory, so it must have changed spontaneously. We have also verified that we do not violate the RAM's tCMS and are also providing additonal latency for refresh cycles with every single access. As far as we know, the FPGA drives the HyperRAM according to specifications.
We have reviewed our schematics and have noticed a few issues that however don't seem to be very critical:Schematics
- We have added pull up resistors on the pins A2 (RSTO#) and A5 (INT#), which are marked as “RFU” in the HyperRAM datasheet. In the FPGA, they are unused so there is a weak pull-down (10-40k if I’m not mistaken) by default. In the Documentation of the Infineon/Cypress/Spansion HyperBus Controller, I found the following passage regarding the INT and RSTO pins, which might be the reason we have added those:
- On the A4 pin (RESET#), we have a pull down resistor, but in the datasheet, Cypress/Infineon indicates that there is an internal weak pull up resistor in the HyperRAM. During normal operation, this signal is driven by the FPGA, however.
- The B5/C5 pins (PCS/PCS#) are RFU in the datasheet as well but are unconnected in the FPGA, which means there is a weak pulldown there as well.
- The C2 pin (CS1) is RFU in the datasheet but driven high by the FPGA.
- We have also noticed that our Power Delivery trace widths are 11.8 mils wide, which is below the recommended 20 mils in the Design Guide you’ve sent.
We are driving the CK/CK# as two phase-shifted clocks, not through a differential buffer as the schematics might suggest. The schematics also show an ISSI HyperRAM part, but we are experiencing the exact same issue with that one.
What could be the cause of this?
Show LessレジスタをRDする際にデーターシートではレイテンシなしと理解したのですが、
シミュレーションモデルではレイテンシがあるようです。
ここの仕様はどのようになっているのでしょうか?
Hi,
I'm trying to implement Hyperbus protocol for Hyper RAM on a NUCLEOL4R5ZI-P without success. Is some exemple on STM32L4R are available?
Kind regards
Show LessHello
I'd like to check and use for my test board using hyperRAM solution.
Can I get full datasheet of S71KS512SC and S27KS1281DPBHA02?
Thank you
Show LessHi,
I am testing the S27KS0642GABHI020 on our board with Lattice crosslink-NX FPGA. I have 2 hyperbus controllers to use, one is the cypress hyperbus 2.0 controller and the other is a much simpler one from Lattice. I firstly tried the one from Lattice, I found no matter what I wrote into address 0 I always read back random data, even I didn't write. To avoid the wrong initial latency issue, I looked at the incoming data waveform from Lattice Radiant Reveal logic analyzer, they are always random data (mostly 8'h15). I also probed pins with scope to confirm data is coming from HyperRam. HyperRAM is running at 60MHz, but I also tried as low as 24MHz or higher at 120MHz, all similar results on reading.
What should I check? I also tried manual reset for Hyperram after power up.
Thanks,
Yuecheng
Show LessCan someone please direct me as to where I can find an .ibis model for the S27KL0641DABHI020. I would like to simulate the design I am working on that includes this IC as the memory component.
Show LessHi,
In order to communicate with the memory Hyper RAM S27KL0642 I use a NUCLEO-L4R5ZI board.
My problem is that the frequency that can be generated by the MCU is 120MHz and in the datasheet of the memory componment's operation is only detailled for two frequencies (200 and 166MHz).
My question is, does the memory would properly work at 120MHz frequency? If so, are timing specifications the same?
Kind regards
Show LessWe are considering incorporating the Hyper-RAM S27KS0642GABHV020 (and later the 128-Mbit counterpart) as the DRAM solution in our upcoming product design. The IC will be clocked at 150 MHz. In each transaction, we would like to store/read data in 1024 KB chunks, using Linear Burst Mode (essentially each transaction will read/write a row). Beside the Tcsm limitation, which limits each transaction to 600 cycles when using 150 MHz clock, is there a limit to the number of bytes that can be read or written in a transaction when using Linear Burst Mode? Is our use-case, which requires 527 cycles and respects Tcsm, viable?
Kind regards,
DM_Y