TMS320C6727B EMIF

Hi Alan,
A1) You can boot the parallel NOR flash with either 8bit or 16 bit.
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=SPRS277

Can it be flashed for 8-bits and boot up in 32-bit EMIF mode?

No.

A2) You can boot the NOR flash with 8bit mode and can be changed to 32bit EMIF for other purpose through 2nd stage (user s/w) bootloader.
You need to flash the app with 8bit mode for 8bit flash boot mode.

does the parallel NOR flash need to be wired for 8-bit because the DSP need to boot up in 8-bit EMIF mode then switched to 32-bit mode later for normal operation?

Yes. Also it supports 16bit NOR flash.

Hi Titusrathinaraj,

Thanks, that makes it clear for me. My goal is to move from the VC33 to the C6727B
Maybe I should use SPI0 to boot-load, that way the CPLD for chip selection on EMIF will be simple.

1. Can the SPI NOR flash be erased on the C6727B and still boot from the JTAG?

2. Making GPIO into Address bus pins for normal operation (I’ll need an address bus a[23:0]): 10k on any GPIO pin (Use UHPI_HD[10:0])?

3. JTAG Connector: I’ve not found a diagram of the connection to the JTAG for the C6727B. Can I use what I use on the VC33:
   2 x 7 connector,
   PIN 1: TMS
   PIN 2: TRST_N
   PIN 3: TDI
   PIN 4, 8, 10 & 12: DIGITAL SIGNAL GND
   PIN 5: +3.3V
   PIN 6: NC
   PIN 7: TDO
   PIN 9 & 11 : TCK
   PIN 13: EMU0, 20k pull-up to +3.3V
   PIN 14: EMU1, 20k pull-up to +3.3V

4. External Interrupts: On the VC33 I use 3 external interrupts. The C6727B can have a maximum of 3 external interrupts?
   I would use SPI1_CLK, SPI1_SOMI and SPI1_SIMO as external interrupts?

Thanks,
Alan

Alan,

I recommend reconsidering the C6748. The C6748 has a lot of architectural advantages, and you can get an inexpensive board to test your ideas out before committing to a board design.

Alan Jayson said:

1. Can the SPI NOR flash be erased on the C6727B and still boot from the JTAG?

Yes. For safety sake, have easy access to all the boot pins so you can select a different boot mode if needed.

Alan Jayson said:

2. Making GPIO into Address bus pins for normal operation (I’ll need an address bus a[23:0]): 10k on any GPIO pin (Use UHPI_HD[10:0])?

The datasheet will tell you which pins can be used for GPIO and what those pins have as their default state at reset. This will help you determine the correct pull resistor, if one is needed.

Alan Jayson said:

3. JTAG Connector: I’ve not found a diagram of the connection to the JTAG for the C6727B. Can I use what I use on the VC33?

You can probably use what you had on the VC33. This is a board-level question, not a device question. Are you trying to use an existing C6727B board? Or are you building a new one of your own design?

Alan Jayson said:

4. External Interrupts: On the VC33 I use 3 external interrupts. The C6727B can have a maximum of 3 external interrupts?
I would use SPI1_CLK, SPI1_SOMI and SPI1_SIMO as external interrupts?

Where did you read about the SPI pins being used as external interrupts? There is a section in the datasheet titled "External Interrupts" that will explain which pins are used in this way, if not needed for anything else. Their use through the dMax may be a bit inconvenient, which is another reason to reconsider the C6748. But polling or the dMax may work for your system; you can best determine that.

Regards,
RandyP

1. I’ll have a CPLD select the boot mode so it will be programmable.

2. 6727B Datasheet page 47; Any GPIO-capable pins which can be pulled down at reset can be used.

3. I’m building my own new design.

4. 6727B Datasheet Page 44, For External Interrupts it say to use AMUTEIN.
AMUTEIN0 control on 6727B Datasheet page 75.
AMUTEIN1 control on 6727B Datasheet page 76.
AMUTEIN2 control on 6727B Datasheet page 77.
What do you mean buy inconvenient?
External Interrupts are for getting data from an FPGA (down-converter filters, analog overload & RF wideband rms), data need to be filter in real time on DSP, so interrupts timing is important. All three interrupts come from different clock domains.
6727B Datasheet Page 44 said: (Finally, AMUTEIN events are logically ORed with the McASP transmit and receive error events within the dMAX; therefore, the ISR that processes the dMAX interrupt generated by these events must discern the source of the event.) Are we left on our own to figure out the source?

Alan,

Alan Jayson said:

4.  ...
What do you mean buy inconvenient? ...
(Finally, AMUTEIN events are logically ORed with the McASP transmit and receive error events within the dMAX; therefore, the ISR that processes the dMAX interrupt generated by these events must discern the source of the event.) Are we left on our own to figure out the source?

That is exactly what I meant by inconvenient.

What percentage of time will be spent transferring data on EMIFA?

I still will encourage you to re-consider the C6748. The interrupts are easier to use, the EDMA3 is much easier to use and more capable than dMax, and the C674x core is everything that the C67x+ core is plus significant enhancements to performance from the other integrated architectural improvements. And it is faster and it has data cache available.

Regards,
RandyP

What percentage of time will be spent transferring data on EMIFA?

I have two FPGA’s that will take most of the time on the EMIF.

One FPGA has 10 int32 that need to be processed in the DSP every 50 us for ten filters.
One int32 to be processed in the DSP every 209.7 ms for RF Vrms.

The other FPGA (Altera Nios II) will need to exchange char’s, int’s and float’s data both ways (DSP to FPGA and FPGA to DSP).
The faster I can move 64,000 float’s off the DSP the sooner I can reload our event recorded.

Alan,

I am sure your project will be a great success. Please keep us posted on your project.

To know that your C6727 EMIF will meet your need, you will be adding all the data transactions together and including any latency requirements for each different type of transfer, if latency requirements exist. If you have preliminary estimates for your access speed on the EMIF to your FPGAs, please remember to include Turn-around cycles between reads and writes and add a couple of extra EMIF clock cycles to each transfer for caution in case board or FPGA delays end up being more than you expected.

The DSP core is not efficient at accessing the EMIF. In almost all cases you will want the dMax or EDMA3 to do the direct data access and then have that transfer completion interrupt the DSP to start doing some processing. The most efficiency comes when the DSP is busy processing data while the dMax/EDMA is busy transferring data for the next set of processing. Block processing is more efficient than single-sample processing, as long as latency requirements do not prevent it.

Regards,
RandyP