Question about DMA setup time modeling

[daecheolyou]

In the datapath, there is DMA setup time modeling, which delays the DMA transaction considering CPU cache flush or invalidation latency. However, to my knowledge, directory controller of MESI_Two_Level protocol sends an invalidate signal to the line owner when it receives DMA read or write request for the line in modified state (transition(M, DMA_READ, M_DRD) or transition(M, DMA_WRITE, M_DWR) in dir.sm). I think CPU cache flush/invalidation latency is duplicated if ignore_cache_flush is set to false. What do you think about it?

[yaoyuannnn]

The DMA setup time was added to mode the setup phase of the DMA controller, which was validated against a Zynq Zedboard. I think we have a pipelined_dma parameter to pipeline this across multiple DMA requests. But this latency is different from the CPU cache flush and invalidation latencies, which were added to model incorrect DMA behaviors. I agree that since the MESI_Two_Level protocol models a coherent DMA controller, these are not really needed.

[xyzsam]

To add to what Yuan explained, this was added very early in gem5-Aladdin history, long before we had a dedicated ruby model for coherency (which Yuan added). It exists purely as a relic of the past, and we should probably remove it to simplify the code considerably.