TMS320C6000 HPI

Camila Nunes said:

 I'm reading the TMS320C6000 host port interface (HPI) reference guide and I saw in the pag. 23: "HPI sends read request to the DMA" and I want to know more about this signal (how many bits it has, what the DMA makes with this signal), because in this reference guide it's impossible to find.

Would you be able to provide the specific literature number for the document you reference?  It would help steer the discussion.  Thank you.

The literature number is: spru578C.

I am so glad that you want to help me.

Thanks

[:D]

Thank you.  I forgot to ask which device you are targeting.

I am studying the TMS320C6000 DMA and I want to know more about the communication between DMA and HPI, but for this I need to know how the HPI sends the read request to the DMA.

Thanks

The particular device that you are targeting is helpful to understand the DMA architecture.  There are many devices in the C6000 family and the DMA architecture has evolved over time.  The most recent family members use the EDMA3 architecture, which is described in the device's corresponding user's guide.  I chose the TMS320C6455 EDMA as an example (SPRU966).

Earlier devices use and earlier version EDMA architecture which is documented in the TMS320C64x EDMA Architecture Guide (SPRA994).  There is a migration guide from EDMA v2 to EDMA v3 (SPRAAP4).

I realize there are many choices, which is why I was asking about which specific part number you were referencing.  I would suggest going to the Product Folder of that particular device and reviewing its User's Guides to get a better picture on how the EDMA and HPI work.

I'm sorry! I didn't understand what you're asking. The device is TMS320C6202 DMA. Could you answer the question based in this member of the family TMS320C6000? Realy sorry, Thanks

Camila Nunes said:

The device is TMS320C6202 DMA.

A document I would suggest using is the TMS320C620x/C670x DSP Program & Data Memory Controller/DMA Controller.  This will provide the high level architecture of the DMA and how it is hooked into the CPU memory system.

The DMA on the C6202B has four independent programmable channels, whereby you can setup transfers.  There is a unique set of registers for each of the 4 channels that will determine the behavior of the transfer.  For the HPI interface, the DMA has an auxillary channel (or 5th channel).  The only register in the DMA that is associated with the Auxillary channel is the AUXCTL, which determines the priority of the Auxillary channel.  The address context, size of transfer, etc. is maintained by the HPI peripheral itself, and not maintained by the DMA as it would be for the other 4 channels.

The HPI peripheral, which is described in SPRU578, maintains the address to be accessed in the DSP's memory by the HPIA register.  When a read or write operation is requested on the HPI physical interface to the DSP, the HPI peripheral will issue a transfer request through the DMA's auxillary channel.

I read this documents that you showed. My doubt is the read signal that HPI sends to DMA. It has how many bits? The DMA store this signal?? The signal will be sent with the address??
Please solve this to me, because in the document it was impossible to find this information.
thanks

Camila Nunes said:

My doubt is the read signal that HPI sends to DMA. It has how many bits? The DMA store this signal?? The signal will be sent with the address??

The HPI interface to the C6202B DMA engine is 32-bits wide.  While the HPI physical interface to an external host is 16-bits, the internal connection to the DSP's memory is 32-bits.  This is described on page 12 of SPRU578.
"The HPI provides 32-bit data to the CPU with an economical 16-bit external interface by automatically combining successive 16-bit transfers."

The address is contained in the HPIA register and the HPI peripheral sends a Transfer Request (TR) through the DMA Auxiliary Channel.  Therefore, yes, the "signal", which in this case is a Transfer Request (TR), contains an address into memory which is contained in the HPIA.

Ok...

then you said that (in another words): "the TR is the same of the content of HPIA". Is this???

If  it is all correct, how the DMA know that it has a read request??? It is good to remember that DMA does not have the PRICTL or SECCTL.

If the Auxiliary Channel has all of this registers, it is simple to know this channel is running...Look the START (at PRICTL). Understood my doubt? How to know that auxiliary channel is running???

I think that HPI send a signal (one bit) informing the DMA that it wants to transfer, after that HPI sends the address. In this way all will know that DMA auxiliary channel is running.

I hope you solve this problem...

Realy thanks and excuse the insistence

Camila Nunes said:

then you said that (in another words): "the TR is the same of the content of HPIA". Is this???

The transfer request will have the HPIA used as the source address for reads from DSP memory and the destination address for writes to DSP memory.  The transfer request will also contain information on the operation, ie. read or write.

Camila Nunes said:

If  it is all correct, how the DMA know that it has a read request???

The DMA module/controller will know that the Auxiliary channel has a request, but the Auxiliary channel handles the particular operation.  This information is maintained by the source peripheral, in this case the HPI.

Think of the Auxiliary channel as just another port into the arbitration logic.  The Auxiliary channel does not have context information like the other DMA channels 0 through 3, where there is a set of registers controlling and describing the transfer.  It is simply a way into the fabric to access memory.

Camila Nunes said:

It is good to remember that DMA does not have the PRICTL or SECCTL.

If the Auxiliary Channel has all of this registers, it is simple to know this channel is running...Look the START (at PRICTL). Understood my doubt?

The Auxiliary Channel only has the one register, AUXCTL, which specifies the priority of the Auxiliary channel relative to the other DMA channels (0 through 3) and the CPU requests.  Section 2.9.2 of the TMS320C620x/C670x DSP Program & Data Memory Controller/DMA Controller Ref. Guide (SPRU577) indicates the auxiliary channel provides address generation for the DMA.  To attempt to provide some clarification in distinguishing this feature, refer to Section 2.5 of the same document.  The DMA module/controller performs address computation for each read transfer and write transfer for each channel (ie. 0 through 3).  Unlike the Auxiliary channel, which is really getting the address information from the sourcing peripheral itself, in this case the HPI.  The HPI maintains this address generation logic, etc.

Camila Nunes said:

How to know that auxiliary channel is running???

I don't believe you do.  There isn't a status bit that indicates the Auxiliary channel is being used.  Your only indication is the external host sending an interrupt to the DSP after it has completed its set of operations through the HPIC register.

Camila Nunes said:

I think that HPI send a signal (one bit) informing the DMA that it wants to transfer, after that HPI sends the address. In this way all will know that DMA auxiliary channel is running.

The DMA module does receive a request from the HPI through the Auxiliary port.  Whether this is a single signal, or a request packet in some other architectures, is not really relevant.  The point is that, yes, the DMA receives a request from the Auxiliary port because it needs to arbitrate potentially between the Auxiliary port, the other DMA channels (0 through 3) and CPU accesses.  The AUXCTL register sets the priority of the Auxiliary channel relative to these other potential sources of requests.

If the Auxiliary Channel doesn't have START field, so it is always running, ok? Now consider this example:

All the DMA channels (0 through 3) are paused or stopped. In this case, the Auxliary Channel has the highest priority and it is running, right? Even the HPI doesn't want to transfer, the DMA will do the transfer, because the Auxiliary Channel is always running - it will read data that is not required. So, how the DMA controller will prevent this operation?

Pedro Lopes said:

If the Auxiliary Channel doesn't have START field, so it is always running, ok?

I would restate this as the Auxiliary Channel is always available, not running.  The only time it actuals runs, ie. performs a transfer, is when the HPI peripheral requests it.  The only time the HPI peripheral requests a transfer is when an external host is performing read and/or write transactions on the HPI interface.

Pedro Lopes said:

All the DMA channels (0 through 3) are paused or stopped. In this case, the Auxliary Channel has the highest priority and it is running, right?

The Auxiliary Channel is ready and has priority.  Perhaps my definition of running is different.  I would consider a channel running as it is in the state of actually performing transfers.

Pedro Lopes said:

Even the HPI doesn't want to transfer, the DMA will do the transfer, because the Auxiliary Channel is always running - it will read data that is not required. So, how the DMA controller will prevent this operation?

No, the DMA controller does not just generate read transfers.  It only performs transfers when a request from the HPI (which has all of the parameters of the transfer) is made.

For the other DMA channels (0 through 3), the DMA controller can be setup and armed, ready for a request.  Once a peripheral like a MCBSP, for example, needs data, the MCBSP will send a request (a single signal) to trigger a transfer on the DMA channel that is armed and waiting for the trigger.

Brandon...
One more question... :D
You said that DMA receive the transfer request through auxiliary channel, but it occurs when external host send an interrupt to the DSP (through the HPI). Correct?

If the auxiliary channel does not have the priority to transfer when the HPI sends the interrupt, how the DMA warn the HPI that the transfer should not occurs???

thanks again!!!
:*

Camila: I do want to apologize for referencing the wrong document as it relates to the C6202B.  The correct document is TMS320C62x DSP Expansion Bus (XBUS) Reference Guide (SPRU579).  Despite this, the prior comments about the DMA controller and the Auxiliary channel are still relevant.

Camila Nunes said:

You said that DMA receive the transfer request through auxiliary channel, but it occurs when external host send an interrupt to the DSP (through the HPI). Correct?

The DMA operation is independent of the host sending an interrupt to the DSP through the XBHC register.  The DMA is a separate entity from the CPU.  The XBUS interface (HPI) generates the DMA transaction request when the host initiates the access on the external interface pins.

Camila Nunes said:

If the auxiliary channel does not have the priority to transfer when the HPI sends the interrupt, how the DMA warn the HPI that the transfer should not occurs???

The HPI interface internally sends a request to the DMA.  If the DMA is currently busy, there is a handshake back to the HPI to wait until there is an opportunity for the HPI transfer.  At that time, the arbitration grants the HPI peripheral access to use the DMA Auxiliary channel.