Emifa_ReadWrite_example in the C6455CSL

Yes, this should have been obvious to me...  

I have another question, this time regarding addressing of the EMIFA bus.  In Sec. 3 of SPRU971C (TMS320C645x DSP EMIF User's Guide), it says that there is an internal to external address bus translation.  i.e. for 16-bit async accesses, EA[19:0] = A[21:2], ABA1 = A1.  My question is do I have to perform this address translation explicitly?  It would seem that's the only way, but as of yet, I've been unable to access my slave DSP.  It's quite likely I've got some other minute configuration setting incorrect, but knowing this translation information for sure would help.  Thanks in advance!

Perhaps the documentation should have been more clear on the address translation. But it is very easy for you, because all you have to do is configure the EMIF control registers for the type and size and speed of transfers you want to occur, and the internal EMIF peripheral takes care of the address translation for you.

The internal addresses go down to A0 which is the byte address. The address translation table is just telling you how to connect the EA and ABA signals to your memory or peripheral. EA[19:0] = A[21:2] tells you that EA[19:0] provide the address down to the word address (meaning A[2]) and ABA1 is needed to provide the 16-bit half-word address bit for 16-bit-wide EMIF accesses.

Is that any clearer? If this answers you question, please click  Verify Answer  on this posting; if not, please provide additional information to help us answer you.

This has partially clarified my question, and I greatly appreciate your response.  I have spent much time ensuring that the type, size, and speed of EMIF transfers is configured correctly for my application, but my understanding of how the address lines are driven is still somewhat lacking.  Perhaps I should explain my application a little more completely in order to better understand the problem.

We are attempting to use the C6455 as a Host and a C5510a as the slave.  On the C6455 we are using EMIF, and on the C5510a we are using HPI.  I have a data section in the C5510a reserved for the HPI access, and it is located, for example, at (16-bit) halfword address 0x18000.  As the C6455 uses byte-addressing, when accessing the EMIF, I first convert the halfword address 0x18000 to a byte address 0x30000 before attempting a read or write.  I still do not fully understand what the EMIF address lines will be driven to, and I do not know what the ABA1 line will be driven to.  My first question would be: do I need to be converting from halfword to byte address as I am doing?  It seems that if the EMIF is configured for 16-bit accesses, this should be automatic and I would not need to do the conversion.  However, it was indicated in another forum post that I do.

Secondly, I'd like to use the ABA1 line as a method to differentiate between HPIC and HPID accesses in the C5510a, so I am curious whether this is a signal line I have control over through proper addressing, or if it is a line which is automatically driven by the EMIF peripheral.

Ultimately, I'd like to set up the DMA controller to handle all EMIF accesses, so is this going to be possible (once I have the addressing correct) with my current configuration?  Thanks again!

So are you using CE3 to connect to the 5510?  The CEn signal from the 6455 will determine which address space you need to write to.

For now, I'll assume you're using CE3 to talk to the 5510.  If you look at the Memory Map on page 12 of the data sheet you will see that CE3 corresponds to the (6455) DSP address range 0xB0000000 - 0xB07FFFFF (8MB).  If the 6455 writes into that memory range it will cause a transaction to occur out on the EMIF bus, specifically asserting CE3.

So let's say you do several 16-bit writes.  For example:

// untested code!!!

unsigned short *pCE3 = 0xB0000000; // should be "short" to be a pointer to 16-bit data type! (for 16-bit HPI)
int i;

for (i=0; i<5; i++)
{
   pCE3[i] = i+10;  // write ramp pattern into external memory
}

The above code does 5 writes:

Now in your case you mentioned you want to write to half-word address 0x18000 on the 5510.  That would be a simple matter of writing to pCE3[0x18000] in my example above.

Hopefully that clarifies.

Brad

Thanks for your help, Brad.  I appreciate your time greatly.  I've come to believe that perhaps my problem is not in the 6455 but rather the 5510 HPI configuration.  Out of the 6455 I've verified all timing control signals as well as address and data lines, and everything seems to line up as I expect after reading the documentation.  I know that on the 5510, the DMA controller is responsible for getting the data from the HPID (data register) to memory.  My problem with this is that it's a dedicated DMA channel, and while I can configure any of the other 6 DMA channels, it seems that configuration of the HPI DMA channel is automatic.  Among other reasons I have for believing this is the fact that the HPI can be used to bootload program code into the 5510, indicating that nothing need be configured prior to using the interface.  Is this assumption correct, or can you point me towards a resource which would indicate proper configuration of the HPI on the 5510?  Again, I feel it should be as simple as ensuring the control signals are properly timed as well as having data and address pins strobed at the proper times - all things taken care of by the EMIFA interface.  On the 5510, I can access (write/read) the HPIC control register, but have still not managed to get data through to a specific memory location.  I am using the non-multiplexed mode for the 5510 HPI.

Perhaps this post would best be served by moving to the 55xx forums, so I will post there as well.  Again, thanks for your help.

Make sure HMODE is high to select non-multiplexed mode.  Double-check signal levels/integrity of HCS and HDS1 and HDS2.

If you can post a screen capture from a logic analyzer that would be good too (i.e. screenshot of trying to do a write).

I've verified from the DSK5510 schematic that HMODE is pulled high through external logic.  Unfortunately that pin is not accessible to me when I have my daughter card plugged in, but tomorrow I will find a way to verify that the signal is indeed staying high.  Signal levels of HCS, HDS1, HDS2 are > 3V, and one of the next things on my list is to verify their integrity.  A screen capture of doing 3 consecutive writes to the HPIC register is below.  I chose to do 3 consecutive writes in order to see the changes on the data bus.  My setup parameters are as follows:

EMIF:

Clock Freq = 200 MHz (as configured on the DSK6455 board by default and can be seen on Page A-4 of http://c6000.spectrumdigital.com/dsk6455/v2/files/6455_evm_techref.pdf )

Select Strobe Mode disabled, Write Enable Mode disabled, 16-bit data bus, asynchronous memory select, async ready input enabled (polarity low)

W_setup = 15, W_strobe = 32, W_hold = 7

(yes I realize these are very large values, and I've calculated the acceptable ranges of these values, but I am just ensuring that the signal lines and data buses are holding on for long enough).

A couple things to note in the Logic Analyzer screengrab below is that what is labeled as HCNTL0 is actually ABA1 from the C6455.  HCNTL0 is wired to a switch which I have verified is logic level low.  EMIF_EN (top of EMIF_EN/DIR pair) is a CPLD control signal for enabling the bus transceiver which drives the EMIF signal lines to the external connector, and EMIF_DIR (bottom of EMIF_EN/DIR pair) is the direction signal to the bus transceiver.  This polarity (logic level low) is correct, according to the datasheet (though contrary to the DSK6455 documentation).  The bus transceiver datasheet can be found here: http://focus.ti.com/lit/ds/symlink/sn74lvth16245a.pdf

One thing I notice is that the control signals seem to be at least twice as long as configured.  The durations of the control signals I've calculated from the logic analyzer are below the screenshot.

HCS: 596ns

HCS Asserted -> HDS2 Asserted: 168ns

HDS2: 344ns

Addr. Asserted (as measured by duration of HCNTL0 which is actually ABA1): 604ns

Data Asserted: 644ns

Addr Deasserted -> Data Deasserted: 212 ns

A quick correction in my previous post: "This polarity (logic level low) is correct, according to the datasheet (though contrary to the DSK6455 documentation)." should read "(logic level high)".  Though in the DSK6455 documentation it says that this signal should be 0 for writes, it should actually be 1 according to the datasheet.

Derek Wilson said:

EMIF:

Clock Freq = 200 MHz

According to the datasheet, the max EMIFA clock period is 6ns = 166MHz. So, 200 MHz is a bit high, even if the table says it. Have you measured this, or the EMIF_PLL_CLK coming from the CPLD?

Thank you, Randy.  I should have remembered that as I've read that upper limit in numerous forum posts, not to mention in the documentation.  I've now measured the DSP_EMIFA_CLK output signal, and it's at 100 MHz.  This would explain my control signal timing being twice as long as expected.

It occurs to me that my HPIC writes seem to be functioning as expected, and my reasoning is this: if I write to the DSPINT bit withing the HPIC register, the 5510 breaks off into the ISR I have configured for this interrupt.  However, according to p. 17 of spra741 "Using the TMS320VC5509/5510 EHPI" ( http://dspvillage.ti.com/pdfs/spra741.pdf ), writing a 0 to the RESET bit of HPIC should cause the DSP to go into reset until the host writes a 1 to the RESET bit.  However, this is discussed in the context of when the DSP is started up in HPI boot mode, so the host may not be able to reset the DSP with this bit if not starting in HPI boot mode.  

I am trying to get a screenshot of an HPID write, and I will post it as soon as possible.

When you use CCS to look for the data that was written over the HPI make sure that you select "Data" in the memory window so that the address is treated as a word address rather than a byte address (program).  This is a long shot, but perhaps everything is working and you never switched the view to "Data"?

And yes, the RESET bit applies only to the HPI boot mode and it is for releasing the processor from reset.

I have verified that I'm looking at "Data" memory from within CCS.  I've also done a simple memory dump of the 5510 and searched it for the test symbols I try to write, but to no avail.  I'm looking into a couple more things now, one being the HRDY signal put out by the 5510.  According to spru588b "DSP HPI Reference Guide", 'When low, HRDY indicates that the HPI is busy and the host should extend the current transfer cycle'.  In my configuration, this is connected to the ARDY input on the 6455, which according to spru971c "DSP EMIF User's Guide": 'the EMIF monitors the ARDY pin to determine if the attached device wishes to extend the strobe period of the current access cycle'.

During HPI Read operations, HRDY is asserted shortly after the data strobe (HDS) is asserted (i.e. time E7 of p.79, sprs0760 "TMS320VC5510 Fixed-Point Digital Signal Processors", and p.3 of spraa24 "HPI Throughput and Optimization"). In my configuration, the assertion of HRDY causes the 6455 to extend the read strobe period as expected.  During HPI Write operation, however, HRDY is asserted shortly after the data strobe is deasserted (time E9 of the same p.79, and p.4 of spraa24 "HPI Throughput and Optimization").  According to the EMIF User's Guide, the ARDY signal must be asserted "by the second rising edge of the ECLKOUT pin before the end of the programmed strobe period," which will never happen.  It would seem that these are incompatible signal combinations, as I understand them.  Or is my understanding of their use incorrect?  Another thing is that I never see the HRDY signal being strobed by the 5510 during HPIC accesses (Write or Read).  Is the HRDY signal only asserted during HPID accesses?

Another question I have is regarding the EHPI data bus holders which are enabled through the 5510 SYSR system register.  When I have them enabled, I always read back the last thing written on the bus, and when I have them disabled, I'll often read back 0xFF (both HPIC/HPID).  From what I understand, these bus holders should be enabled in good design practices.  Is this correct?

I'll follow up with an HPID Read/Write logic analyzer grab.

Okay, below I have HPID write/read logical analyzer screengrabs.  Note that only the 8 LSBs of the data and address buses are probed.  For the write, I write to 3 consecutive addresses the values 0xFACE, 0xDEAD, 0xBEEF.  For the read, I try to read these 3 consecutive addresses.  Note that during the read, the only values on the data bus are that which were written last - i.e. 0xEF.  All control signals look good, and the HRDY signal is strobing as if the data is being properly extracted from the buses to memory.

Write:

Read:

One more quick question: If my 5510 breaks off into the ISR set up for the DSPINT bit in the HPIC control register (i.e. HWI 10), can I conclude that HPIC writing is functioning properly?  I've been proceeding with the simple answer of "yes" but maybe I'm wrong.

I cannot envision any scenario which would cause HPIC writes to function properly but not allow reading of this register, in addition to not allowing writing/reading of HPID, but perhaps someone else can think of one.

Derek,

Thanks for following up with your solution.  I'm glad to hear you resolved the issue!!!

Best regards,
Brad