09-28-2016 01:29 AM
When I use the example design created by the ip catalog. During simulation, I can see the following:
app_wdf_rdy is 1 about 70% of the time. app_rdy is 1 about 50% of the time. This means data fifo fills up faster than the cmd/addr fifo. This is a good news though. The only condition given in UG586 is that for a given addr/cmd, the associated data can appear no later than 2 clock cycles.
The example design uses this strategy. It first lets the data fifo fill up for 64 data. Then app_wr_en deasserts, and filling up data fifo stops. The addr fifo continues to fill up as it fills up slower. When the addr has filled up 64 addr/cmd's. app_en deasserts as well. Now we can ensure that both fifos have 64 elements, which associates with each other across fifos.
When I first created the MIG controller. I didn't take into account waiting for the addr/cmd fifo, which could cause an error that some data don't have their corresponding addr.
However, when you select this waiting limit too small. Lets put it to extreme, 1. That is to say I won't write a second data until I have written the addr of the first data. This could be extremely low and the fifos become meaningless here.
So what could be an optimal waiting limit? What kind of factors decide this?
09-28-2016 02:37 AM
09-28-2016 04:02 AM
app_wdf_data data can be pushed even before app_cmd "write command" is asserted. The only condition is that for every app_cmd "write command," the associated app_wdf_data "write data" must be present.
You need not wait for first data to be written to data FIFO to send the second command.