Hey Erman!
I see you have a lot of questions, which is great. I'll try to answer what I can and as many as I can for you in a concise manner because the QMSS is a common IP and has a lot of stuff going on.
"First of all, I am assuming all the cores (DSPs and ARMs) run asymmetric" I'm going to say every one's favorite answer of "it depends". It's all about how you configure it. The most common configuration is to have a master and multiple slaves. A lot of users prefer Core DSP0 the master, and the DSPs and ARMs as slaves. You can run the ARM as a master, or just the DSPs. Etc. There's also a process where you have no masters and a sort of "assembly" or pass it on. This is usually in signal filters where Core 0 does x to the data, and sends it to Core 1 to do x, etc. If you want more info try the CorePac User Guide.
"1) Is it possible to use Multicore Navigator for a complete infrastucture communication in a complete asymmetric system? If yes, I understand that we need to use QMSS TX queues and accumulation queues for the inter-processor communication (ARM <-> ARM, ARM <-> DSP, DSP <-> DSP). So what about inter-process communication? Which queues can we use for TX and RX sides?" I have personally never seen it done, but QMSS has a "fire and forget" system. Where you fire off the data and forget about it. If the receiving IP can't handle the data, it'll just stay in the TX queue until it's ready to go. It's purpose is to basically just let the CPU deal with the processing and have the QMSS be the "mover". So I don't think from the QMSS point of view if it matters. Because I know that XGE or VCP may be doing something simultaneously, and the QMSS doesn't care. It's just sort of a mail slot.
"2) What are the general-purpose queues used for? I mean, other queues cover all the usage area. I believe this may be related to the upper question, inter-process communication part." To quote the user guide "Any queue that is not used by the application for hardware purposes may be used as a general purpose queue". It's basically used for whatever you configure it for. They're pretty well, general. Whatever you need to use it for.
"Moreover, and also with high importance for us, we wonder if we can use more than one queues for this TX channel? For example we have five software blocks in ARM0, and we may want to use different queues for the blocks due to priority issues. So a TX channel with more than one TX queues, a RX channel with more than one RX queues (ports maybe in seperate cores) using RX flows? Is this possible?" From my understanding the QMSS doesn't care where the packet it's receiving in queue x is coming from unless it's a hardware specific queue and it's not from there (I.e. a NETCP queue doesn't get a packet from SRIO). That's why you might want to use the general purpose ones. You can configure it so that it receives it from your software blocks. I think that will solve your queue problem.
"4) Do you have a complete channel map? The PKTDMA channel map (Table 5-18) only shows the number of channels." You mean like table 5-1 for the queues? Not that I know of right now, but I'll see.
"5) In Table 5-9, the mapping of queues to high priority accumulation channels shows that the interrupts are only available to DSP cores. But we will require interrupts for the ARM cores too. Is this possible using high priority accumulation queues?" Well I think you expanded to ARM because you didn't have enough queues per core, which would solve this by rearrange the queues. However, if you're using ARM for processing, I think the way to do it is to map the arm interrupt to the queue interrupt signals.
"6) I have some unclear parts in the example code of the user guide:
- How (and where) is the RQ FDQs are related to the RX flow? How does the PKTDMA know which descriptor to pop when data arrives?" Descriptor order is taken care of by firmware, you don't have to worry. Same with your X FDQ question.
Ok, so you have a lot of really not "basic" but best shown by visuals questions. I'd suggest looking at the QMSS and PKTDMA videos/ppts here. They're really helpful:
http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=OLT110027
"7) It seems clear that we should have a centralized initialization point. But for seperate RX ports in seperate cores, some initializations may be required seperately. So, what if one of the cores should go to reset in the runtime? What kind of action should we take? Do you suggest a complete centralized initialization, with constant address values for other cores?" As long as the cores aren't depending on the data or process of the others, a reset shouldn't be a problem.
"8) My reference is for Dummies and user guide as I mentioned. Do you suggest any other documents, examples?" See the videos I posted above. Use the examples in the MCSDK software packet try it on another device if you can. Look at these videos: http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=OLT110048
Look at older forum posts. A lot of questions have been answered here. Here too: http://focus.ti.com/general/docs/traininghome.tsp
-Kat