However, after going to terasic and downloading DE1_SoC_SDRAM_RTL_Test on the DE1_SOC system CD I found it difficult to understand.
First, I mainly code in VHDL so I have a hard time translating the verilog example.
Next, there are a lot of attached components which I assume is part of the debugging process.
Is there a simple way to confirm reading and writing in SDRAM with a simple wrapper code?
I just assume that controller from the platform designer deal with all the nitty gritty and the "conduit" wires deal with the controller interacting with the SDRAM.
1) Is there going to be complex timing I have to consider in order to read and write from SDRAM?
2) How can we verify that it is working, I tried using signal tap but there are so many weird signals; and signals I want such as counters are not in the list. Also ISSP seems kind of too simplistic.
The code I have is simple, I have the platform designer component wrapped as "ramsys" and I just have a top level design called SDRAM.
In the top level, I simply toggled the Read and write enable by a counter. Likewise, the address follows a counter.
Note: I just have a random FF because I was messing with it to see if the signal can appear in signaltap.
You don't cover in your code if waitrequest is high. You have to continue holding the address and control signals when this happens. It might be easier to make use of some off the shelf component in Platform Designer instead of exporting the interface and coding your own Avalon host to communicate with the SDRAM. Maybe a FIFO or something from the IP Catalog.
For Signal Tap, use the pre-synthesis Signal Tap filter when tapping nodes. That way you'll recognize the signals from the code instead of the changed names you'll see if you use the post-fit filter.
Also, I presume you have a .sdc file with timing constraints and that you made pin assignments correctly in the Pin Planner.
Hello. I apologize for the late reply. At the moment @sstrell was right about the sdc and and my lack of pin assignment. I was finally able to see the signals i wanted in signal tap after putting in pre synthesis.
Currently I am able to see some sort of correct semblance on the waveform but for some reason it is not quite right.
I am certain it is my finite state machine code or something but I am still trying to find the problem functionally.
I wanted to see if I can get the waveform right before posting it.
I think my next problem is regarding SDRAM wait request.
I coded it the address/data to latch when it is high and only change the data/address when it is low as suggested,.
On the other hand I cant predict when SDRAM will be high or not.
Is this something completely random or is there some kind of timing it follows so we can predict when SDRAM wait request will be low.
At the moment, I see this SDRAM wait request as some annoying enable signal. I wonder if this is completely natural in the memory interface.
Is it alright if I can work on it a bit longer before following up?
Squiggly lines: as long as waitrequest is held high, the other signals must be held. This is showing that it could be multiple cycles before waitrequest is released.
Host is whatever system component is issuing read or write commands (previously referred to as a master). Agent (previously a slave) responds to commands by either storing data on a write or replying with data on a read.
For external memory, you have an IP that responds to read/write commands on the Avalon interface that is an intermediary to the external memory. That is the agent, not the external memory.
The waveforms are generic read and write transfers to understand the signaling on an Avalon interface. It doesn't matter if read or write occurs first.
cycle 1: The interconnect asserts waitrequest (often due to arbitration due to multiple hosts accessing a single agent at the same time), unless the agent includes a waitrequest output signal for manual control of waitrequest. So the note below the waveform indicates that the agent, in this case, is manually asserting waitrequest.
cycle 2: it's not a latching. 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.
just to clarify, the agent you mentioned is the SDRAM controller IP right?
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.
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.
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?
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.
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?.
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.
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.
I am closing the thread for now. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.
New Contributor
