Xilinx Series 7 Memory Controller - "app_wdf_rdy" signal

[shaiko]

Hello,

From page 92 of the following document:
https://www.xilinx.com/support/documentation/ip_documentation/ug586_7Series_MIS.pdf

The write data is registered in the write FIFO when app_wdf_wren is asserted and
app_wdf_rdy is high (Figure 1-48). If app_wdf_rdy is deasserted, the user logic needs to
hold app_wdf_wren and app_wdf_end high along with the valid app_wdf_data value
until app_wdf_rdy is asserted. The app_wdf_mask signal can be used to mask out the
bytes to write to external memory.

What if the user's application asserts the "app_wdf_wren" to the controller, while the controller (at the same cycle) de-aasserts "app_wdf_rdy" ?
Assuming synchrnous logic - "app_wdf_rdy" will be sampled by the user only at the next clock edge and the data won't be written to the controller's Tx FIFO.
Do you agree ?

 

[Tetik]

You are right.

Usually, with this kind of interface, the slave interface is allowed to assert and deassert the ready signal anytime. The master must asserts the enable signal regardless the state of the ready signal. However, once the enable signal is asserted the master must not deassert the enable until ready signal is asserted. The transaction is valid when both signals are asserted.

You can read the AXI specification. It gives a good explanation of this mechanism.

 

[shaiko]

Thanks,

One more thing.
Page 93 - figure 1-49.
Do you understand why "app_en" goes low when the other control signals are still valid ?

 

[vGoodtimes]

"When issuing back-to-back write commands, there is no maximum delay between the write data and the associated back-to-back write command, as shown in Figure 1-49."

In the diagram, the data for the next write is buffered but the command is not issued. The next write will use this data. The point is that you can pre-write data by as much as you want. (assuming the fifo doesn't overflow.)

 

[kommu4946]

Hi,

I have doubt on non back-to -back write command,in page no 92 diagram it is specified that maximum allowed delay from address to command is two clock cycles,in the third case app_wdf_wr_en is asserted after(two clock cycles) de-asserting command signal,still it has shown that new data is written.Is that data is written to fifo or it is written to memory location specified during command assertion. I understood first and second case in the diagram based on your explanation.

Regards

 

[shaiko]

What about very long waits between asserting app_wdf_wren and app_en?

I.E: The datasheet mentions that the data mustn't be address more then 2 clocks after app_en - but what about the opposite ?
Can we write data to the controller and assert app_en many clocks after?

 

[dpaul]

I.E: The datasheet mentions that the data mustn't be address more then 2 clocks after app_en - but what about the opposite ?

I didn't understand what you meant by - but what about the opposite ?
UG586 in Pg163 says with respect to the CMD, data can come in delayaled to a maximum of 2 clock cycles. Data may also come 1 clk cycle earlier to the corresponding CMD.

Can we write data to the controller and assert app_en many clocks after?

I don't think so!

I wouldn't connect the Xil MIG to a design that violates what is mentioned in the spec.

btw- Are you using the Xiling traffic gen or have designed your custom traffic gen for the Xilinx MIG?

 

[shaiko]

I don't think so!
I wouldn't connect the Xil MIG to a design that violates what is mentioned in the spec.

That's exactly my point - I don't see the spec mentioning that.
In page 92 - The spec explicitly forbids asserting the data more then 2 cycles after app_en.
But it doesn't say anything about the opposite - I.E asserting app_en more then 2 (or any number of) cycles after data has been written.

btw- Are you using the Xiling traffic gen or have designed your custom traffic gen for the Xilinx MIG?

Custom.
Can you post a link to the datasheet of the traffic gen you're referring to?

 

[dpaul]

Can you post a link to the datasheet of the traffic gen you're referring to?

There isn't anything other than the ug586.

Note that what shown in Pg163, is only for *non back-to-back write command*.
And as per my understanding, the write data can come in 1 clk before the CMD has been registered or upto 2 clk cycles after the CMD has been registered. Anything else would be an invalid scenario for non back-to-back.

Basically I am also working on a custom traffic gen and up to now what it does is a huge chunk of back-to-back write, then back-to-back read, then again back-to-back write, then again back-to-back read and then end up in an IDLE state, doing nothing. My state-machine just holds the CMD and WRITE_DATA until the handshaking signals are asserted by the MIG. Then it moves on to the nxt CMD and so on.

 

[vGoodtimes]

--edit:

"A non back-to-back write command can be issued as shown in Figure 1-47. This figure
depicts three scenarios for the app_wdf_data, app_wdf_wren, and app_wdf_end
signals, as follows:
1. Write data is presented along with the corresponding write command (second half of
BL8).
2. Write data is presented before the corresponding write command.
3. Write data is presented after the corresponding write command, but should not exceed
the limitation of two clock cycles.
"

case 2 is the relevant one.

 

[shaiko]

case 2 is the relevant one.

Correct,
It's just an example of data being written before issuing app_en.
Nowhere the datasheet mentions that we can't write as much data as we want and wait as much cycles as we want before issuing app_en's for that data.

What do you think?

 

[vGoodtimes]

Re: Xilinx Series 7 Memory Controller - "app_wdf_rdy" signal

You still need to respect the wdf rdy signal. I don't think the fifos on the newer controllers are all that deep.

It is also problematic if multiple cores ever share the ram.

Otherwise it appears fine.

- - - Updated - - -

You still need to respect the wdf rdy signal. I don't think the fifos on the newer controllers are all that deep.

It is also problematic if multiple cores ever share the ram.

Otherwise it appears fine.