Mity CPU Platforms » MityDSP (TI TMS320C6xxx Based Products)

The bootloader FPGA image included in the file mention provides a basic UART at pins 14 and 16 of the edge connector as you mentioned.

The FPGA_RSV1 and FPGA_RSV2 lines are not driven, unfortunately. They were left floating in the bootloader image in order to ensure no contention issues with any known host board.

If you would like an FPGA image that routes the 2 LED lines to these pins, we should be able to provide one in short order.

The other option would be to use the tcNetDrvr_645x::LinkUp() method and toggle the on board LEDs. Probably more work than spinning the FPGA.

-Mike

Hello Tom,

I will try posting this to the support forum as well but I need to clear up some confusion Kevin and I were having yesterday as to what we were seeing. But I need to ask some questions to make sure I understand myself what I believe is going on…

From the schematics it appears that the evaluation board is connected to both RJ-45 connectors, one goes to the 10/100 signals on the plug-in module DSP EMAC and the other to what appears to be a Gigabit PHY which uses a GEMAC running out of the FPGA, is that correct?

In trying to get a demo running in CCS4 I requested that a demo be converted that uses Ethernet and serial communications. I may not have been clear enough, my bad, but I don’t know for sure if the converted demo uses the DSP EMAC setup as a 10/100. You would need to speak to Kevin more about what we’re seeing but it appears that when we try to run the application from the MityDSP configuration GUI, we end up getting conflicts. The configuration GUI recognizes the evaluation board correctly but when we click on run application with the default .hex file we lose communications on the Ethernet port but we see activity on the serial port via HyperTerminal. Connecting up to what we believe is the 10/100 that should be functional does nothing so we’re not sure the demo is doing what we think or somehow we are not interpreting the demo correctly and need to understand it better.

I am not in the office today but will be in tomorrow. I am thinking that maybe what we also need to do is program a more basic bare bones FPGA image that simply configures or uses the RS232 RX/TX and the FPGA RSV1 & RSV2 pins to show Ethernet activity. Also, we simply want to use the 2 differential 10/100 signal pairs connected directly to the DSP module via the SO-DIMM which simply go thru our back side RJ-45 connector with embedded magnetics to communicate over Ethernet. In doing the reprogram I’m thinking would simply select say tab number 2 and indicate the FPGA image we wish to load? Also, should we doing this with the output of the converted compiled demo? If so will we have any issues that you might be aware of with the evaluation board in terms of conflicts? I’m hoping not since we most likely will be deactivating some functions both in the bare bones FPGA image as well as the demo we requested.

I am attaching the SO-DIMM connector page of our schematic to show how basic the connection scheme is we are intending to use for the moment. If one of the FPGA images in the installed MityDSP directory accomplishes this task then that’s most likely what we should be programming into the FPGA on the DSP module. Once that is done we should be able to use the converted DEMO to try and activate the 10/100 Ethernet port along with serial communications to get things running as we hope they should on our host card.

You will see from the attached schematic page all we care about is using the 10/100 from the DSP along with the RSV1 & 2 pins for link/activity as well as the RS232 TX/RX. We connect up directly to the 2 McBSP ports on the DSP, of which one will be configured as a Master SPI. The remaining FPGA pins are completely unused… If we can program an FPGA image that includes any boot up functions the module requires along with what is depicted on the schematic page I’ve enclosed that would be great. If that image happens to reside in the installed MityDSP directory even better. If some minor mods need to be done to a basic FPGA image to use the RSV1 & 2 pins for activity/link then hopefully that’s a minor thing.

I have put our FAB on hold to make sure that how it is currently connected and what I believe should be a pretty simple FPGA image to load is correct. I could simply be a software issue in how we are trying to configure and use the 10/100 in the DSP or how we load up the example along with a proper FPGA image file.

Thanks,

Anthony

From the schematics it appears that the evaluation board is connected to both RJ-45 connectors, one goes to the 10/100 signals on the plug-in module DSP EMAC and the other to what appears to be a Gigabit PHY which uses a GEMAC running out of the FPGA, is that correct?

Almost correct. The DSP MAC is the 10/100/1000 and the FPGA MAC is 10/100. I will ask one of the guys here to help you through getting the demo functional.

Thanks,
Tom

Hi Tom / Anthony,

I hope this doesn't muddy the waters, but here is some more information: There are actually 3 EMAC interface options available for the MityDSP-PRO module. DSP using 10/100 MII, DSP using Reduced Gigabit MII, and FPGA 10/100.

The C645X DSP chip has an internal MAC that can be connected to an MII (10/100) interface as well as a RGMII (10/100/1000) interface. On the MityDSP-PRO module itself, the MII (10/100) interface is routed directly to an on-board 10/100 PHY. The PHY signals (going to the RJ-45 / magnetics) are routed to the ETH_TD and ETH_RD pins on the DDR2 connector (pins 13/15/17/19). The PHY status lines (normally hooked to LEDS) are routed to the FPGA. The Bootloader will attempt to use this interface if no FPGA EMAC core is found in the boot FPGA. These signals are routed to 1 of the two EMAC connectors (the one on the long side of the board, I don't have the J number off hand). These are the pins you have called out on your schematic.

The Reduced Gigabit MII interface is routed directly to the Hirose expansion connector on the bottom of the module. On the evaluation board, these signals are not connected and are not used.

Finally, Critical Link has ported a legacy 10/100 FPGA based EMAC core from our legacy C6711 MityDSP modules. This requires routing FPGA pins to a host board 10/100 ethernet PHY and magnetics. The second RJ-45 ethernet port on the evaluation board is hooked to FPGA lines to support using this core. The FPGA core is not gigabit, only MII (10/100).

So, the evaluation board supports the DSP 10/100 EMAC (which, I suspect, won't have working link lights when used with a "stock" or black FPGA image) and/or an optional FPGA based 10/100 EMAC (which should have working link lights as the are direct connected on the host board to the phy on the host board).

I think your confusion may be due to how the current bootloader works:

The bootloader is designed to only support 1 EMAC interface. It uses the first on it finds. It first checks the FPGA for a EMAC core, then if it doesn't find one it turns on the local DSP EMAC using the 10/100 (on-board PHY) interface. A lot of our initial demo code used the FPGA core as we hadn't written an LWIP driver for the DSP EMAC peripheral until later. I suspect that the bootloader is using one interface and the demo is using the other, which explains the problem. If you want the bootloader to use the DSP 10/100 MAC, you need to ensure that the boot FPGA does not include an EMAC core in it. The application, of course, can choose which one to use.

-Mike

(from Anthony)

Michael,

Thanks for the response. From what you describe it seems that the signals I intend to use are fine the way they are connected up in our schematics, which just leaves us needing to make sure we have the bootloader come up in a way that utilizes the DSP EMAC in 10/100 mode…Knowing what the bootloader does is a huge explanation, is there somewhere that I missed reading the actual boot up process in detail because from the schematic I was totally confused based on what I was seeing in the demo.

My previous assumption was that the evaluation board most likely came with an FPGA image that does far more than what we will initially be needing it to do outside of whatever logic the DSP might need to access the boot flash and other stuff. This is understandable but we now need to take it back down to a more basic level with minimal function in the hopes of being able to better understand how we need to implement our designs.

I’m going to think out loud here for a minute and you can correct me. In researching the MityDSP directory install I noticed that there is a section for hardware that has both a ‘development’ directory called “C:\MityDSP\2.10\hardware\FPGA” and another called “C:\MityDSP\2.10\hardware\FPGA_boot”.

In the directory labeled “C:\MityDSP\2.10\hardware\FPGA_boot” I see several sub directories that appear to have pre-compiled FPGA bitstreams for various sized FPGA’s of which I am very familiar with having designed with Xilinx for over 15 years. More specific, in the sub directory XC3S4000_Pro is what I assume to be a more base or simpler FPGA image?

I also notice in the VHDL directory various files of which 2 standout relating to the DSP_Pro, at least that’s my thinking. “MityDSP_eth.vhd” and “MityDSP-Pro.vhd” are the 2 files which I have actually called up as designs, created projects and managed to compile to bit stream generation successfully. However, being that the majority of our work has never needed the largest FPGAs, we have managed to do all our work with the free WebPack ISE that Xilinx offers. In any case, I did manage to target the largest device in the WebPack which is the XC3S1500. The Critical Link MityDSP plug-in uses the XC3S4000 but again, the largest device supported in the free WebPack ISE is the 1500, however, using the constraints file provided I did not receive any errors that prevented the tools from compiling the design into the XC3S1500. This was all in an effort to make sure I could recompile the designs and call up the correct cores properly. In fact I was missing 2 core generator files and created my own based on the errors and investigating the VHDL files, it worked. Eventually Tom sent me the missing files and I reran the designs with those and was successful again.

In looking at the VHDL code itself, it would seem to me that ‘MityDSP-Pro.vhd’ has the basic RS232 function in addition to the LED signals called FPGA_RSV1 & FPGA_RSV2 on the SO-DIMM connector that I would need to drive activity and link for the 10/100 function of the TI DSP? Here is the section of code I am referring to:

This is taken from MityDSP-Pro.vhd file…

-- I/O pins for RS232 interface
i_rs232_rcv : in std_logic;
o_rs232_xmit : out std_logic;
i_rs232_cts : in std_logic;
o_rs232_rts : out std_logic;

-- I/O pins for USB interface
-- i_usb_rcv : in std_logic;
-- o_usb_xmit : out std_logic;
-- i_usb_cts : in std_logic;
-- o_usb_rts : out std_logic;

o_sba_data : out std_logic;
o_sba_clk : out std_logic;

o_led0_n : out std_logic; (Are these the 2 lines that drive FPGA_RSV1 & FPGA_RSV2?)
o_led1_n : out std_logic; ( )

i_config : in std_logic_vector(2 downto 0) (Is this used on board the plug-in module transparent to the user?)
);
end MityDSP_Pro;

Is the bitstream that is located in XC3S4000_Pro sub directory in fact that VHDL design (MityDSP-Pro.vhd)? If so, by reprogramming “MityDSP-Pro_boot_4k.mcs” into the current plug-in module would that ensure that the DSP EMAC comes up in 10/100 mode as well as having the FPGA_RSV1 & RSV2 signals become active for activity and link on the RJ-45 connector?

I believe I am understanding the whole setup better now that some pieces of the puzzle have been filled in. If the file I mention above does not do what I think it does, can you generate an XC3S4000 bit stream with the basic functions we would need to boot as well as have RS232 and the LED signals driven?

Thanks,

Anthony

In the directory labeled “C:\MityDSP\2.10\hardware\FPGA_boot” I see several sub directories that appear to have pre-compiled FPGA bitstreams for various sized FPGA’s of which I am very familiar with having designed with Xilinx for over 15 years. More specific, in the sub directory XC3S4000_Pro is what I assume to be a more base or simpler FPGA image?

That's correct, these images are the factory installed "bootloader" images for this product line, generated from the source files in the FPGA_boot\vhdl directory.

In looking at the VHDL code itself, it would seem to me that ‘MityDSP-Pro.vhd’ has the basic RS232 function in addition to the LED signals called FPGA_RSV1 & FPGA_RSV2 on the SO-DIMM connector that I would need to drive activity and link for the 10/100 function of the TI DSP?

No, those LED signals are for the 2 green (user controllable) LEDs on the MityDSP-PRO module itself. When the Module boots, you should see these lights flashing at different rates during the boot phases. The LEDs are controllable via the tcDspFirmware class API. The FPGA_RSV1 and FPGA_RSV2 lines are not driven at the moment.

If the file I mention above does not do what I think it does, can you generate an XC3S4000 bit stream with the basic functions we would need to boot as well as have RS232 and the LED signals driven?

We will upgrade the Pro bootloader FPGA code to pass these ethernet link LED signals through and provide you an image.

-Mike

Hello,

I wanted to update this issue with a interim Boot SW and FPGA that addresses the issue stated. Attached are two files that you will need to program your MityDSP-Pro module with. These are bootloader files NOT application files. As such you will need to follow the following steps to program the Bootloader using MityGUI.

*********
NOTE: Doing this can "brick" a MityDSP module therefore it is highly recommended that these files ONLY be updated with ones provided by Critical Link. *********
1) With MityGUI closed go into the MItyGUI install directory (currently C:\MityGUI\4.0\software\tools\
2) Open/edit the "MityDSPGUI.ini" file
3) Add the following line at the end of the file "Admin=1"
4) Save and close the "MityDSPGUI.ini" file
5) Now start the MityGUI application
6) You should now have the following list of options to program your module with

A) Application (Previously available)
B) Application FPGA (Previously available)
C) Bootloader (New - this is for the provided hex file)
D) Bootloader FPGA (New - this is for the provided mcs file)
E) Bootstrapper (New - will not use this)
F) Configuration (New - will not use this)
G) Full Image (New - will not use this)

7) You will need specify the Bootloader file and direct the GUI to use the attached "BootloaderPro_EthLED.hex" file
8) Download the file to the module
9) You will need specify the Bootloader FPGA file and direct the GUI to use the attached "mitydsp_pro_EthLED.mcs" file
10) Download the file to the module
11) Reboot/power cycle the module

At this time if you have the ethernet connected the orange speed LED (On = 100 MBit and Off = 10 MBit) and green Link/Activity (ON for Link and blinking for activity) should be working.

This version of the Bootloader will be included in the 2.12 version of the MDK.

Minor changes

Update to Step 1:
Depending on the version of MityGUI (or how it is installed) you should simply right-click on your MityGUI shortcut and view "properties" from there you want to find the location of the exe file it is executing. Broswe on your PC to that location and you will find the .ini file you need to modify.

Update to Step 3:
Instead of Admin=1 should should enter Authorized=1 into the .ini file