In Hyper-V what happens when I "delete saved state" of one Remote PC; Would I lose the data in that Remote PC? Because I have tried to increase the RAM but it didn't work.Show Less
I'm using this part in my design S70KL1283GABHB020.
Could you please share design guidelines, reference schematic, and simulation model for this part?Show Less
We are looking for a way to integrate external RAM (possibly as large as 16MB) in our Project. Right now, we can only use Quad-SPI to connect the RAM-IC to our µC.
After looking at the Datasheets for the S27-Series, I haven't found a possibility to set the ICs up for a Quad-I/O-Mode.
Can you confirm that, or is there a way that i have overlooked?
The Exelon F-RAMs seem to be compatible with QSPI, though the Memory Density is not as large as we might need it.
Is there another product, that we could use?
Thank you and regards,
I asked the same question under HyperFlash board; however, this applies to the HyperRAM too since they follow the HyperBus timing specification all together.
Here is the link to the question: (Please review it, I'm not pasting it here to not to duplicate)
For the CLK, DQ and RWDS timings, it seems like the datasheet values are valid only up to ~65 MHz, although it is specified up to 133 MHz. Delay values and the valid areas of given signals doesn't add up and there seems to be a mismatch.
Has anyone ever tried to design the interface themselves or debugged the interface above ~65 MHz (CLK)? I'd like to see the DQs and RWDS signals (measured) above these clock frequencies.
Thank you.Show Less
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?