Low cost DSP with a VCP

Reinier,

Although I can name a few devices that have a VCP co-processor, you should be able to do a device parameter search on TI.com. Or you can do a search on TI.com for VCP. I tried those and my internet access seems to be very slow.

In the C64x+ family, the C6455, C6457, C6474 and maybe C6454 have a VCP.

In the C66x family, the C6670 has a VCP.

There may be others in the C5000 and OMAP lines, but I do not know them.

Is this a good start?

Regards,
RandyP

Randy,

Thank you for the reply.

I had a look at the DSP you suggested and I also found the C6655, which has a VCP. I noticed that the C6655 is significantly cheaper than the C64x+ DSP's with a VCP. Do you know why this is the case?

Regards

  Reinier

Reinier,

No, I do not know why it is significantly cheaper. How much more should we charge for it?

Regards,
RandyP

When thinking about C66, do not forget its quite different from "power on - go on" solutions we knew before. Migrating your app to C66 would not be sip of honey either. In my company we are switching from C64 to C66, and that work still far from completion. We chosen C66 to have performance margin for future, though I expect that migration to C6457 would be much easier.

rrlagic,

I would be very interested to hear about the issues you have run into with the migration. Are you moving from a C64x+ to C66? Which devices in particular?

Regards,
RandyP

Hi rrlagic,

We would also be very interested in the typical issues you encountered with migrating from the C64 to the C66 family.

Regards

  Reinier

Hello,

We were using C6414 mainly, but switched to pin compatible  C6416 when TCP and VCP become needed. After a while we faced supply troubles for DSP itself and other components of the system. Because of performance limitations we decided to upgrade. We considered two candidates, already mentioned C6457 and C6670. The first one has larger memory, newer core, however, we did not expect revolutionary performance increase. Among C66 the  C6670 is interesting because of its coprocessors. So we selected C6670.

The very first is booting DSP. We had parallel flash on EMIF B, where we were booting from. Later we tried HPI boot. With C66 neither would work, so we have to try something else.

We had USB chip on EMIF B and used it to communicate with host PC. Also tried HPI. With C66 have to look for something else.

We have FPGA as baseband accelerator. We used EMIF A to communicate with FPGA. With C66 have to look for something else.

We used McBSPs, but its enough to see, that migration is not just replacement. We have to learn, how to use PCIe or SRIO, how to boot and so on.

When first PCB was ordered, I asked hardware designer, how they implemented varivable power supply and power sequencing. Easy to guess, they overlooked both. Ok, we took a look at EVM board and understood, that we cannot make any similar solution. So we considering some smaller CPLD to operate as power sequencer. Not to forget, that RTL code that still to be written and verified.

So, when I as programmer said I like this excellent C6670, I could not imagine, what a difficulties are waiting for us.

rrlagic,

Thank you for the list of items you struggled with in the migration from C6416 to C6670. It definitely makes sense that these items would cause difficulty for you when trying to move from one processor to another. I hope that you have now solved all your problems and you are developing your application on the new platform.

It is very good to not hear anything about porting your application code from the C6416 to C6670, although I am sure there were some struggles with adapting to the new interface for the co-processors.

As was mentioned earlier, the C6657/55 may be a good alternative for someone looking to migrate from one of the C641x DSPs since it has an EMIF and McBSP available. It will deliver significantly higher performance, and it sounds like the price is very attractive.

What can we do to improve the availability of information for your hardware designer? Was the information in the datasheet concerning the power supply requirements hard to find or poorly presented? Was the Hardware Design Guide incomplete when the design was started? Did the hardware designer take into account the requirements for the DDR3 design and layout rules?

Why was the power solution on the EVM a poor choice for your application?

May I recommend a low-cost, low-power MCU like the MSP430 to be used for power sequencing and reset control? The various reset signals need to be applied and removed at the right times with regards to the power supplies, and the clocks may need some managing, too. The Data Manual and the Hardware Design Guide should cover all of that in terms of requirements.

By the way, if your power design uses the LM10010 for the VID controller, you need to change that to the LM10011. We are trying to get all of our documentation showing that to be the case. The LM10011 is a pin-compatible replacement that uses one of the LM10010's NC pins to add a resistor that sets the startup voltage, which needs to be around 300KOhms for the Keystone I family.

Regards,
RandyP

Hello,

Thank you for feedback, though I am sorry for hijacking someone's thread.

As to power itself, I have found really useful thread on the forum. I wish we saw it before we start our design. I wish these two solutions described in some more details, perhaps in a form of minimum required schematic, kind of app note would be ok too. Unfortunately, our h/w designer took care only about voltage ratings, but overlooked Smart Reflex requirement and sequencing. I opened my own eyes only accidentally reading e2e forums.

As to EVM design, it uses FPGA to supply reset signals to DSP. FPGA takes too many inputs, manages modes and DSP configurations, which are useful at study stage, but unnecessary in production. I took a look at RTL code of FPGA, its not a solution one can get familiar fast. So we decided to develop something minimum required with CPLD. Better ideas appreciated. 

As to your suggestion about MSP430, could you please elaborate a little bit more? Actually, we had ARM controller on baseband board, which was responsible for DSP and FPGA booting and interfacing host PC, but removed that one now. We plan to use Cypress USB controller to boot FPGA and plan to boot DSP over Ethernet. All this still at test stage, we have no proven concept yet. Perhaps your input may help to avoid more pitfalls.

I saw recommendation to use LM10011, h/w designer already instructed to do that.

I post nothing about software migration issues. My plan was playing with evaluation board while custom board gets ready. However, C6670 design requirements were so different from what we were used to, so I had to spend all my time traversing forums and reading manuals to give some more explanations to h/w designer. So be sure, my software migration questions would come later :-)