SDRAM without HPS

---

@HTolentino wrote:

Hello thank you for the reply,

just to clarify, the agent you mentioned is the SDRAM controller IP right?

Yes.

In Platform designer I instantiated the SDRAM controller with the PLL.

This block design is called RAMSYS.

At the moment, RAMSYS has SDRAM wait request as the output port.

In my top level design (host), I connected this output to an interconnect which I used to determine if I can proceed with reading or writing.

I undestand wait request behaves a certain way based on the inputs of the controller .

It also seems it is dependent on some timing based on the figure before.

The interconnect I referred to is the interconnect automatically generated by Platform Designer. I'm not sure what interconnect you are referring to here. And again, waitrequest is not timing based. It's based on logic. When the agent cannot currently accept commands (arbitration is a common cause), depending on the design, either the interconnect or the agent (if it has manual waitrequest control with an output signal) holds waitrequest high as long as necessary.

My confusion is that the clock cycle difference from read and write are different.

Even though write cycle provided the necessary inputs (data/address/read enable), same as the read cycle,

it still deasserts wait request longer than write.

Again, that's an illustrative waveform. It's not showing the exact number of cycles for things to happen.

If it is indeed based on some sort of timing, can I assume it would be some static timing based if the inputs arrive at the same clock cycle?

Again, no. The assertion of waitrequest is not timing based.

I realized that my host (state machine code) depends on the wait request while the agent (SDRAM controller) depends on the inputs from the host.

I confused myself even further as it looks this looks like a feedback loop.

At the end of the day, I really dont know whos really reponsible for wait request.

The interconnect or agent is responsible for the generation of waitrequest. The host (your design in this case) is responsible for interpreting waitrequest as an input signal and holding your output control signals steady as long as waitrequest is held high. (i.e. "if waitrequest=1 on this clock cycle, hold outputs at current value until after the first clock cycle where waitrequest is released; that's the cycle the transfer takes place)

I understand you made a note on this ...

"

When the host sees waitrequest, logic in the host would know to continue asserting the control signals.

waitrequest can be any length needed. It doesn't matter whether it's a read or a write. It's up to whatever is controlling it, the interconnect or the agent. Again, the waveform is illustrative to explain how the signaling works, not how every design must work.

"

In bold you note that the wait request is controlled by the agent and the one controlling it...isnt the one controlling it the host?.

Again, either the agent can control waitrequest manually or if it does not have a waitrequest output, the interconnect can generate and sent waitrequest to the host as needed.

OVerall it seems like I am going backwards as I dont even know which really controls who.

I will continue reading on it and I understand if this question is off tangent the original problem.

Thank you.

-htolentino

---