Hi Dan,
> > You need to be more clear with your terms. Only the 60x core > "uses" the cache. The CPM is a DMA device that can utilize > cache coherency protocols if you enable that with the GBL flags. > Ah, I see. If the CPM DMA is configured to "snoop" the cache then that doesn't mean it "uses" the cache - it just tells the cache when data needs to flush - namely before DMA writes. > > I have seen this causing problems. When I map a VPI/VCI to a > > connection > > table using the address compression table, > > Where are you placing the VP-level and VC-level tables? I assume > you are properly configuring the GMODE to indicate their locations? > Does it work properly if the tables are in DP RAM? > I've got the VP-level tables in DPRAM (as recommended by the UM) and the VC-level tables in external memory (as required by UM). The EVPT bit in GMODE is cleared to indicate VP tables in DPRAM. The first few cells received after writing the mapping are definitely going to the raw cell queue. This doesn't happen if I flush the cache line following core writes to the VC-level table. This suggests to me that the CPM DMA is not employing the cache coherency protocol when accessing the address compression tables. This is not a surprise since the UM only claims to be able to do "snooping" for buffers, BDs, and interrupt tables. > > With external connection tables the problem is more severe. > > There are some very subtle assumptions made by the ATM > controller regarding all channel data structures. There aren't > configuration location flags for every level of table, and assumptions > are made that tables for a connection are either internal or > external. Be careful with that. I either entirely use DP RAM for > everything or external memory for everything, which seemed > to work for me in the past. Maybe I was just lucky :-) The UM definitely claims you can have a mixture of internal channels and external channels. If you want a lot of simultaneous channels open you are forced to use both since the number of internal channels is limited by (a) the amount of DPRAM available, and (b) the design limit of 256. > > > .... During > > frame transmission, the core is constantly having to read and write > > to the Transmit Connection Table in order to use Auto-VC-ofF. I > > couldn't get this to work until I added lots of > > "invalidate_dcache_range" and"flush_dcache_range" calls. > > Are you sure this is really a cache problem and not a race condition > with CPM access to the CTs? The CPM does atomic burst read/write > of the RCT/TCT entries, and buy doing cache flush operations, the > 60x core does the same. > Well it looks to me that for address compression tables and external connection tables the CPM DMA is not employing it's cache coherency mechanisms. This mechanism probably just boils down to the CPM saying to the cache "I want to write to ptr, please flush any pending writes then invalidate the line". By adding calls to flush/invalidate_dcache_range in my code I am doing the cache coherency mechanism in software instead. It would be a lot easier though if I could just allocate uncached memory.... Thanks for your help, Alex
