• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 1559 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Interfacing C6414/C6416 to AT91SAM9G54 ARM

Victor Kazmirenko
Guru 13202 points
Other Parts Discussed in Thread: OMAP-L138

Hello!

I'd like to ask community advice on the following topic.

We have rather old and fixed digital board with C6414/C6416. On EMIFA we have FPGA, CPLD,  and USB chip. On EMIFB we have 3 parallel flash memory chips of 4MB each. They served as boot source and storage for FPGA images. Because of boot requirements flashes are seen as 8 bit devices, so visible space is 1MB and we use CPLD to produce higher address bits. That solution though proven and works fine is far from elegant. And now we switched to larger FPGA device and run short of flash memory. Somehow we'd like to have more space for DSP and FPGA images and also want to have multiple sets of them. To reload DSP with different program we use two stage bootloader. First stage looks into hardcoded flash memory location for address of primary DSP image. Write to CPLD register is used to create hardware reset strobe to DSP. So this scheme worked pretty well, when we had older smaller FPGA, we could have 2 or 3 images on board, but no more.

So we considering to add ARM controller to that digital board. It will run under some Linux and would have file system on NAND flash. Then ARM could be used to load FPGA chip through SPI port and we free up some space in parallel flashes of the DSP. But then we consider, what if we put all the images on ARM's side? I've heard that booting DSP through HPI is simple and proven process. So we might like to use it. The only concern is that we need more exchange between ARM and DSP. Before we were using USB to connect DSP to the host system. Although USB is kind of host-controller (master-slave) system, we were able to send messages in both directions, from host to DSP and vice versa. Now, when ARM host would be physically present on the board, I wonder, if we can avoid USB at least between ARM and DSP.

Primary requirement is packet exchange with maximum payload of about 256 bytes. We need that both parties can initiate or at least request transfer. Can HPI be used for that purpose? I did not study HPI deeply, I only picked up that it is slave port. Perhaps some GPIO pin can be used to notify ARM host that DSP has something to send. I just guess...

So again, I'd like community comments and advice on this situation.

Thanks in advance.

  • 0
    TI__Guru* 84110 points

    My first recommendation is to move to the OMAP-L138 to get an ARM and a DSP in the same chip. Inter-core communication will be a bit easier than using USB or HPI.

    My second recommendation, if you need more fixed-point DSP MIPS than the C674x in the OMAP-L138 can give you, is to look at the C6678 or one of the derivatives with fewer cores.

    Take a look at the Features section at the beginning of either datasheet. You can find out the memory devices they will interface with and the processing power you get.

    Regards,
    RandyP 

  • 0 in reply to RandyP
    Guru 13202 points

    Thanks for your valuable reply.

    We did not settle with OMAP-L138 for the following reasons. First, as you might noticed I did not mentioned any RAM for C6414(6). Applications we are using fit in its L2 memory. OMAP has less on-chip memory, so we would have to add external memory. That's normal way, but would take extra step to verify DDR operation on PCB. Second concern is that C641x @720 MHz or @1 GHz would outperform OMAP in fixed point math. And main concern is that we have several projects on C6414, which we want to be ported with minimal changes.

    As to C66x family, we already set up a project for next platform with C6670. Its my favourite because of its coprocessors. But that power does not come for free. As I understand, C6670 has no memory interface, except for DDR3, though C6678 has EMIF-16. Coprocessing with FPGA is required step, so we are studying the only option to connect C6670 and FPGA - PCIe. Again, to handle housekeeping jobs we want some kind of ARM to run OS and maintain filesystem. So, there should be PCIe switch. This all is doable, just takes time to deal with all these high speed technologies.

    What we are looking now, is some kind of quick solution, which would not change existing PCB and software applications too much. We have proven system with DSP which I described in the first post. We have verified PCB layout and software for mentioned ARM in separate solution. So I wonder if we could merge them.

    As a last resort I consider to change for HPI booting, but preserve USB interface (yeh, that's would be "cool": two processors on the same board would communicate via USB hub on the external interface board), but at least it is well known to us and proven. I wonder, whether HPI can do similar job for us. 

    Have you heard anything about similar solutions?

    Thanks in advance.

  • 0 in reply to Victor Kazmirenko
    Expert 2655 points

    Greetings,

    Given your state of development, I will recommend the HPI over USB for boot/communication, except it will not port to your next generation based on the 6670.

    Good Luck,

    Sam

  • 0 in reply to Sam Kuzbary
    Guru 13202 points

    Sam,

    Thank your for opinion.

    First, HPI definitely won't go to C6670 project as that part has no HPI. As I mentioned, we are considering PCIe both for boot and communications. As soon as evaluation boards and interfaces come, we would prepare prototyping setup.

    As to C6414/C6416, not too many option available. For booting HPI is a best candidate in my opinion. But I have no idea, how to make bidirectional communications over HPI. Could you please elaborate a little on your suggestion? How does DSP send/notify host of data available for transmission? Set couple of GPIO pins for this kind of interrupts?

    Thanks in advance.

  • 0 in reply to Victor Kazmirenko
    Expert 2655 points

    Greetings,

    For the C6670 to boot and operate over PCIe, I think there is still a need for a secondary boot loader beyond internal ROM to help setup PCIe for such.  Good luck with that.

    For C641x, using HPI for boot is no brainer.

    If a simple non/queueing interface suffice, then once your app is up, you can have a static area in your memory to use for a command register (from Host to DSP), a response register (from DSP to Host), and a buffer[x] of certain size x to use if the command or response do have a body. 

    In your app, a timer ISR (with or without DSP/BIOS) or a general loop, can be used to manage a simple but robust exchange between your Host and DSP.  You can design it in any way fit for a Host-Master/DSP-Slave.

    If an advanced queueing interface is required, you can then built it using DSP/BIOS and the HPI interface Host-to-DSP and DSP-to Host interrupts

    I hope this help.

    Sam

  • 0 in reply to Sam Kuzbary
    Guru 13202 points

    Sam,

    Thanks again.

    With your hint I picked, that host can interrupt DSP by write to control register, and DSP can interrupt host by setting HINT signal. Thus, no extra connections required to make bidirectional interrupt signalling.

    As I understand, we have to develop kind of low level driver, which would serve as transport instead of existing USB driver. As you mentioned, there should be some static buffers for commands and responses, whose absolute location is known to the host. Then to issue a command the host performs HPI writes to command buffer according to HPI sequence and sets Host-to-DSP interrupt to let DSP application know about ingress command. If DSP has response to host, it first prepares response in response buffer and sets HINT interrupt to the host. Host catches the interrupt and performs HPI read from response buffer.

    Am I missing something?

    Just in case, if TI's people may have some example code, could you please share that too?

  • 0 in reply to Victor Kazmirenko
    Expert 2655 points

    Greetings,

    You got the idea.  Now you can poll these command/response registers and do away without host-to-dsp or dsp-to-host interrupts if the traffic throughput is low, and no queueing of many host reqs or dsp reqs.

    If no example code form TI, and you want to go this way, we may take this offline, and you can send me your e-mail so that I can throw at you some example code.

    Good Luck,

    Sam

     

  • 0 in reply to Sam Kuzbary
    Guru 13202 points

    Sam,

    Thank you for sharing opinion. If you don't mind to share some code, please send to "my forum nickname" at google.com.

  • 0 in reply to Victor Kazmirenko
    Expert 2655 points

    Greetings,

    Test e-mail to rrlagic@google.com bounced back.

    Sam