[6727 uhpi]

Ok. I just didn't understand the data sheet. It says they are not
needed if HCS- meets timing requirements and the requirements I see
are that read/write, address and data are all set before HCS- goes low.

However, it worked better after I did that.
The problem still remains. I have done it that way too. I was driving
HDSx with a separate read and write line.
I will put it back.
Don

On 2008, Feb, 4, at 8:35 AM, Jeff Brower wrote:

> Don-
>
>> As I understood it, i could as long as HCS- went true after the read/
>> write, hcntl and address and data lines were set. I will check again.
>
> If you did that, you'd be violating HRDY timing. You must verify
> HRDY *before* asserting HDS. That means /HCS needs
> to be set as a first step, in order to enable HPI and HRDY output.
> Depending on the application and power consumption
> limitations, you can leave /HCS asserted always, or at least when
> you're making a series of HPI accesses.
>
> -Jeff
>
>> Oops, maybe I have the internal memory address wrong? I will check
>> that too.
>> Thanks for all your help.
>> Don
>>
>> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
>>
>>> Don-
>>>
>>>> I am sorry. I sent the whole program because I wanted to make
>>>> sure I
>>>> didn't edit something out that was actually the problem and mislead
>>>> people. Instead, I gave you too much extraneous stuff. That short
>>>> bit
>>>> of code to write external memory was just put there to prove I
>>>> could
>>>> and to set up the values before the FPGA wrote to those same
>>>> locations. FPGA writes occur but sometimes I am missing the high
>>>> half
>>>> of the word and sometimes the low half with the pieces of the words
>>>> that make it concatenated to form new 'words' in this area. The HPI
>>>> write pointers appear to increment correctly, however (very
>>>> confusing
>>>> for me) but I can see that either it didn't see the HHWIL and or
>>>> didn't actually post-increment.
>>>>
>>>> Please ignore the write to external RAM.
>>>>
>>>> Yes, I am writing to external RAM with the FPGA, but the same
>>>> problem
>>>> exists if I write to 0x10000000, internal ram.
>>>>
>>>> I can see the Hrdy working correctly relative to HCS-. All four
>>>> conditions described in the data sheet and the application notes on
>>>> UHPI have been tested and work as expected with the HRDY either
>>>> accepting the data (staying low) or stalling the FPGA (going high)
>>>> just as described.
>>>>
>>>> Because the timing (according to the logic analyzer) met all the
>>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2,
>>>> HAS-
>>>> is permanently high with HDS1 high and HDS2 low. The read/write
>>>> strobe
>>>> occurs well before HCS-. But I will make some more tests.
>>>>
>>>> I have not proven that the PLL is truly set to 250MHz with a scope-
>>>> this is a very good question. I did walk through the setup to see
>>>> the
>>>> multipliers were correct and the clocks were also correctly
>>>> sync'd -
>>>> that is with the special sync registers. I will try to check that
>>>> today. Thanks.
>>>>
>>>> I will get back to you as soon as I can get some data.
>>>
>>> How can you get away without using data strobe (either HDS1 or
>>> HDS2)? I don't think the data sheet permits you to do
>>> this -- HR/W should be asserted and stable (meeting minimum setup
>>> time) *prior* to internal HDS, and all timing should
>>> be relative to internal HDS active.
>>>
>>> Also, I would suggest you test HPI read first, then you cut the
>>> problem in half. Your DSP test code can initialize
>>> some internal mem data, then FPGA reads it. Make sure you can do
>>> all combinations of read (various addresses,
>>> autoincrement, non-autoincrement, etc) then test HPI writes.
>>>
>>> I don't know details of C672x as I do C671x, but I would have
>>> thought that internal mem starts at zero rather than
>>> 0x10000000. I'm sure you've checked this, but I am curious though,
>>> what memory is at location 0x0? The older C620x
>>> devices split internal data and program mem, and program mem started
>>> at 0x0, so maybe something like that is going on.
>>>
>>> -Jeff
>>>
>>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>>>>
>>>>> Woshi Don-
>>>>>
>>>>> It's not clear what you're doing. The HPI peripheral is a slave,
>>>>> so
>>>>> you must be using the FPGA to read/write 6727
>>>>> memory, right? So you are reading/writing memory at 0x80000000?
>>>>> First, that's not internal memory... second you are
>>>>> expecting the FPGA to read values 0 to 15?
>>>>>
>>>>> Is this correct? If so, I suggest a) that you test internal memory
>>>>> first, and b) you use some test values that allow
>>>>> you to "see" what's going on more clearly, for example values that
>>>>> increment in both low and high 16-bit halves.
>>>>>
>>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
>>>>> to checking HRDY? What is the FPGA clock and how
>>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
>>>>> setting HCNTL and H/RW before strobing /HDS? How
>>>>> sure are you the internal clock rate is truly 250 MHz? Did you
>>>>> measure any of the CLKOUT signals? If the internal
>>>>> rate exceeds the spec that can either mess up the DSP internal
>>>>> circuitry (HPI results undefined) or exceed your FPGA
>>>>> timing.
>>>>>
>>>>> -Jeff
>>>>>
>>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
>>>>> fpga
>>>>>> meets all the requirements for the DSP (from what I can see on a
>>>>> logic
>>>>>> analyzer) so I am only using the read/write, hcntl, and ready
>>>>>> lines,
>>>>>> in addition to the 16-bits of data for half-word mode. the byte
>>>>>> enables are tied active, the hds pins are set one high the other
>>>>> low,
>>>>>> the int- is tied high, as is the has line. I also have those made
>>>>> GPIO
>>>>>> pins so that they will see the default anyway.
>>>>>>
>>>>>> I have it set for half-word mode and I am not using HAS. I have
>>>>>> the
>>>>>> PLL set to 250MHz.
>>>>>>
>>>>>> My problem is that I can read and write but not consistently.
>>>>>> sometimes, I get the whole 32-bit word transfered, often only
>>>>>> half
>>>>> of
>>>>>> it. The auto-increment does seem to register the correct count
>>>>>> but I
>>>>>> only see half of the tranfer in the ram sometimes. It is not
>>>>> consistent.
>>>>>>
>>>>>> I am sending the simple set up code I have for test, probably I
>>>>>> have
>>>>>> something set wrong?
>>>>>>
>>>>>> Or just any thoughts?
>>>>>>
>>>>>> #define CHIP_6713
>>>>>> #include
>>>>>> #include
>>>>>> //#include "mcasp1.h"
>>>>>> #include
>>>>>>
>>>>>> unsigned int * CfgHpi;
>>>>>> unsigned int * Hpic;
>>>>>> unsigned int * Gpioen;
>>>>>> unsigned int * Hpiaw;
>>>>>> unsigned int * Hpiar;
>>>>>> unsigned int * memory;
>>>>>> unsigned int * pwremu;
>>>>>> unsigned int * memory;
>>>>>> unsigned int * adrmsb;
>>>>>> unsigned int * adrnmsb;
>>>>>> /*----------------------*/
>>>>>>
>>>>>> /
>>>>> **********************************************************************/
>>>>>> /* Main */
>>>>>> /
>>>>> **********************************************************************/
>>>>>> void main() {
>>>>>>
>>>>>>
>>>>>> int i,port;
>>>>>> int error = 0;
>>>>>>
>>>>>> init_pll();
>>>>>>
>>>>>> CfgHpi = (unsigned int *)0x40000008;
>>>>>> Gpioen = (unsigned int *) 0x4300000c;
>>>>>> Hpic = (unsigned int *)0x43000030;
>>>>>> Hpiaw = (unsigned int *) 0x43000034;
>>>>>> Hpiar = (unsigned int *) 0x43000038;
>>>>>> memory = (unsigned int *) 0x80000000;
>>>>>> pwremu = (unsigned int *) 0x43000004;
>>>>>> adrmsb = (unsigned int *) 0x4000000c;
>>>>>> adrnmsb = (unsigned int *) 0x40000010;
>>>>>> memory = (unsigned int *) 0x80000000;
>>>>>> /* Configuration for DEVCFG register */
>>>>>> *CfgHpi = 0x2;
>>>>>> *adrmsb = 0x80;
>>>>>> *adrnmsb = 0x0;
>>>>>> *CfgHpi = 0x3;
>>>>>> *Hpic = 0x00;
>>>>>> *Gpioen = 0x1e4c;
>>>>>> *pwremu = 0x1;
>>>>>>
>>>>>> for(i=0;i<16;i++){
>>>>>> *memory++ = i;
>>>>>> }
>>>>>>
>>>>>> while(1);
>>
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Don-

> I was going by note G at the bottom of p.56 of the datasheet: Only
> required if needed for strobe timing. Not required if CS- meets strobe
> timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
> have them tied opposite.

Ok, but in that case you'd have to:

-disable HDS, enable HCS, check HRDY
-disable HCS, enable HDS
-use HCS as the strobe

Otherwise the moment you turn on HCS, you're causing an access, whether the HPI is ready or not. Maybe that would
still work and you could sit on HRDY, but I think you could have problems, as it would depend on whether the HPI can
accept an access initiated (strobed) *prior* to HRDY valid. Does the data sheet say anything about that case?

-Jeff

> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
>
>> Don-
>>
>>> I am sorry. I sent the whole program because I wanted to make sure I
>>> didn't edit something out that was actually the problem and mislead
>>> people. Instead, I gave you too much extraneous stuff. That short bit
>>> of code to write external memory was just put there to prove I could
>>> and to set up the values before the FPGA wrote to those same
>>> locations. FPGA writes occur but sometimes I am missing the high half
>>> of the word and sometimes the low half with the pieces of the words
>>> that make it concatenated to form new 'words' in this area. The HPI
>>> write pointers appear to increment correctly, however (very confusing
>>> for me) but I can see that either it didn't see the HHWIL and or
>>> didn't actually post-increment.
>>>
>>> Please ignore the write to external RAM.
>>>
>>> Yes, I am writing to external RAM with the FPGA, but the same problem
>>> exists if I write to 0x10000000, internal ram.
>>>
>>> I can see the Hrdy working correctly relative to HCS-. All four
>>> conditions described in the data sheet and the application notes on
>>> UHPI have been tested and work as expected with the HRDY either
>>> accepting the data (staying low) or stalling the FPGA (going high)
>>> just as described.
>>>
>>> Because the timing (according to the logic analyzer) met all the
>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
>>> is permanently high with HDS1 high and HDS2 low. The read/write
>>> strobe
>>> occurs well before HCS-. But I will make some more tests.
>>>
>>> I have not proven that the PLL is truly set to 250MHz with a scope-
>>> this is a very good question. I did walk through the setup to see the
>>> multipliers were correct and the clocks were also correctly sync'd -
>>> that is with the special sync registers. I will try to check that
>>> today. Thanks.
>>>
>>> I will get back to you as soon as I can get some data.
>>
>> How can you get away without using data strobe (either HDS1 or
>> HDS2)? I don't think the data sheet permits you to do
>> this -- HR/W should be asserted and stable (meeting minimum setup
>> time) *prior* to internal HDS, and all timing should
>> be relative to internal HDS active.
>>
>> Also, I would suggest you test HPI read first, then you cut the
>> problem in half. Your DSP test code can initialize
>> some internal mem data, then FPGA reads it. Make sure you can do
>> all combinations of read (various addresses,
>> autoincrement, non-autoincrement, etc) then test HPI writes.
>>
>> I don't know details of C672x as I do C671x, but I would have
>> thought that internal mem starts at zero rather than
>> 0x10000000. I'm sure you've checked this, but I am curious though,
>> what memory is at location 0x0? The older C620x
>> devices split internal data and program mem, and program mem started
>> at 0x0, so maybe something like that is going on.
>>
>> -Jeff
>>
>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>>>
>>>> Woshi Don-
>>>>
>>>> It's not clear what you're doing. The HPI peripheral is a slave, so
>>>> you must be using the FPGA to read/write 6727
>>>> memory, right? So you are reading/writing memory at 0x80000000?
>>>> First, that's not internal memory... second you are
>>>> expecting the FPGA to read values 0 to 15?
>>>>
>>>> Is this correct? If so, I suggest a) that you test internal memory
>>>> first, and b) you use some test values that allow
>>>> you to "see" what's going on more clearly, for example values that
>>>> increment in both low and high 16-bit halves.
>>>>
>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
>>>> to checking HRDY? What is the FPGA clock and how
>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
>>>> setting HCNTL and H/RW before strobing /HDS? How
>>>> sure are you the internal clock rate is truly 250 MHz? Did you
>>>> measure any of the CLKOUT signals? If the internal
>>>> rate exceeds the spec that can either mess up the DSP internal
>>>> circuitry (HPI results undefined) or exceed your FPGA
>>>> timing.
>>>>
>>>> -Jeff
>>>>
>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
>>>> fpga
>>>>> meets all the requirements for the DSP (from what I can see on a
>>>> logic
>>>>> analyzer) so I am only using the read/write, hcntl, and ready
>>>>> lines,
>>>>> in addition to the 16-bits of data for half-word mode. the byte
>>>>> enables are tied active, the hds pins are set one high the other
>>>> low,
>>>>> the int- is tied high, as is the has line. I also have those made
>>>> GPIO
>>>>> pins so that they will see the default anyway.
>>>>>
>>>>> I have it set for half-word mode and I am not using HAS. I have the
>>>>> PLL set to 250MHz.
>>>>>
>>>>> My problem is that I can read and write but not consistently.
>>>>> sometimes, I get the whole 32-bit word transfered, often only half
>>>> of
>>>>> it. The auto-increment does seem to register the correct count
>>>>> but I
>>>>> only see half of the tranfer in the ram sometimes. It is not
>>>> consistent.
>>>>>
>>>>> I am sending the simple set up code I have for test, probably I
>>>>> have
>>>>> something set wrong?
>>>>>
>>>>> Or just any thoughts?
>>>>>
>>>>> #define CHIP_6713
>>>>> #include
>>>>> #include
>>>>> //#include "mcasp1.h"
>>>>> #include
>>>>>
>>>>> unsigned int * CfgHpi;
>>>>> unsigned int * Hpic;
>>>>> unsigned int * Gpioen;
>>>>> unsigned int * Hpiaw;
>>>>> unsigned int * Hpiar;
>>>>> unsigned int * memory;
>>>>> unsigned int * pwremu;
>>>>> unsigned int * memory;
>>>>> unsigned int * adrmsb;
>>>>> unsigned int * adrnmsb;
>>>>> /*----------------------*/
>>>>>
>>>>> /
>>>> **********************************************************************/
>>>>> /* Main */
>>>>> /
>>>> **********************************************************************/
>>>>> void main() {
>>>>>
>>>>>
>>>>> int i,port;
>>>>> int error = 0;
>>>>>
>>>>> init_pll();
>>>>>
>>>>> CfgHpi = (unsigned int *)0x40000008;
>>>>> Gpioen = (unsigned int *) 0x4300000c;
>>>>> Hpic = (unsigned int *)0x43000030;
>>>>> Hpiaw = (unsigned int *) 0x43000034;
>>>>> Hpiar = (unsigned int *) 0x43000038;
>>>>> memory = (unsigned int *) 0x80000000;
>>>>> pwremu = (unsigned int *) 0x43000004;
>>>>> adrmsb = (unsigned int *) 0x4000000c;
>>>>> adrnmsb = (unsigned int *) 0x40000010;
>>>>> memory = (unsigned int *) 0x80000000;
>>>>> /* Configuration for DEVCFG register */
>>>>> *CfgHpi = 0x2;
>>>>> *adrmsb = 0x80;
>>>>> *adrnmsb = 0x0;
>>>>> *CfgHpi = 0x3;
>>>>> *Hpic = 0x00;
>>>>> *Gpioen = 0x1e4c;
>>>>> *pwremu = 0x1;
>>>>>
>>>>> for(i=0;i<16;i++){
>>>>> *memory++ = i;
>>>>> }
>>>>>
>>>>> while(1);
>>

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Don-

> I have HDS1 and HDS2 permanently tied - one to gnd, one to vcc, just as the datasheet says.

I've never seen one out of literally dozens of TI DSP data sheets before (since 1998) that advised to use the HPI this
way in multiplexed HPI mode. HDS stands for "host data strobe" -- so use it as a data strobe. That's what it's there
for.

> I set the address, data and hcntl data on the pins one 1/66MHz period before asserting HCS-. There are 4 conditions
> listed in the UHPI application note and data sheet relating to HRDY that can occur. All these conditions are met. When
> necessary, and HRDY is asserted the FPGA waits until it is de-asserted. I have never seen a time when this does not
> occur. Basically, just about any read is likely to cause a HRDY hit and it does and the FPGA waits. because of the
> FIFOs the writes unless they exceed the 8 level fifo. Of course writes and reads of the HPI registers shouldn't cause
> a HRDY and I have not seen one.
>
> I appologize but I don't really understand what you are saying below: disable HDS, enable HDS- why?

I just said that because of your weird way of using the HPI. If you read my earlier e-mails I said clearly to enable
HCS, check for HRDY, assert HNCTL, HR/W (and data if writing), and then strobe the darn thing. With the data strobe
signal. Is that difficult with your FPGA design? Did you not run the HDS lines to the FPGA?

> If you look at the schematic of the internal strobe, you will see that HDS1 and HDS2 are tied to an XOR gate and this
> gate is AND'd with HCS-.

Exactly, and if you look at the TI reference designs they typically show HDS1 tied high and HDS2 used as the external
/HDS (active low).

-Jeff

> Forgive me, I am not trying to be obtuse and I do appreciate your help. I have put the
> HDS pins back. It doesn't solve the problem.
>
> Don
> ----- Original Message ----
> From: Jeff Brower
> To: Don Morgan
> Cc: c...
> Sent: Monday, February 4, 2008 8:55:03 AM
> Subject: Re: [c6x] [6727 uhpi]
>
> Don-
>
>> I was going by note G at the bottom of p.56 of the datasheet: Only
>> required if needed for strobe timing. Not required if CS- meets strobe
>> timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
>> have them tied opposite.
>
> Ok, but in that case you'd have to:
>
> -disable HDS, enable HCS, check HRDY
> -disable HCS, enable HDS
> -use HCS as the strobe
>
> Otherwise the moment you turn on HCS, you're causing an access, whether the HPI is ready or not. Maybe that would
> still work and you could sit on HRDY, but I think you could have problems, as it would depend on whether the HPI can
> accept an access initiated (strobed) *prior* to HRDY valid. Does the data sheet say anything about that case?
>
> -Jeff
>
>> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
>>
>>> Don-
>>>
>>>> I am sorry. I sent the whole program because I wanted to make sure I
>>>> didn't edit something out that was actually the problem and mislead
>>>> people. Instead, I gave you too much extraneous stuff. That short bit
>>>> of code to write external memory was just put there to prove I could
>>>> and to set up the values before the FPGA wrote to those same
>>>> locations. FPGA writes occur but sometimes I am missing the high half
>>>> of the word and sometimes the low half with the pieces of the words
>>>> that make it concatenated to form new 'words' in this area. The HPI
>>>> write pointers appear to increment correctly, however (very confusing
>>>> for me) but I can see that either it didn't see the HHWIL and or
>>>> didn't actually post-increment.
>>>>
>>>> Please ignore the write to external RAM.
>>>>
>>>> Yes, I am writing to external RAM with the FPGA, but the same problem
>>>> exists if I write to 0x10000000, internal ram.
>>>>
>>>> I can see the Hrdy working correctly relative to HCS-. All four
>>>> conditions described in the data sheet and the application notes on
>>>> UHPI have been tested and work as expected with the HRDY either
>>>> accepting the data (staying low) or stalling the FPGA (going high)
>>>> just as described.
>>>>
>>>> Because the timing (according to the logic analyzer) met all the
>>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
>>>> is permanently high with HDS1 high and HDS2 low. The read/write
>>>> strobe
>>>> occurs well before HCS-. But I will make some more tests.
>>>>
>>>> I have not proven that the PLL is truly set to 250MHz with a scope-
>>>> this is a very good question. I did walk through the setup to see the
>>>> multipliers were correct and the clocks were also correctly sync'd -
>>>> that is with the special sync registers. I will try to check that
>>>> today. Thanks.
>>>>
>>>> I will get back to you as soon as I can get some data.
>>>
>>> How can you get away without using data strobe (either HDS1 or
>>> HDS2)? I don't think the data sheet permits you to do
>>> this -- HR/W should be asserted and stable (meeting minimum setup
>>> time) *prior* to internal HDS, and all timing should
>>> be relative to internal HDS active.
>>>
>>> Also, I would suggest you test HPI read first, then you cut the
>>> problem in half. Your DSP test code can initialize
>>> some internal mem data, then FPGA reads it. Make sure you can do
>>> all combinations of read (various addresses,
>>> autoincrement, non-autoincrement, etc) then test HPI writes.
>>>
>>> I don't know details of C672x as I do C671x, but I would have
>>> thought that internal mem starts at zero rather than
>>> 0x10000000. I'm sure you've checked this, but I am curious though,
>>> what memory is at location 0x0? The older C620x
>>> devices split internal data and program mem, and program mem started
>>> at 0x0, so maybe something like that is going on.
>>>
>>> -Jeff
>>>
>>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>>>>
>>>>> Woshi Don-
>>>>>
>>>>> It's not clear what you're doing. The HPI peripheral is a slave, so
>>>>> you must be using the FPGA to read/write 6727
>>>>> memory, right? So you are reading/writing memory at 0x80000000?
>>>>> First, that's not internal memory... second you are
>>>>> expecting the FPGA to read values 0 to 15?
>>>>>
>>>>> Is this correct? If so, I suggest a) that you test internal memory
>>>>> first, and b) you use some test values that allow
>>>>> you to "see" what's going on more clearly, for example values that
>>>>> increment in both low and high 16-bit halves.
>>>>>
>>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
>>>>> to checking HRDY? What is the FPGA clock and how
>>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
>>>>> setting HCNTL and H/RW before strobing /HDS? How
>>>>> sure are you the internal clock rate is truly 250 MHz? Did you
>>>>> measure any of the CLKOUT signals? If the internal
>>>>> rate exceeds the spec that can either mess up the DSP internal
>>>>> circuitry (HPI results undefined) or exceed your FPGA
>>>>> timing.
>>>>>
>>>>> -Jeff
>>>>>
>>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
>>>>> fpga
>>>>>> meets all the requirements for the DSP (from what I can see on a
>>>>> logic
>>>>>> analyzer) so I am only using the read/write, hcntl, and ready
>>>>>> lines,
>>>>>> in addition to the 16-bits of data for half-word mode. the byte
>>>>>> enables are tied active, the hds pins are set one high the other
>>>>> low,
>>>>>> the int- is tied high, as is the has line. I also have those made
>>>>> GPIO
>>>>>> pins so that they will see the default anyway.
>>>>>>
>>>>>> I have it set for half-word mode and I am not using HAS. I have the
>>>>>> PLL set to 250MHz.
>>>>>>
>>>>>> My problem is that I can read and write but not consistently.
>>>>>> sometimes, I get the whole 32-bit word transfered, often only half
>>>>> of
>>>>>> it. The auto-increment does seem to register the correct count
>>>>>> but I
>>>>>> only see half of the tranfer in the ram sometimes. It is not
>>>>> consistent.
>>>>>>
>>>>>> I am sending the simple set up code I have for test, probably I
>>>>>> have
>>>>>> something set wrong?
>>>>>>
>>>>>> Or just any thoughts?
>>>>>>
>>>>>> #define CHIP_6713
>>>>>> #include
>>>>>> #include
>>>>>> //#include "mcasp1.h"
>>>>>> #include
>>>>>>
>>>>>> unsigned int * CfgHpi;
>>>>>> unsigned int * Hpic;
>>>>>> unsigned int * Gpioen;
>>>>>> unsigned int * Hpiaw;
>>>>>> unsigned int * Hpiar;
>>>>>> unsigned int * memory;
>>>>>> unsigned int * pwremu;
>>>>>> unsigned int * memory;
>>>>>> unsigned int * adrmsb;
>>>>>> unsigned int * adrnmsb;
>>>>>> /*---------- --------- --------- --------- --------- --------- ---*/
>>>>>>
>>>>>> /
>>>>> ************ ********* ********* ********* ********* ********* ********* ****/
>>>>>> /* Main */
>>>>>> /
>>>>> ************ ********* ********* ********* ********* ********* ********* ****/
>>>>>> void main() {
>>>>>>
>>>>>>
>>>>>> int i,port;
>>>>>> int error = 0;
>>>>>>
>>>>>> init_pll();
>>>>>>
>>>>>> CfgHpi = (unsigned int *)0x40000008;
>>>>>> Gpioen = (unsigned int *) 0x4300000c;
>>>>>> Hpic = (unsigned int *)0x43000030;
>>>>>> Hpiaw = (unsigned int *) 0x43000034;
>>>>>> Hpiar = (unsigned int *) 0x43000038;
>>>>>> memory = (unsigned int *) 0x80000000;
>>>>>> pwremu = (unsigned int *) 0x43000004;
>>>>>> adrmsb = (unsigned int *) 0x4000000c;
>>>>>> adrnmsb = (unsigned int *) 0x40000010;
>>>>>> memory = (unsigned int *) 0x80000000;
>>>>>> /* Configuration for DEVCFG register */
>>>>>> *CfgHpi = 0x2;
>>>>>> *adrmsb = 0x80;
>>>>>> *adrnmsb = 0x0;
>>>>>> *CfgHpi = 0x3;
>>>>>> *Hpic = 0x00;
>>>>>> *Gpioen = 0x1e4c;
>>>>>> *pwremu = 0x1;
>>>>>>
>>>>>> for(i=0;i<16; i++){
>>>>>> *memory++ = i;
>>>>>> }
>>>>>>
>>>>>> while(1);

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Don-
> I have no interest in arguing with you, I just refer you to the 6727b data sheet
> (p56, note G) and the timing diagrams (check the timing number too-> specifically
> #37 and #4, please), which are met.
>

That's fine, and I have no interest in having the data sheet read back to me after
using various TI DSP HPIs for 10 years. There can be many notes in the data sheet,
some even conflicting or inaccurate. That's why groups like this exist, so people
can ask questions and get straight answers based on experience.
> It is just likely that I didn't understand some part of it. It has happened before.
>
> I have re-introduced the HDS lines and I will use them as instructed.
>
> The problem still exists.
>

If the problem still exists after using HDS as the data strobe, then a) did you try
the read test that I suggested, b) did you ensure you are reading from internal mem,
and c) did you measure CLKOUT? If so, what are the read values you get? For example
if you fill DSP memory with 01234567, 5555AAAA, 76543210 (or some other pattern
unique in both lower and upper 16 bit halves), what do you see in your FPGA read
results?

-Jeff

PS. Please post to the group, not to me.
> ----- Original Message ----
> From: Jeff Brower
> To: Don Morgan
> Cc: c...
> Sent: Monday, February 4, 2008 11:15:37 AM
> Subject: Re: [c6x] [6727 uhpi]
>
> Don-
>
> > I have HDS1 and HDS2 permanently tied - one to gnd, one to vcc, just as the
> datasheet says.
>
> I've never seen one out of literally dozens of TI DSP data sheets before (since
> 1998) that advised to use the HPI this
> way in multiplexed HPI mode. HDS stands for "host data strobe" -- so use it as a
> data strobe. That's what it's there
> for.
>
> > I set the address, data and hcntl data on the pins one 1/66MHz period before
> asserting HCS-. There are 4 conditions
> > listed in the UHPI application note and data sheet relating to HRDY that can
> occur. All these conditions are met. When
> > necessary, and HRDY is asserted the FPGA waits until it is de-asserted. I have
> never seen a time when this does not
> > occur. Basically, just about any read is likely to cause a HRDY hit and it does
> and the FPGA waits. because of the
> > FIFOs the writes unless they exceed the 8 level fifo. Of course writes and reads
> of the HPI registers shouldn't cause
> > a HRDY and I have not seen one.
> >
> > I appologize but I don't really understand what you are saying below: disable
> HDS, enable HDS- why?
>
> I just said that because of your weird way of using the HPI. If you read my
> earlier e-mails I said clearly to enable
> HCS, check for HRDY, assert HNCTL, HR/W (and data if writing), and then strobe the
> darn thing. With the data strobe
> signal. Is that difficult with your FPGA design? Did you not run the HDS lines to
> the FPGA?
>
> > If you look at the schematic of the internal strobe, you will see that HDS1 and
> HDS2 are tied to an XOR gate and this
> > gate is AND'd with HCS-.
>
> Exactly, and if you look at the TI reference designs they typically show HDS1 tied
> high and HDS2 used as the external
> /HDS (active low).
>
> -Jeff
>
> > Forgive me, I am not trying to be obtuse and I do appreciate your help. I have
> put the
> > HDS pins back. It doesn't solve the problem.
> >
> > Don
> >
> >
> > ----- Original Message ----
> > From: Jeff Brower
> > To: Don Morgan
> > Cc: c...
> > Sent: Monday, February 4, 2008 8:55:03 AM
> > Subject: Re: [c6x] [6727 uhpi]
> >
> > Don-
> >
> >> I was going by note G at the bottom of p.56 of the datasheet: Only
> >> required if needed for strobe timing. Not required if CS- meets strobe
> >> timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
> >> have them tied opposite.
> >
> > Ok, but in that case you'd have to:
> >
> > -disable HDS, enable HCS, check HRDY
> > -disable HCS, enable HDS
> > -use HCS as the strobe
> >
> > Otherwise the moment you turn on HCS, you're causing an access, whether the HPI
> is ready or not. Maybe that would
> > still work and you could sit on HRDY, but I think you could have problems, as it
> would depend on whether the HPI can
> > accept an access initiated (strobed) *prior* to HRDY valid. Does the data sheet
> say anything about that case?
> >
> > -Jeff
> >
> >> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
> >>
> >>> Don-
> >>>
> >>>> I am sorry. I sent the whole program because I wanted to make sure I
> >>>> didn't edit something out that was actually the problem and mislead
> >>>> people. Instead, I gave you too much extraneous stuff. That short bit
> >>>> of code to write external memory was just put there to prove I could
> >>>> and to set up the values before the FPGA wrote to those same
> >>>> locations. FPGA writes occur but sometimes I am missing the high half
> >>>> of the word and sometimes the low half with the pieces of the words
> >>>> that make it concatenated to form new 'words' in this area. The HPI
> >>>> write pointers appear to increment correctly, however (very confusing
> >>>> for me) but I can see that either it didn't see the HHWIL and or
> >>>> didn't actually post-increment.
> >>>>
> >>>> Please ignore the write to external RAM.
> >>>>
> >>>> Yes, I am writing to external RAM with the FPGA, but the same problem
> >>>> exists if I write to 0x10000000, internal ram.
> >>>>
> >>>> I can see the Hrdy working correctly relative to HCS-. All four
> >>>> conditions described in the data sheet and the application notes on
> >>>> UHPI have been tested and work as expected with the HRDY either
> >>>> accepting the data (staying low) or stalling the FPGA (going high)
> >>>> just as described.
> >>>>
> >>>> Because the timing (according to the logic analyzer) met all the
> >>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
> >>>> is permanently high with HDS1 high and HDS2 low. The read/write
> >>>> strobe
> >>>> occurs well before HCS-. But I will make some more tests.
> >>>>
> >>>> I have not proven that the PLL is truly set to 250MHz with a scope-
> >>>> this is a very good question. I did walk through the setup to see the
> >>>> multipliers were correct and the clocks were also correctly sync'd -
> >>>> that is with the special sync registers. I will try to check that
> >>>> today. Thanks.
> >>>>
> >>>> I will get back to you as soon as I can get some data.
> >>>
> >>> How can you get away without using data strobe (either HDS1 or
> >>> HDS2)? I don't think the data sheet permits you to do
> >>> this -- HR/W should be asserted and stable (meeting minimum setup
> >>> time) *prior* to internal HDS, and all timing should
> >>> be relative to internal HDS active.
> >>>
> >>> Also, I would suggest you test HPI read first, then you cut the
> >>> problem in half. Your DSP test code can initialize
> >>> some internal mem data, then FPGA reads it. Make sure you can do
> >>> all combinations of read (various addresses,
> >>> autoincrement, non-autoincrement, etc) then test HPI writes.
> >>>
> >>> I don't know details of C672x as I do C671x, but I would have
> >>> thought that internal mem starts at zero rather than
> >>> 0x10000000. I'm sure you've checked this, but I am curious though,
> >>> what memory is at location 0x0? The older C620x
> >>> devices split internal data and program mem, and program mem started
> >>> at 0x0, so maybe something like that is going on.
> >>>
> >>> -Jeff
> >>>
> >>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
> >>>>
> >>>>> Woshi Don-
> >>>>>
> >>>>> It's not clear what you're doing. The HPI peripheral is a slave, so
> >>>>> you must be using the FPGA to read/write 6727
> >>>>> memory, right? So you are reading/writing memory at 0x80000000?
> >>>>> First, that's not internal memory... second you are
> >>>>> expecting the FPGA to read values 0 to 15?
> >>>>>
> >>>>> Is this correct? If so, I suggest a) that you test internal memory
> >>>>> first, and b) you use some test values that allow
> >>>>> you to "see" what's going on more clearly, for example values that
> >>>>> increment in both low and high 16-bit halves.
> >>>>>
> >>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
> >>>>> to checking HRDY? What is the FPGA clock and how
> >>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
> >>>>> setting HCNTL and H/RW before strobing /HDS? How
> >>>>> sure are you the internal clock rate is truly 250 MHz? Did you
> >>>>> measure any of the CLKOUT signals? If the internal
> >>>>> rate exceeds the spec that can either mess up the DSP internal
> >>>>> circuitry (HPI results undefined) or exceed your FPGA
> >>>>> timing.
> >>>>>
> >>>>> -Jeff
> >>>>>
> >>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
> >>>>> fpga
> >>>>>> meets all the requirements for the DSP (from what I can see on a
> >>>>> logic
> >>>>>> analyzer) so I am only using the read/write, hcntl, and ready
> >>>>>> lines,
> >>>>>> in addition to the 16-bits of data for half-word mode. the byte
> >>>>>> enables are tied active, the hds pins are set one high the other
> >>>>> low,
> >>>>>> the int- is tied high, as is the has line. I also have those made
> >>>>> GPIO
> >>>>>> pins so that they will see the default anyway.
> >>>>>>
> >>>>>> I have it set for half-word mode and I am not using HAS. I have the
> >>>>>> PLL set to 250MHz.
> >>>>>>
> >>>>>> My problem is that I can read and write but not consistently.
> >>>>>> sometimes, I get the whole 32-bit word transfered, often only half
> >>>>> of
> >>>>>> it. The auto-increment does seem to register the correct count
> >>>>>> but I
> >>>>>> only see half of the tranfer in the ram sometimes. It is not
> >>>>> consistent.
> >>>>>>
> >>>>>> I am sending the simple set up code I have for test, probably I
> >>>>>> have
> >>>>>> something set wrong?
> >>>>>>
> >>>>>> Or just any thoughts?
> >>>>>>
> >>>>>> #define CHIP_6713
> >>>>>> #include
> >>>>>> #include
> >>>>>> //#include "mcasp1.h"
> >>>>>> #include
> >>>>>>
> >>>>>> unsigned int * CfgHpi;
> >>>>>> unsigned int * Hpic;
> >>>>>> unsigned int * Gpioen;
> >>>>>> unsigned int * Hpiaw;
> >>>>>> unsigned int * Hpiar;
> >>>>>> unsigned int * memory;
> >>>>>> unsigned int * pwremu;
> >>>>>> unsigned int * memory;
> >>>>>> unsigned int * adrmsb;
> >>>>>> unsigned int * adrnmsb;
> >>>>>> /*---------- --------- --------- --------- --------- --------- ---*/
> >>>>>>
> >>>>>> /
> >>>>> ************ ********* ********* ********* ********* ********* *********
> ****/
> >>>>>> /* Main */
> >>>>>> /
> >>>>> ************ ********* ********* ********* ********* ********* *********
> ****/
> >>>>>> void main() {
> >>>>>>
> >>>>>>
> >>>>>> int i,port;
> >>>>>> int error = 0;
> >>>>>>
> >>>>>> init_pll();
> >>>>>>
> >>>>>> CfgHpi = (unsigned int *)0x40000008;
> >>>>>> Gpioen = (unsigned int *) 0x4300000c;
> >>>>>> Hpic = (unsigned int *)0x43000030;
> >>>>>> Hpiaw = (unsigned int *) 0x43000034;
> >>>>>> Hpiar = (unsigned int *) 0x43000038;
> >>>>>> memory = (unsigned int *) 0x80000000;
> >>>>>> pwremu = (unsigned int *) 0x43000004;
> >>>>>> adrmsb = (unsigned int *) 0x4000000c;
> >>>>>> adrnmsb = (unsigned int *) 0x40000010;
> >>>>>> memory = (unsigned int *) 0x80000000;
> >>>>>> /* Configuration for DEVCFG register */
> >>>>>> *CfgHpi = 0x2;
> >>>>>> *adrmsb = 0x80;
> >>>>>> *adrnmsb = 0x0;
> >>>>>> *CfgHpi = 0x3;
> >>>>>> *Hpic = 0x00;
> >>>>>> *Gpioen = 0x1e4c;
> >>>>>> *pwremu = 0x1;
> >>>>>>
> >>>>>> for(i=0;i<16; i++){
> >>>>>> *memory++ = i;
> >>>>>> }
> >>>>>>
> >>>>>> while(1);
> Start a New Thread

Just a couple of comments;

Jeff,

The c6727 has some differences wrt preceding c6200/6700 devices, two
of which are:
different HPI,
internal RAM origin at 0x10000000 [ROM is at 0].

Don,

I don't pretend to understand the details of your problem, but I think
that your FPGA is over running the DSP's HPI. Probably a sync/timing
problem related to CS and RDY. If you don't identify the problem, try
inserting some extra time between HPI accesses.

mikedunn

On Feb 4, 2008 1:26 PM, Jeff Brower wrote:
> Don-
> I have no interest in arguing with you, I just refer you to the 6727b data
> sheet (p56, note G) and the timing diagrams (check the timing number too->
> specifically #37 and #4, please), which are met.
> That's fine, and I have no interest in having the data sheet read back to me
> after using various TI DSP HPIs for 10 years. There can be many notes in
> the data sheet, some even conflicting or inaccurate. That's why groups like
> this exist, so people can ask questions and get straight answers based on
> experience.
>
> It is just likely that I didn't understand some part of it. It has happened
> before.
>
> I have re-introduced the HDS lines and I will use them as instructed.
>
> The problem still exists.
> If the problem still exists after using HDS as the data strobe, then a) did
> you try the read test that I suggested, b) did you ensure you are reading
> from internal mem, and c) did you measure CLKOUT? If so, what are the read
> values you get? For example if you fill DSP memory with 01234567, 5555AAAA,
> 76543210 (or some other pattern unique in both lower and upper 16 bit
> halves), what do you see in your FPGA read results?
>
> -Jeff
>
> PS. Please post to the group, not to me.
>
> ----- Original Message ----
> From: Jeff Brower
> To: Don Morgan
> Cc: c...
>
> Sent: Monday, February 4, 2008 11:15:37 AM
> Subject: Re: [c6x] [6727 uhpi]
>
> Don-
>
> > I have HDS1 and HDS2 permanently tied - one to gnd, one to vcc, just as
> the datasheet says.
>
> I've never seen one out of literally dozens of TI DSP data sheets before
> (since 1998) that advised to use the HPI this
> way in multiplexed HPI mode. HDS stands for "host data strobe" -- so use it
> as a data strobe. That's what it's there
> for.
>
> > I set the address, data and hcntl data on the pins one 1/66MHz period
> before asserting HCS-. There are 4 conditions
> > listed in the UHPI application note and data sheet relating to HRDY that
> can occur. All these conditions are met. When
> > necessary, and HRDY is asserted the FPGA waits until it is de-asserted. I
> have never seen a time when this does not
> > occur. Basically, just about any read is likely to cause a HRDY hit and it
> does and the FPGA waits. because of the
> > FIFOs the writes unless they exceed the 8 level fifo. Of course writes and
> reads of the HPI registers shouldn't cause
> > a HRDY and I have not seen one.
> >
> > I appologize but I don't really understand what you are saying below:
> disable HDS, enable HDS- why?
>
> I just said that because of your weird way of using the HPI. If you read my
> earlier e-mails I said clearly to enable
> HCS, check for HRDY, assert HNCTL, HR/W (and data if writing), and then
> strobe the darn thing. With the data strobe
> signal. Is that difficult with your FPGA design? Did you not run the HDS
> lines to the FPGA?
>
> > If you look at the schematic of the internal strobe, you will see that
> HDS1 and HDS2 are tied to an XOR gate and this
> > gate is AND'd with HCS-.
>
> Exactly, and if you look at the TI reference designs they typically show
> HDS1 tied high and HDS2 used as the external
> /HDS (active low).
>
> -Jeff
>
> > Forgive me, I am not trying to be obtuse and I do appreciate your help. I
> have put the
> > HDS pins back. It doesn't solve the problem.
> >
> > Don
> >
> >
> > ----- Original Message ----
> > From: Jeff Brower
> > To: Don Morgan
> > Cc: c...
> > Sent: Monday, February 4, 2008 8:55:03 AM
> > Subject: Re: [c6x] [6727 uhpi]
> >
> > Don-
> >
> >> I was going by note G at the bottom of p.56 of the datasheet: Only
> >> required if needed for strobe timing. Not required if CS- meets strobe
> >> timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
> >> have them tied opposite.
> >
> > Ok, but in that case you'd have to:
> >
> > -disable HDS, enable HCS, check HRDY
> > -disable HCS, enable HDS
> > -use HCS as the strobe
> >
> > Otherwise the moment you turn on HCS, you're causing an access, whether
> the HPI is ready or not. Maybe that would
> > still work and you could sit on HRDY, but I think you could have problems,
> as it would depend on whether the HPI can
> > accept an access initiated (strobed) *prior* to HRDY valid. Does the data
> sheet say anything about that case?
> >
> > -Jeff
> >
> >> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
> >>
> >>> Don-
> >>>
> >>>> I am sorry. I sent the whole program because I wanted to make sure I
> >>>> didn't edit something out that was actually the problem and mislead
> >>>> people. Instead, I gave you too much extraneous stuff. That short bit
> >>>> of code to write external memory was just put there to prove I could
> >>>> and to set up the values before the FPGA wrote to those same
> >>>> locations. FPGA writes occur but sometimes I am missing the high half
> >>>> of the word and sometimes the low half with the pieces of the words
> >>>> that make it concatenated to form new 'words' in this area. The HPI
> >>>> write pointers appear to increment correctly, however (very confusing
> >>>> for me) but I can see that either it didn't see the HHWIL and or
> >>>> didn't actually post-increment.
> >>>>
> >>>> Please ignore the write to external RAM.
> >>>>
> >>>> Yes, I am writing to external RAM with the FPGA, but the same problem
> >>>> exists if I write to 0x10000000, internal ram.
> >>>>
> >>>> I can see the Hrdy working correctly relative to HCS-. All four
> >>>> conditions described in the data sheet and the application notes on
> >>>> UHPI have been tested and work as expected with the HRDY either
> >>>> accepting the data (staying low) or stalling the FPGA (going high)
> >>>> just as described.
> >>>>
> >>>> Because the timing (according to the logic analyzer) met all the
> >>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
> >>>> is permanently high with HDS1 high and HDS2 low. The read/write
> >>>> strobe
> >>>> occurs well before HCS-. But I will make some more tests.
> >>>>
> >>>> I have not proven that the PLL is truly set to 250MHz with a scope-
> >>>> this is a very good question. I did walk through the setup to see the
> >>>> multipliers were correct and the clocks were also correctly sync'd -
> >>>> that is with the special sync registers. I will try to check that
> >>>> today. Thanks.
> >>>>
> >>>> I will get back to you as soon as I can get some data.
> >>>
> >>> How can you get away without using data strobe (either HDS1 or
> >>> HDS2)? I don't think the data sheet permits you to do
> >>> this -- HR/W should be asserted and stable (meeting minimum setup
> >>> time) *prior* to internal HDS, and all timing should
> >>> be relative to internal HDS active.
> >>>
> >>> Also, I would suggest you test HPI read first, then you cut the
> >>> problem in half. Your DSP test code can initialize
> >>> some internal mem data, then FPGA reads it. Make sure you can do
> >>> all combinations of read (various addresses,
> >>> autoincrement, non-autoincrement, etc) then test HPI writes.
> >>>
> >>> I don't know details of C672x as I do C671x, but I would have
> >>> thought that internal mem starts at zero rather than
> >>> 0x10000000. I'm sure you've checked this, but I am curious though,
> >>> what memory is at location 0x0? The older C620x
> >>> devices split internal data and program mem, and program mem started
> >>> at 0x0, so maybe something like that is going on.
> >>>
> >>> -Jeff
> >>>
> >>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
> >>>>
> >>>>> Woshi Don-
> >>>>>
> >>>>> It's not clear what you're doing. The HPI peripheral is a slave, so
> >>>>> you must be using the FPGA to read/write 6727
> >>>>> memory, right? So you are reading/writing memory at 0x80000000?
> >>>>> First, that's not internal memory... second you are
> >>>>> expecting the FPGA to read values 0 to 15?
> >>>>>
> >>>>> Is this correct? If so, I suggest a) that you test internal memory
> >>>>> first, and b) you use some test values that allow
> >>>>> you to "see" what's going on more clearly, for example values that
> >>>>> increment in both low and high 16-bit halves.
> >>>>>
> >>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
> >>>>> to checking HRDY? What is the FPGA clock and how
> >>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
> >>>>> setting HCNTL and H/RW before strobing /HDS? How
> >>>>> sure are you the internal clock rate is truly 250 MHz? Did you
> >>>>> measure any of the CLKOUT signals? If the internal
> >>>>> rate exceeds the spec that can either mess up the DSP internal
> >>>>> circuitry (HPI results undefined) or exceed your FPGA
> >>>>> timing.
> >>>>>
> >>>>> -Jeff
> >>>>>
> >>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
> >>>>> fpga
> >>>>>> meets all the requirements for the DSP (from what I can see on a
> >>>>> logic
> >>>>>> analyzer) so I am only using the read/write, hcntl, and ready
> >>>>>> lines,
> >>>>>> in addition to the 16-bits of data for half-word mode. the byte
> >>>>>> enables are tied active, the hds pins are set one high the other
> >>>>> low,
> >>>>>> the int- is tied high, as is the has line. I also have those made
> >>>>> GPIO
> >>>>>> pins so that they will see the default anyway.
> >>>>>>
> >>>>>> I have it set for half-word mode and I am not using HAS. I have the
> >>>>>> PLL set to 250MHz.
> >>>>>>
> >>>>>> My problem is that I can read and write but not consistently.
> >>>>>> sometimes, I get the whole 32-bit word transfered, often only half
> >>>>> of
> >>>>>> it. The auto-increment does seem to register the correct count
> >>>>>> but I
> >>>>>> only see half of the tranfer in the ram sometimes. It is not
> >>>>> consistent.
> >>>>>>
> >>>>>> I am sending the simple set up code I have for test, probably I
> >>>>>> have
> >>>>>> something set wrong?
> >>>>>>
> >>>>>> Or just any thoughts?
> >>>>>>
> >>>>>> #define CHIP_6713
> >>>>>> #include
> >>>>>> #include
> >>>>>> //#include "mcasp1.h"
> >>>>>> #include
> >>>>>>
> >>>>>> unsigned int * CfgHpi;
> >>>>>> unsigned int * Hpic;
> >>>>>> unsigned int * Gpioen;
> >>>>>> unsigned int * Hpiaw;
> >>>>>> unsigned int * Hpiar;
> >>>>>> unsigned int * memory;
> >>>>>> unsigned int * pwremu;
> >>>>>> unsigned int * memory;
> >>>>>> unsigned int * adrmsb;
> >>>>>> unsigned int * adrnmsb;
> >>>>>> /*---------- --------- --------- --------- --------- --------- ---*/
> >>>>>>
> >>>>>> /
> >>>>> ************ ********* ********* ********* ********* *********
> ********* ****/
> >>>>>> /* Main */
> >>>>>> /
> >>>>> ************ ********* ********* ********* ********* *********
> ********* ****/
> >>>>>> void main() {
> >>>>>>
> >>>>>>
> >>>>>> int i,port;
> >>>>>> int error = 0;
> >>>>>>
> >>>>>> init_pll();
> >>>>>>
> >>>>>> CfgHpi = (unsigned int *)0x40000008;
> >>>>>> Gpioen = (unsigned int *) 0x4300000c;
> >>>>>> Hpic = (unsigned int *)0x43000030;
> >>>>>> Hpiaw = (unsigned int *) 0x43000034;
> >>>>>> Hpiar = (unsigned int *) 0x43000038;
> >>>>>> memory = (unsigned int *) 0x80000000;
> >>>>>> pwremu = (unsigned int *) 0x43000004;
> >>>>>> adrmsb = (unsigned int *) 0x4000000c;
> >>>>>> adrnmsb = (unsigned int *) 0x40000010;
> >>>>>> memory = (unsigned int *) 0x80000000;
> >>>>>> /* Configuration for DEVCFG register */
> >>>>>> *CfgHpi = 0x2;
> >>>>>> *adrmsb = 0x80;
> >>>>>> *adrnmsb = 0x0;
> >>>>>> *CfgHpi = 0x3;
> >>>>>> *Hpic = 0x00;
> >>>>>> *Gpioen = 0x1e4c;
> >>>>>> *pwremu = 0x1;
> >>>>>>
> >>>>>> for(i=0;i<16; i++){
> >>>>>> *memory++ = i;
> >>>>>> }
> >>>>>>
> >>>>>> while(1);
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Don-

Did you get it working?

I had a chance to look closer at the C6727 data sheet and UHPI Ref Guide.

I disagree with the note:

"Only required if needed for strobe timing. Not required if
CS meets strobe timing requirements. Tie UHPI_HDS[2] and
UHPI_HDS[1] opposite. For more information, see Figure
4-14."

because, if the design does that, then it's possible to strobe the HPI prior to HRDY
being active. This is demonstrated by Figure 4-14, which shows HRDY as not available
until CS goes low. The data sheet doesn't define results if that happens, so I don't
know if that would cause the HPI to lock up or get out of sync, but I wouldn't risk
it.

I have submitted a TI hotline request to ask them about the validity of the note.

-Jeff

-------- Original Message --------
Subject: Re: [c6x] [6727 uhpi]
Date: Mon, 04 Feb 2008 13:26:42 -0600
From: Jeff Brower
Organization: Signalogic, Inc
To: Don Morgan
CC: c...

Don-
> I have no interest in arguing with you, I just refer you to the 6727b data sheet
> (p56, note G) and the timing diagrams (check the timing number too-> specifically
> #37 and #4, please), which are met.
>

That's fine, and I have no interest in having the data sheet read back to me after
using various TI DSP HPIs for 10 years. There can be many notes in the data sheet,
some even conflicting or inaccurate. That's why groups like this exist, so people
can ask questions and get straight answers based on experience.
> It is just likely that I didn't understand some part of it. It has happened before.
>
> I have re-introduced the HDS lines and I will use them as instructed.
>
> The problem still exists.
>

If the problem still exists after using HDS as the data strobe, then a) did you try
the read test that I suggested, b) did you ensure you are reading from internal mem,
and c) did you measure CLKOUT? If so, what are the read values you get? For example
if you fill DSP memory with 01234567, 5555AAAA, 76543210 (or some other pattern
unique in both lower and upper 16 bit halves), what do you see in your FPGA read
results?

-Jeff

PS. Please post to the group, not to me.
> ----- Original Message ----
> From: Jeff Brower
> To: Don Morgan
> Cc: c...
> Sent: Monday, February 4, 2008 11:15:37 AM
> Subject: Re: [c6x] [6727 uhpi]
>
> Don-
>
> > I have HDS1 and HDS2 permanently tied - one to gnd, one to vcc, just as the
> datasheet says.
>
> I've never seen one out of literally dozens of TI DSP data sheets before (since
> 1998) that advised to use the HPI this
> way in multiplexed HPI mode. HDS stands for "host data strobe" -- so use it as a
> data strobe. That's what it's there
> for.
>
> > I set the address, data and hcntl data on the pins one 1/66MHz period before
> asserting HCS-. There are 4 conditions
> > listed in the UHPI application note and data sheet relating to HRDY that can
> occur. All these conditions are met. When
> > necessary, and HRDY is asserted the FPGA waits until it is de-asserted. I have
> never seen a time when this does not
> > occur. Basically, just about any read is likely to cause a HRDY hit and it does
> and the FPGA waits. because of the
> > FIFOs the writes unless they exceed the 8 level fifo. Of course writes and reads
> of the HPI registers shouldn't cause
> > a HRDY and I have not seen one.
> >
> > I appologize but I don't really understand what you are saying below: disable
> HDS, enable HDS- why?
>
> I just said that because of your weird way of using the HPI. If you read my
> earlier e-mails I said clearly to enable
> HCS, check for HRDY, assert HNCTL, HR/W (and data if writing), and then strobe the
> darn thing. With the data strobe
> signal. Is that difficult with your FPGA design? Did you not run the HDS lines to
> the FPGA?
>
> > If you look at the schematic of the internal strobe, you will see that HDS1 and
> HDS2 are tied to an XOR gate and this
> > gate is AND'd with HCS-.
>
> Exactly, and if you look at the TI reference designs they typically show HDS1 tied
> high and HDS2 used as the external
> /HDS (active low).
>
> -Jeff
>
> > Forgive me, I am not trying to be obtuse and I do appreciate your help. I have
> put the
> > HDS pins back. It doesn't solve the problem.
> >
> > Don
> >
> >
> > ----- Original Message ----
> > From: Jeff Brower
> > To: Don Morgan
> > Cc: c...
> > Sent: Monday, February 4, 2008 8:55:03 AM
> > Subject: Re: [c6x] [6727 uhpi]
> >
> > Don-
> >
> >> I was going by note G at the bottom of p.56 of the datasheet: Only
> >> required if needed for strobe timing. Not required if CS- meets strobe
> >> timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
> >> have them tied opposite.
> >
> > Ok, but in that case you'd have to:
> >
> > -disable HDS, enable HCS, check HRDY
> > -disable HCS, enable HDS
> > -use HCS as the strobe
> >
> > Otherwise the moment you turn on HCS, you're causing an access, whether the HPI
> is ready or not. Maybe that would
> > still work and you could sit on HRDY, but I think you could have problems, as it
> would depend on whether the HPI can
> > accept an access initiated (strobed) *prior* to HRDY valid. Does the data sheet
> say anything about that case?
> >
> > -Jeff
> >
> >> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
> >>
> >>> Don-
> >>>
> >>>> I am sorry. I sent the whole program because I wanted to make sure I
> >>>> didn't edit something out that was actually the problem and mislead
> >>>> people. Instead, I gave you too much extraneous stuff. That short bit
> >>>> of code to write external memory was just put there to prove I could
> >>>> and to set up the values before the FPGA wrote to those same
> >>>> locations. FPGA writes occur but sometimes I am missing the high half
> >>>> of the word and sometimes the low half with the pieces of the words
> >>>> that make it concatenated to form new 'words' in this area. The HPI
> >>>> write pointers appear to increment correctly, however (very confusing
> >>>> for me) but I can see that either it didn't see the HHWIL and or
> >>>> didn't actually post-increment.
> >>>>
> >>>> Please ignore the write to external RAM.
> >>>>
> >>>> Yes, I am writing to external RAM with the FPGA, but the same problem
> >>>> exists if I write to 0x10000000, internal ram.
> >>>>
> >>>> I can see the Hrdy working correctly relative to HCS-. All four
> >>>> conditions described in the data sheet and the application notes on
> >>>> UHPI have been tested and work as expected with the HRDY either
> >>>> accepting the data (staying low) or stalling the FPGA (going high)
> >>>> just as described.
> >>>>
> >>>> Because the timing (according to the logic analyzer) met all the
> >>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
> >>>> is permanently high with HDS1 high and HDS2 low. The read/write
> >>>> strobe
> >>>> occurs well before HCS-. But I will make some more tests.
> >>>>
> >>>> I have not proven that the PLL is truly set to 250MHz with a scope-
> >>>> this is a very good question. I did walk through the setup to see the
> >>>> multipliers were correct and the clocks were also correctly sync'd -
> >>>> that is with the special sync registers. I will try to check that
> >>>> today. Thanks.
> >>>>
> >>>> I will get back to you as soon as I can get some data.
> >>>
> >>> How can you get away without using data strobe (either HDS1 or
> >>> HDS2)? I don't think the data sheet permits you to do
> >>> this -- HR/W should be asserted and stable (meeting minimum setup
> >>> time) *prior* to internal HDS, and all timing should
> >>> be relative to internal HDS active.
> >>>
> >>> Also, I would suggest you test HPI read first, then you cut the
> >>> problem in half. Your DSP test code can initialize
> >>> some internal mem data, then FPGA reads it. Make sure you can do
> >>> all combinations of read (various addresses,
> >>> autoincrement, non-autoincrement, etc) then test HPI writes.
> >>>
> >>> I don't know details of C672x as I do C671x, but I would have
> >>> thought that internal mem starts at zero rather than
> >>> 0x10000000. I'm sure you've checked this, but I am curious though,
> >>> what memory is at location 0x0? The older C620x
> >>> devices split internal data and program mem, and program mem started
> >>> at 0x0, so maybe something like that is going on.
> >>>
> >>> -Jeff
> >>>
> >>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
> >>>>
> >>>>> Woshi Don-
> >>>>>
> >>>>> It's not clear what you're doing. The HPI peripheral is a slave, so
> >>>>> you must be using the FPGA to read/write 6727
> >>>>> memory, right? So you are reading/writing memory at 0x80000000?
> >>>>> First, that's not internal memory... second you are
> >>>>> expecting the FPGA to read values 0 to 15?
> >>>>>
> >>>>> Is this correct? If so, I suggest a) that you test internal memory
> >>>>> first, and b) you use some test values that allow
> >>>>> you to "see" what's going on more clearly, for example values that
> >>>>> increment in both low and high 16-bit halves.
> >>>>>
> >>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
> >>>>> to checking HRDY? What is the FPGA clock and how
> >>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
> >>>>> setting HCNTL and H/RW before strobing /HDS? How
> >>>>> sure are you the internal clock rate is truly 250 MHz? Did you
> >>>>> measure any of the CLKOUT signals? If the internal
> >>>>> rate exceeds the spec that can either mess up the DSP internal
> >>>>> circuitry (HPI results undefined) or exceed your FPGA
> >>>>> timing.
> >>>>>
> >>>>> -Jeff
> >>>>>
> >>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
> >>>>> fpga
> >>>>>> meets all the requirements for the DSP (from what I can see on a
> >>>>> logic
> >>>>>> analyzer) so I am only using the read/write, hcntl, and ready
> >>>>>> lines,
> >>>>>> in addition to the 16-bits of data for half-word mode. the byte
> >>>>>> enables are tied active, the hds pins are set one high the other
> >>>>> low,
> >>>>>> the int- is tied high, as is the has line. I also have those made
> >>>>> GPIO
> >>>>>> pins so that they will see the default anyway.
> >>>>>>
> >>>>>> I have it set for half-word mode and I am not using HAS. I have the
> >>>>>> PLL set to 250MHz.
> >>>>>>
> >>>>>> My problem is that I can read and write but not consistently.
> >>>>>> sometimes, I get the whole 32-bit word transfered, often only half
> >>>>> of
> >>>>>> it. The auto-increment does seem to register the correct count
> >>>>>> but I
> >>>>>> only see half of the tranfer in the ram sometimes. It is not
> >>>>> consistent.
> >>>>>>
> >>>>>> I am sending the simple set up code I have for test, probably I
> >>>>>> have
> >>>>>> something set wrong?
> >>>>>>
> >>>>>> Or just any thoughts?
> >>>>>>
> >>>>>> #define CHIP_6713
> >>>>>> #include
> >>>>>> #include
> >>>>>> //#include "mcasp1.h"
> >>>>>> #include
> >>>>>>
> >>>>>> unsigned int * CfgHpi;
> >>>>>> unsigned int * Hpic;
> >>>>>> unsigned int * Gpioen;
> >>>>>> unsigned int * Hpiaw;
> >>>>>> unsigned int * Hpiar;
> >>>>>> unsigned int * memory;
> >>>>>> unsigned int * pwremu;
> >>>>>> unsigned int * memory;
> >>>>>> unsigned int * adrmsb;
> >>>>>> unsigned int * adrnmsb;
> >>>>>> /*---------- --------- --------- --------- --------- --------- ---*/
> >>>>>>
> >>>>>> /
> >>>>> ************ ********* ********* ********* ********* ********* *********
> ****/
> >>>>>> /* Main */
> >>>>>> /
> >>>>> ************ ********* ********* ********* ********* ********* *********
> ****/
> >>>>>> void main() {
> >>>>>>
> >>>>>>
> >>>>>> int i,port;
> >>>>>> int error = 0;
> >>>>>>
> >>>>>> init_pll();
> >>>>>>
> >>>>>> CfgHpi = (unsigned int *)0x40000008;
> >>>>>> Gpioen = (unsigned int *) 0x4300000c;
> >>>>>> Hpic = (unsigned int *)0x43000030;
> >>>>>> Hpiaw = (unsigned int *) 0x43000034;
> >>>>>> Hpiar = (unsigned int *) 0x43000038;
> >>>>>> memory = (unsigned int *) 0x80000000;
> >>>>>> pwremu = (unsigned int *) 0x43000004;
> >>>>>> adrmsb = (unsigned int *) 0x4000000c;
> >>>>>> adrnmsb = (unsigned int *) 0x40000010;
> >>>>>> memory = (unsigned int *) 0x80000000;
> >>>>>> /* Configuration for DEVCFG register */
> >>>>>> *CfgHpi = 0x2;
> >>>>>> *adrmsb = 0x80;
> >>>>>> *adrnmsb = 0x0;
> >>>>>> *CfgHpi = 0x3;
> >>>>>> *Hpic = 0x00;
> >>>>>> *Gpioen = 0x1e4c;
> >>>>>> *pwremu = 0x1;
> >>>>>>
> >>>>>> for(i=0;i<16; i++){
> >>>>>> *memory++ = i;
> >>>>>> }
> >>>>>>
> >>>>>> while(1);
> Start a New Thread

yes, it is working and without the HDS pins. I put them back in for
test and set them to opposite polarities.
Mike had it right with the overrun. I had the PLL set at about 125MHz
which I thought was enough but when I put it at 250MHz it worked
without a problem. My design doesn't check for the ready until the
next clock edge after the chip select which is well out of harm's way,
so I really doubt there will be a problem.
Don

On 2008, Feb, 7, at 3:37 PM, Jeff Brower wrote:

> Don-
> Did you get it working?
>
> I had a chance to look closer at the C6727 data sheet and UHPI Ref
> Guide.
>
> I disagree with the note:
>
> "Only required if needed for strobe timing. Not required if
> CS meets strobe timing requirements. Tie UHPI_HDS[2] and
> UHPI_HDS[1] opposite. For more information, see Figure
> 4-14."
>
> because, if the design does that, then it's possible to strobe the
> HPI prior to HRDY being active. This is demonstrated by Figure
> 4-14, which shows HRDY as not available until CS goes low. The data
> sheet doesn't define results if that happens, so I don't know if
> that would cause the HPI to lock up or get out of sync, but I
> wouldn't risk it.
>
> I have submitted a TI hotline request to ask them about the validity
> of the note.
>
> -Jeff
>
> -------- Original Message --------
> Subject: Re: [c6x] [6727 uhpi]
> Date: Mon, 04 Feb 2008 13:26:42 -0600
> From: Jeff Brower
> Organization: Signalogic, Inc
> To: Don Morgan
> CC: c...
>
> Don-
>> I have no interest in arguing with you, I just refer you to the
>> 6727b data sheet (p56, note G) and the timing diagrams (check the
>> timing number too-> specifically #37 and #4, please), which are met.
>
> That's fine, and I have no interest in having the data sheet read
> back to me after using various TI DSP HPIs for 10 years. There can
> be many notes in the data sheet, some even conflicting or
> inaccurate. That's why groups like this exist, so people can ask
> questions and get straight answers based on experience.
>> It is just likely that I didn't understand some part of it. It has
>> happened before.
>>
>> I have re-introduced the HDS lines and I will use them as instructed.
>>
>> The problem still exists.
>
> If the problem still exists after using HDS as the data strobe, then
> a) did you try the read test that I suggested, b) did you ensure you
> are reading from internal mem, and c) did you measure CLKOUT? If
> so, what are the read values you get? For example if you fill DSP
> memory with 01234567, 5555AAAA, 76543210 (or some other pattern
> unique in both lower and upper 16 bit halves), what do you see in
> your FPGA read results?
>
> -Jeff
>
> PS. Please post to the group, not to me.
>> ----- Original Message ----
>> From: Jeff Brower
>> To: Don Morgan
>> Cc: c...
>> Sent: Monday, February 4, 2008 11:15:37 AM
>> Subject: Re: [c6x] [6727 uhpi]
>> Don-
>>
>> > I have HDS1 and HDS2 permanently tied - one to gnd, one to vcc,
>> just as the datasheet says.
>>
>> I've never seen one out of literally dozens of TI DSP data sheets
>> before (since 1998) that advised to use the HPI this
>> way in multiplexed HPI mode. HDS stands for "host data strobe" --
>> so use it as a data strobe. That's what it's there
>> for.
>>
>> > I set the address, data and hcntl data on the pins one 1/66MHz
>> period before asserting HCS-. There are 4 conditions
>> > listed in the UHPI application note and data sheet relating to
>> HRDY that can occur. All these conditions are met. When
>> > necessary, and HRDY is asserted the FPGA waits until it is de-
>> asserted. I have never seen a time when this does not
>> > occur. Basically, just about any read is likely to cause a HRDY
>> hit and it does and the FPGA waits. because of the
>> > FIFOs the writes unless they exceed the 8 level fifo. Of course
>> writes and reads of the HPI registers shouldn't cause
>> > a HRDY and I have not seen one.
>> >
>> > I appologize but I don't really understand what you are saying
>> below: disable HDS, enable HDS- why?
>>
>> I just said that because of your weird way of using the HPI. If
>> you read my earlier e-mails I said clearly to enable
>> HCS, check for HRDY, assert HNCTL, HR/W (and data if writing), and
>> then strobe the darn thing. With the data strobe
>> signal. Is that difficult with your FPGA design? Did you not run
>> the HDS lines to the FPGA?
>>
>> > If you look at the schematic of the internal strobe, you will see
>> that HDS1 and HDS2 are tied to an XOR gate and this
>> > gate is AND'd with HCS-.
>>
>> Exactly, and if you look at the TI reference designs they typically
>> show HDS1 tied high and HDS2 used as the external
>> /HDS (active low).
>>
>> -Jeff
>>
>> > Forgive me, I am not trying to be obtuse and I do appreciate your
>> help. I have put the
>> > HDS pins back. It doesn't solve the problem.
>> >
>> > Don
>> >
>> >
>> > ----- Original Message ----
>> > From: Jeff Brower
>> > To: Don Morgan
>> > Cc: c...
>> > Sent: Monday, February 4, 2008 8:55:03 AM
>> > Subject: Re: [c6x] [6727 uhpi]
>> >
>> > Don-
>> >
>> >> I was going by note G at the bottom of p.56 of the datasheet: Only
>> >> required if needed for strobe timing. Not required if CS- meets
>> strobe
>> >> timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
>> >> have them tied opposite.
>> >
>> > Ok, but in that case you'd have to:
>> >
>> > -disable HDS, enable HCS, check HRDY
>> > -disable HCS, enable HDS
>> > -use HCS as the strobe
>> >
>> > Otherwise the moment you turn on HCS, you're causing an access,
>> whether the HPI is ready or not. Maybe that would
>> > still work and you could sit on HRDY, but I think you could have
>> problems, as it would depend on whether the HPI can
>> > accept an access initiated (strobed) *prior* to HRDY valid. Does
>> the data sheet say anything about that case?
>> >
>> > -Jeff
>> >
>> >> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
>> >>
>> >>> Don-
>> >>>
>> >>>> I am sorry. I sent the whole program because I wanted to make
>> sure I
>> >>>> didn't edit something out that was actually the problem and
>> mislead
>> >>>> people. Instead, I gave you too much extraneous stuff. That
>> short bit
>> >>>> of code to write external memory was just put there to prove I
>> could
>> >>>> and to set up the values before the FPGA wrote to those same
>> >>>> locations. FPGA writes occur but sometimes I am missing the
>> high half
>> >>>> of the word and sometimes the low half with the pieces of the
>> words
>> >>>> that make it concatenated to form new 'words' in this area.
>> The HPI
>> >>>> write pointers appear to increment correctly, however (very
>> confusing
>> >>>> for me) but I can see that either it didn't see the HHWIL and or
>> >>>> didn't actually post-increment.
>> >>>>
>> >>>> Please ignore the write to external RAM.
>> >>>>
>> >>>> Yes, I am writing to external RAM with the FPGA, but the same
>> problem
>> >>>> exists if I write to 0x10000000, internal ram.
>> >>>>
>> >>>> I can see the Hrdy working correctly relative to HCS-. All four
>> >>>> conditions described in the data sheet and the application
>> notes on
>> >>>> UHPI have been tested and work as expected with the HRDY either
>> >>>> accepting the data (staying low) or stalling the FPGA (going
>> high)
>> >>>> just as described.
>> >>>>
>> >>>> Because the timing (according to the logic analyzer) met all the
>> >>>> conditions in the data sheet, I do not use HAS- or HDS1 or
>> HDS2, HAS-
>> >>>> is permanently high with HDS1 high and HDS2 low. The read/write
>> >>>> strobe
>> >>>> occurs well before HCS-. But I will make some more tests.
>> >>>>
>> >>>> I have not proven that the PLL is truly set to 250MHz with a
>> scope-
>> >>>> this is a very good question. I did walk through the setup to
>> see the
>> >>>> multipliers were correct and the clocks were also correctly
>> sync'd -
>> >>>> that is with the special sync registers. I will try to check
>> that
>> >>>> today. Thanks.
>> >>>>
>> >>>> I will get back to you as soon as I can get some data.
>> >>>
>> >>> How can you get away without using data strobe (either HDS1 or
>> >>> HDS2)? I don't think the data sheet permits you to do
>> >>> this -- HR/W should be asserted and stable (meeting minimum setup
>> >>> time) *prior* to internal HDS, and all timing should
>> >>> be relative to internal HDS active.
>> >>>
>> >>> Also, I would suggest you test HPI read first, then you cut the
>> >>> problem in half. Your DSP test code can initialize
>> >>> some internal mem data, then FPGA reads it. Make sure you can do
>> >>> all combinations of read (various addresses,
>> >>> autoincrement, non-autoincrement, etc) then test HPI writes.
>> >>>
>> >>> I don't know details of C672x as I do C671x, but I would have
>> >>> thought that internal mem starts at zero rather than
>> >>> 0x10000000. I'm sure you've checked this, but I am curious
>> though,
>> >>> what memory is at location 0x0? The older C620x
>> >>> devices split internal data and program mem, and program mem
>> started
>> >>> at 0x0, so maybe something like that is going on.
>> >>>
>> >>> -Jeff
>> >>>
>> >>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>> >>>>
>> >>>>> Woshi Don-
>> >>>>>
>> >>>>> It's not clear what you're doing. The HPI peripheral is a
>> slave, so
>> >>>>> you must be using the FPGA to read/write 6727
>> >>>>> memory, right? So you are reading/writing memory at 0x80000000?
>> >>>>> First, that's not internal memory... second you are
>> >>>>> expecting the FPGA to read values 0 to 15?
>> >>>>>
>> >>>>> Is this correct? If so, I suggest a) that you test internal
>> memory
>> >>>>> first, and b) you use some test values that allow
>> >>>>> you to "see" what's going on more clearly, for example values
>> that
>> >>>>> increment in both low and high 16-bit halves.
>> >>>>>
>> >>>>> Also a couple of questions -- is your FPGA code setting /HCS
>> prior
>> >>>>> to checking HRDY? What is the FPGA clock and how
>> >>>>> many clock cycles a) after /HCS and before checking HRDY, b)
>> after
>> >>>>> setting HCNTL and H/RW before strobing /HDS? How
>> >>>>> sure are you the internal clock rate is truly 250 MHz? Did you
>> >>>>> measure any of the CLKOUT signals? If the internal
>> >>>>> rate exceeds the spec that can either mess up the DSP internal
>> >>>>> circuitry (HPI results undefined) or exceed your FPGA
>> >>>>> timing.
>> >>>>>
>> >>>>> -Jeff
>> >>>>>
>> >>>>>> I am using the DSP as a peripheral to an FPGA. the timing on
>> the
>> >>>>> fpga
>> >>>>>> meets all the requirements for the DSP (from what I can see
>> on a
>> >>>>> logic
>> >>>>>> analyzer) so I am only using the read/write, hcntl, and ready
>> >>>>>> lines,
>> >>>>>> in addition to the 16-bits of data for half-word mode. the
>> byte
>> >>>>>> enables are tied active, the hds pins are set one high the
>> other
>> >>>>> low,
>> >>>>>> the int- is tied high, as is the has line. I also have those
>> made
>> >>>>> GPIO
>> >>>>>> pins so that they will see the default anyway.
>> >>>>>>
>> >>>>>> I have it set for half-word mode and I am not using HAS. I
>> have the
>> >>>>>> PLL set to 250MHz.
>> >>>>>>
>> >>>>>> My problem is that I can read and write but not consistently.
>> >>>>>> sometimes, I get the whole 32-bit word transfered, often
>> only half
>> >>>>> of
>> >>>>>> it. The auto-increment does seem to register the correct count
>> >>>>>> but I
>> >>>>>> only see half of the tranfer in the ram sometimes. It is not
>> >>>>> consistent.
>> >>>>>>
>> >>>>>> I am sending the simple set up code I have for test,
>> probably I
>> >>>>>> have
>> >>>>>> something set wrong?
>> >>>>>>
>> >>>>>> Or just any thoughts?
>> >>>>>>
>> >>>>>> #define CHIP_6713
>> >>>>>> #include
>> >>>>>> #include
>> >>>>>> //#include "mcasp1.h"
>> >>>>>> #include
>> >>>>>>
>> >>>>>> unsigned int * CfgHpi;
>> >>>>>> unsigned int * Hpic;
>> >>>>>> unsigned int * Gpioen;
>> >>>>>> unsigned int * Hpiaw;
>> >>>>>> unsigned int * Hpiar;
>> >>>>>> unsigned int * memory;
>> >>>>>> unsigned int * pwremu;
>> >>>>>> unsigned int * memory;
>> >>>>>> unsigned int * adrmsb;
>> >>>>>> unsigned int * adrnmsb;
>> >>>>>> /*---------- --------- --------- --------- ---------
>> --------- ---*/
>> >>>>>>
>> >>>>>> /
>> >>>>> ************ ********* ********* ********* *********
>> ********* ********* ****/
>> >>>>>> /* Main */
>> >>>>>> /
>> >>>>> ************ ********* ********* ********* *********
>> ********* ********* ****/
>> >>>>>> void main() {
>> >>>>>>
>> >>>>>>
>> >>>>>> int i,port;
>> >>>>>> int error = 0;
>> >>>>>>
>> >>>>>> init_pll();
>> >>>>>>
>> >>>>>> CfgHpi = (unsigned int *)0x40000008;
>> >>>>>> Gpioen = (unsigned int *) 0x4300000c;
>> >>>>>> Hpic = (unsigned int *)0x43000030;
>> >>>>>> Hpiaw = (unsigned int *) 0x43000034;
>> >>>>>> Hpiar = (unsigned int *) 0x43000038;
>> >>>>>> memory = (unsigned int *) 0x80000000;
>> >>>>>> pwremu = (unsigned int *) 0x43000004;
>> >>>>>> adrmsb = (unsigned int *) 0x4000000c;
>> >>>>>> adrnmsb = (unsigned int *) 0x40000010;
>> >>>>>> memory = (unsigned int *) 0x80000000;
>> >>>>>> /* Configuration for DEVCFG register */
>> >>>>>> *CfgHpi = 0x2;
>> >>>>>> *adrmsb = 0x80;
>> >>>>>> *adrnmsb = 0x0;
>> >>>>>> *CfgHpi = 0x3;
>> >>>>>> *Hpic = 0x00;
>> >>>>>> *Gpioen = 0x1e4c;
>> >>>>>> *pwremu = 0x1;
>> >>>>>>
>> >>>>>> for(i=0;i<16; i++){
>> >>>>>> *memory++ = i;
>> >>>>>> }
>> >>>>>>
>> >>>>>> while(1);
>> Start a New Thread

Don-
> yes, it is working and without the HDS pins. I put them back in for test and set
> them to opposite polarities.Mike had it right with the overrun. I had the PLL set
> at about 125MHz which I thought was enough but when I put it at 250MHz it worked
> without a problem. My design doesn't check for the ready until the next clock edge
> after the chip select which is well out of harm's way, so I really doubt there will
> be a problem.

In your design, once you assert CS then you've already strobed the device -- too late
to check for HRDY. My experience has been that HRDY can be ignored until you are
using internal DMA channels. Then it becomes important, as HPI uses a dedicated
internal DMA channel and delays become a concern.

I'll let you know what the Hotline says.

-Jeff
> On 2008, Feb, 7, at 3:37 PM, Jeff Brower wrote:
>
>> Don-
>>
>> Did you get it working?
>>
>> I had a chance to look closer at the C6727 data sheet and UHPI Ref Guide.
>>
>> I disagree with the note:
>>
>> "Only required if needed for strobe timing. Not required if
>> CS meets strobe timing requirements. Tie UHPI_HDS[2] and
>> UHPI_HDS[1] opposite. For more information, see Figure
>> 4-14."
>>
>> because, if the design does that, then it's possible to strobe the HPI prior to
>> HRDY being active. This is demonstrated by Figure 4-14, which shows HRDY as not
>> available until CS goes low. The data sheet doesn't define results if that
>> happens, so I don't know if that would cause the HPI to lock up or get out of
>> sync, but I wouldn't risk it.
>>
>> I have submitted a TI hotline request to ask them about the validity of the note.
>>
>> -Jeff
>>
>> -------- Original Message --------
>>
Subject: Re: [c6x] [6727 uhpi]
Date: Mon, 04 Feb 2008 13:26:42 -0600
From: Jeff Brower
Organization: Signalogic, Inc
To: Don Morgan
CC: c...
>>
>> Don-
>> > I have no interest in arguing with you, I just refer you to the 6727b data sheet
>> > (p56, note G) and the timing diagrams (check the timing number too->
>> > specifically #37 and #4, please), which are met.
>> >
>>
>> That's fine, and I have no interest in having the data sheet read back to me
>> after using various TI DSP HPIs for 10 years. There can be many notes in the
>> data sheet, some even conflicting or inaccurate. That's why groups like this
>> exist, so people can ask questions and get straight answers based on experience.
>> > It is just likely that I didn't understand some part of it. It has happened
>> > before.
>> >
>> > I have re-introduced the HDS lines and I will use them as instructed.
>> >
>> > The problem still exists.
>> >
>>
>> If the problem still exists after using HDS as the data strobe, then a) did you
>> try the read test that I suggested, b) did you ensure you are reading from
>> internal mem, and c) did you measure CLKOUT? If so, what are the read values you
>> get? For example if you fill DSP memory with 01234567, 5555AAAA, 76543210 (or
>> some other pattern unique in both lower and upper 16 bit halves), what do you see
>> in your FPGA read results?
>>
>> -Jeff
>>
>> PS. Please post to the group, not to me.
>> > ----- Original Message ----
>> > From: Jeff Brower
>> > To: Don Morgan
>> > Cc: c...
>> > Sent: Monday, February 4, 2008 11:15:37 AM
>> > Subject: Re: [c6x] [6727 uhpi]
>> >
>> > Don-
>> >
>> > > I have HDS1 and HDS2 permanently tied - one to gnd, one to vcc, just as the
>> > datasheet says.
>> >
>> > I've never seen one out of literally dozens of TI DSP data sheets before (since
>> > 1998) that advised to use the HPI this
>> > way in multiplexed HPI mode. HDS stands for "host data strobe" -- so use it as
>> > a data strobe. That's what it's there
>> > for.
>> >
>> > > I set the address, data and hcntl data on the pins one 1/66MHz period before
>> > asserting HCS-. There are 4 conditions
>> > > listed in the UHPI application note and data sheet relating to HRDY that can
>> > occur. All these conditions are met. When
>> > > necessary, and HRDY is asserted the FPGA waits until it is de-asserted. I have
>> > never seen a time when this does not
>> > > occur. Basically, just about any read is likely to cause a HRDY hit and it
>> > does and the FPGA waits. because of the
>> > > FIFOs the writes unless they exceed the 8 level fifo. Of course writes and
>> > reads of the HPI registers shouldn't cause
>> > > a HRDY and I have not seen one.
>> > >
>> > > I appologize but I don't really understand what you are saying below: disable
>> > HDS, enable HDS- why?
>> >
>> > I just said that because of your weird way of using the HPI. If you read my
>> > earlier e-mails I said clearly to enable
>> > HCS, check for HRDY, assert HNCTL, HR/W (and data if writing), and then strobe
>> > the darn thing. With the data strobe
>> > signal. Is that difficult with your FPGA design? Did you not run the HDS lines
>> > to the FPGA?
>> >
>> > > If you look at the schematic of the internal strobe, you will see that HDS1
>> > and HDS2 are tied to an XOR gate and this
>> > > gate is AND'd with HCS-.
>> >
>> > Exactly, and if you look at the TI reference designs they typically show HDS1
>> > tied high and HDS2 used as the external
>> > /HDS (active low).
>> >
>> > -Jeff
>> >
>> > > Forgive me, I am not trying to be obtuse and I do appreciate your help. I have
>> > put the
>> > > HDS pins back. It doesn't solve the problem.
>> > >
>> > > Don
>> > >
>> > >
>> > > ----- Original Message ----
>> > > From: Jeff Brower
>> > > To: Don Morgan
>> > > Cc: c...
>> > > Sent: Monday, February 4, 2008 8:55:03 AM
>> > > Subject: Re: [c6x] [6727 uhpi]
>> > >
>> > > Don-
>> > >
>> > >> I was going by note G at the bottom of p.56 of the datasheet: Only
>> > >> required if needed for strobe timing. Not required if CS- meets strobe
>> > >> timing requirements. The UHPI_HDS[2]- and HUPI_HDS[1]- opposite. I
>> > >> have them tied opposite.
>> > >
>> > > Ok, but in that case you'd have to:
>> > >
>> > > -disable HDS, enable HCS, check HRDY
>> > > -disable HCS, enable HDS
>> > > -use HCS as the strobe
>> > >
>> > > Otherwise the moment you turn on HCS, you're causing an access, whether the
>> > HPI is ready or not. Maybe that would
>> > > still work and you could sit on HRDY, but I think you could have problems, as
>> > it would depend on whether the HPI can
>> > > accept an access initiated (strobed) *prior* to HRDY valid. Does the data
>> > sheet say anything about that case?
>> > >
>> > > -Jeff
>> > >
>> > >> On 2008, Feb, 4, at 8:03 AM, Jeff Brower wrote:
>> > >>
>> > >>> Don-
>> > >>>
>> > >>>> I am sorry. I sent the whole program because I wanted to make sure I
>> > >>>> didn't edit something out that was actually the problem and mislead
>> > >>>> people. Instead, I gave you too much extraneous stuff. That short bit
>> > >>>> of code to write external memory was just put there to prove I could
>> > >>>> and to set up the values before the FPGA wrote to those same
>> > >>>> locations. FPGA writes occur but sometimes I am missing the high half
>> > >>>> of the word and sometimes the low half with the pieces of the words
>> > >>>> that make it concatenated to form new 'words' in this area. The HPI
>> > >>>> write pointers appear to increment correctly, however (very confusing
>> > >>>> for me) but I can see that either it didn't see the HHWIL and or
>> > >>>> didn't actually post-increment.
>> > >>>>
>> > >>>> Please ignore the write to external RAM.
>> > >>>>
>> > >>>> Yes, I am writing to external RAM with the FPGA, but the same problem
>> > >>>> exists if I write to 0x10000000, internal ram.
>> > >>>>
>> > >>>> I can see the Hrdy working correctly relative to HCS-. All four
>> > >>>> conditions described in the data sheet and the application notes on
>> > >>>> UHPI have been tested and work as expected with the HRDY either
>> > >>>> accepting the data (staying low) or stalling the FPGA (going high)
>> > >>>> just as described.
>> > >>>>
>> > >>>> Because the timing (according to the logic analyzer) met all the
>> > >>>> conditions in the data sheet, I do not use HAS- or HDS1 or HDS2, HAS-
>> > >>>> is permanently high with HDS1 high and HDS2 low. The read/write
>> > >>>> strobe
>> > >>>> occurs well before HCS-. But I will make some more tests.
>> > >>>>
>> > >>>> I have not proven that the PLL is truly set to 250MHz with a scope-
>> > >>>> this is a very good question. I did walk through the setup to see the
>> > >>>> multipliers were correct and the clocks were also correctly sync'd -
>> > >>>> that is with the special sync registers. I will try to check that
>> > >>>> today. Thanks.
>> > >>>>
>> > >>>> I will get back to you as soon as I can get some data.
>> > >>>
>> > >>> How can you get away without using data strobe (either HDS1 or
>> > >>> HDS2)? I don't think the data sheet permits you to do
>> > >>> this -- HR/W should be asserted and stable (meeting minimum setup
>> > >>> time) *prior* to internal HDS, and all timing should
>> > >>> be relative to internal HDS active.
>> > >>>
>> > >>> Also, I would suggest you test HPI read first, then you cut the
>> > >>> problem in half. Your DSP test code can initialize
>> > >>> some internal mem data, then FPGA reads it. Make sure you can do
>> > >>> all combinations of read (various addresses,
>> > >>> autoincrement, non-autoincrement, etc) then test HPI writes.
>> > >>>
>> > >>> I don't know details of C672x as I do C671x, but I would have
>> > >>> thought that internal mem starts at zero rather than
>> > >>> 0x10000000. I'm sure you've checked this, but I am curious though,
>> > >>> what memory is at location 0x0? The older C620x
>> > >>> devices split internal data and program mem, and program mem started
>> > >>> at 0x0, so maybe something like that is going on.
>> > >>>
>> > >>> -Jeff
>> > >>>
>> > >>>> On 2008, Feb, 2, at 9:45 PM, Jeff Brower wrote:
>> > >>>>
>> > >>>>> Woshi Don-
>> > >>>>>
>> > >>>>> It's not clear what you're doing. The HPI peripheral is a slave, so
>> > >>>>> you must be using the FPGA to read/write 6727
>> > >>>>> memory, right? So you are reading/writing memory at 0x80000000?
>> > >>>>> First, that's not internal memory... second you are
>> > >>>>> expecting the FPGA to read values 0 to 15?
>> > >>>>>
>> > >>>>> Is this correct? If so, I suggest a) that you test internal memory
>> > >>>>> first, and b) you use some test values that allow
>> > >>>>> you to "see" what's going on more clearly, for example values that
>> > >>>>> increment in both low and high 16-bit halves.
>> > >>>>>
>> > >>>>> Also a couple of questions -- is your FPGA code setting /HCS prior
>> > >>>>> to checking HRDY? What is the FPGA clock and how
>> > >>>>> many clock cycles a) after /HCS and before checking HRDY, b) after
>> > >>>>> setting HCNTL and H/RW before strobing /HDS? How
>> > >>>>> sure are you the internal clock rate is truly 250 MHz? Did you
>> > >>>>> measure any of the CLKOUT signals? If the internal
>> > >>>>> rate exceeds the spec that can either mess up the DSP internal
>> > >>>>> circuitry (HPI results undefined) or exceed your FPGA
>> > >>>>> timing.
>> > >>>>>
>> > >>>>> -Jeff
>> > >>>>>
>> > >>>>>> I am using the DSP as a peripheral to an FPGA. the timing on the
>> > >>>>> fpga
>> > >>>>>> meets all the requirements for the DSP (from what I can see on a
>> > >>>>> logic
>> > >>>>>> analyzer) so I am only using the read/write, hcntl, and ready
>> > >>>>>> lines,
>> > >>>>>> in addition to the 16-bits of data for half-word mode. the byte
>> > >>>>>> enables are tied active, the hds pins are set one high the other
>> > >>>>> low,
>> > >>>>>> the int- is tied high, as is the has line. I also have those made
>> > >>>>> GPIO
>> > >>>>>> pins so that they will see the default anyway.
>> > >>>>>>
>> > >>>>>> I have it set for half-word mode and I am not using HAS. I have the
>> > >>>>>> PLL set to 250MHz.
>> > >>>>>>
>> > >>>>>> My problem is that I can read and write but not consistently.
>> > >>>>>> sometimes, I get the whole 32-bit word transfered, often only half
>> > >>>>> of
>> > >>>>>> it. The auto-increment does seem to register the correct count
>> > >>>>>> but I
>> > >>>>>> only see half of the tranfer in the ram sometimes. It is not
>> > >>>>> consistent.
>> > >>>>>>
>> > >>>>>> I am sending the simple set up code I have for test, probably I
>> > >>>>>> have
>> > >>>>>> something set wrong?
>> > >>>>>>
>> > >>>>>> Or just any thoughts?
>> > >>>>>>
>> > >>>>>> #define CHIP_6713
>> > >>>>>> #include
>> > >>>>>> #include
>> > >>>>>> //#include "mcasp1.h"
>> > >>>>>> #include
>> > >>>>>>
>> > >>>>>> unsigned int * CfgHpi;
>> > >>>>>> unsigned int * Hpic;
>> > >>>>>> unsigned int * Gpioen;
>> > >>>>>> unsigned int * Hpiaw;
>> > >>>>>> unsigned int * Hpiar;
>> > >>>>>> unsigned int * memory;
>> > >>>>>> unsigned int * pwremu;
>> > >>>>>> unsigned int * memory;
>> > >>>>>> unsigned int * adrmsb;
>> > >>>>>> unsigned int * adrnmsb;
>> > >>>>>> /*---------- --------- --------- --------- --------- --------- ---*/
>> > >>>>>>
>> > >>>>>> /
>> > >>>>> ************ ********* ********* ********* ********* ********* *********
>> > ****/
>> > >>>>>> /* Main */
>> > >>>>>> /
>> > >>>>> ************ ********* ********* ********* ********* ********* *********
>> > ****/
>> > >>>>>> void main() {
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> int i,port;
>> > >>>>>> int error = 0;
>> > >>>>>>
>> > >>>>>> init_pll();
>> > >>>>>>
>> > >>>>>> CfgHpi = (unsigned int *)0x40000008;
>> > >>>>>> Gpioen = (unsigned int *) 0x4300000c;
>> > >>>>>> Hpic = (unsigned int *)0x43000030;
>> > >>>>>> Hpiaw = (unsigned int *) 0x43000034;
>> > >>>>>> Hpiar = (unsigned int *) 0x43000038;
>> > >>>>>> memory = (unsigned int *) 0x80000000;
>> > >>>>>> pwremu = (unsigned int *) 0x43000004;
>> > >>>>>> adrmsb = (unsigned int *) 0x4000000c;
>> > >>>>>> adrnmsb = (unsigned int *) 0x40000010;
>> > >>>>>> memory = (unsigned int *) 0x80000000;
>> > >>>>>> /* Configuration for DEVCFG register */
>> > >>>>>> *CfgHpi = 0x2;
>> > >>>>>> *adrmsb = 0x80;
>> > >>>>>> *adrnmsb = 0x0;
>> > >>>>>> *CfgHpi = 0x3;
>> > >>>>>> *Hpic = 0x00;
>> > >>>>>> *Gpioen = 0x1e4c;
>> > >>>>>> *pwremu = 0x1;
>> > >>>>>>
>> > >>>>>> for(i=0;i<16; i++){
>> > >>>>>> *memory++ = i;
>> > >>>>>> }
>> > >>>>>>
>> > >>>>>> while(1);
>> >
>> >
>> > Start a New Thread