Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hello Kyungguk Bok,

From the FPGA perspective the base_module component handles the EMIF transactions and converts then to an internal bus format so that you can have multiple FPGA components (or Cores as we call them) that sit on the EMIF bus at regularly spaced intervals.

If we look at IndustialIO_top.vhd, first we have the base_module instantiation:

bm : base_module
   generic map (
      CONFIG => "MityDSP_L138",
      GEN_XADC_PORT => GEN_XADC_PORT
      )
   port map (
      ema_clk         => ema_clk, 
      i_cs            => arm_cs5_r(CORE_BASE_MODULE),
      i_ID            => FPGA_APPLICATION_ID,
      i_version_major => FPGA_VERSION_MAJOR,
      i_version_minor => FPGA_VERSION_MINOR,
      i_year          => FPGA_YEAR,
      i_month         => FPGA_MONTH,
      i_day           => FPGA_DAY,
      i_ABus          => addr_r,
      i_DBus          => edi_r,
      o_DBus          => edo_arm(CORE_BASE_MODULE),
      i_wr_en         => wr_r,
      i_rd_en         => rd_r,
      i_be_r          => be_r,

      o_dcm_reset  => open,
      i_dcm_status => dcm_status,
      i_dcm_lock   => dcm_lock,

      i_irq_map    => irq_map,
      o_irq_output => o_int                  

      );

Next we will focus on the i2c FPGA Core:

i2cctrl : i2c 
   Port Map ( 
      clk            => ema_clk,
      i_ABus         => addr_r,
      i_DBus         => edi_r,
      o_DBus         => edo_arm(CORE_I2C_MODULE),
      i_wr_en        => wr_r,
      i_rd_en        => rd_r,
      i_cs           => arm_cs5_r(CORE_I2C_MODULE),
      o_irq          => irq_map(CORE_I2C_IRQ_LEVEL)(CORE_I2C_IRQ_VECTOR),
      i_ilevel       => conv_std_logic_vector(CORE_I2C_IRQ_LEVEL, 2),
      i_ivector      => conv_std_logic_vector(CORE_I2C_IRQ_VECTOR, 4),
      i_sda          => io_sda,
      o_sda          => sda,
      o_sdt          => t_sda,
      o_scl          => o_scl
   );

If we specifically focus on the ports relating to handle EMIF reads and writes:

 
      clk            => ema_clk,
      i_ABus         => addr_r,
      i_DBus         => edi_r,
      o_DBus         => edo_arm(CORE_I2C_MODULE),
      i_wr_en        => wr_r,
      i_rd_en        => rd_r,

We have a clock, address, data in, data out, write enable and read enable. These signals translates EMIF reads and write specific to that core. When I say "specific to that core" the idea here is that the FPGA EMIF memory space starts at physical address 0x6000_0000 from the perspective of the ARM/DSP. Then each FPGA core starts its address space at an offset of 0x80. For example, CORE_I2C_MODULE is set to 2, meaning that EMIF reads/writes from 0x6000_0100 to 0x600_017C will correspond to read/writes to the i2c core.

In short, if you want to implement a custom FPGA core on the EMIF bus I would look at the source for i2c or any of the other cores supplied in the MDK. From the perspective of the DSP you just need to know that the FPAG EMIF space starts at physical address 0x6000_0000 and each core added properly in the FPGA will start on a multiple of 0x80.

Thanks,
Greg

답변 감사합니다.
지금 제가 공부하고 있는 환경은 리눅스(우분투)입니다.
(wiki에서 다운 받아 설치한 .ova파일)
code composer studio 7.5.0을 사용하고 있습니다. 이 환경에서 DSP로 EMIF에 관해 코딩하려고하니, csl_emifa.h 파일이 필요하다고 합니다.
.ova에는 EMIF에 관해 코드를 진행하기 어려운 상황입니까?
우선 CSL에 관해 필요한 include파일을 설치하고 첨부한 상황이긴 합니다.
혹시 다른 필요한게 있을까요?
아직 공부가 더 필요하지만, 정보를 얻을 데가 한정적입니다.
초보적인 질문이라 죄송합니다. 답변 주시면 감사하겠습니다.

Thank you for answer.
The environment I am currently studying is Linux (Ubuntu).
(.ova file downloaded and installed from wiki)
I am using code composer studio 7.5.0. When I try to code EMIF with DSP in this environment, it says I need the csl_emifa.h file.
Is it difficult to code .ova for EMIF?
First of all, the necessary include files for CSL have been installed and attached.
Is there anything else you need?
More study is still needed, but information is limited.
Sorry for the beginner question. I would appreciate your reply.

Could you provide an example of what you are trying? I don't believe you should need any special headers, assuming the kernel is loaded and configured the EMIF bus on the ARM.

Thank you for answer.
Currently working on MityDSP-L138F.
The kernel is loaded on ARM, and HelloworldDSP and FPGA from Wiki have been converted to .bin files so that they are automatically loaded upon booting.
If you try to write code related to EMIF in CCS, you will need a header file called csl.emifa.h. How can EMIF be performed without the need for a header file? I would like some basic information about EMIF.
I would be grateful if you could answer any questions I may have, even if they are incomplete.

If you try to write code related to EMIF in CCS, you will need a header file called csl.emifa.h. How can EMIF be performed without the need for a header file? I would like some basic information about EMIF.

The kernel sets up the emif bus for you, there should be no need to modify the configuration from the DSP.
Greg's explanation mentions that the EMIF is memory mapping the physical memory address 0x6000_0000 to the FPGA cores. So your code in the DSP can read/write directly to/from memory at that address and the EMIF will handle sending/receiving to the FPGA.

In short, if you want to implement a custom FPGA core on the EMIF bus I would look at the source for i2c or any of the other cores supplied in the MDK. From the perspective of the DSP you just need to know that the FPAG EMIF space starts at physical address 0x6000_0000 and each core added properly in the FPGA will start on a multiple of 0x80.

In MDK_2014-01-13, the camera demo sw interacts with a FPGA pwm and gpio core. The constructor for the tcDspFpgaGpio class takes a memory address to where the fpga core is mapped into memory as Greg described. Please review the gpio and other DspFpga* classes in MDK_2014-01-13/sw/DSP/lib/core/

MDK_2014-01-13/examples/industrial_io/cam_demo_sw/DSP/cam_demo/VideoApp.cpp:
mpGpio = new tcDspFpgaGpio((void*)0x66000280);

The MDK can be downloaded on the following page: https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Board_Support_Package

Thank you for answer.
(using MityDSP-L138F Devkit)
When using EMIFA to control the LED by controlling the FPGA's GPIO, I found out that EMIFA is set in the kernel when the fpga_ctrl.ko and fpga_gpio.ko module files are loaded. I also found out that I can control the FPGA's GPIO from the DSP through the DspFpgaGpio.cpp source.
Is my understanding correct?
Then, next, I would like to randomly control pin C10 of the FPGA to turn the LED on/off.
(Pin C10 is connected to DISP A3 P.)
In this case, how should I set the Pin?
gpiochip144 does not exist in the /sys/class/gpio path.

'int tcDspFpgaGpio::SetPinDirection(unsigned int Bank, unsigned int Offset,bool IsOutput, unsigned int Value)'
'int tcDspFpgaGpio::SetPinValue(unsigned int Bank, unsigned int Offset, unsigned int Value)'
I need to set it using a function such as Bank=0, etc. How should I input it into the variable?

Kyungguk Bok wrote in RE: DSP EMIF Example Code:

Thank you for answer.
(using MityDSP-L138F Devkit)
When using EMIFA to control the LED by controlling the FPGA's GPIO, I found out that EMIFA is set in the kernel when the fpga_ctrl.ko and fpga_gpio.ko module files are loaded.

I'm pretty sure the EMIFA will get configured before fpga_ctrl.ko and fpga_gpio.ko module files are loaded. So they aren't strictly required as long as the fpga is loaded in u-boot. fpga_ctrl is needed to program the FPGA from linux.

I also found out that I can control the FPGA's GPIO from the DSP through the DspFpgaGpio.cpp source.

yes

Then, next, I would like to randomly control pin C10 of the FPGA to turn the LED on/off.
(Pin C10 is connected to DISP A3 P.)
In this case, how should I set the Pin?
gpiochip144 does not exist in the /sys/class/gpio path.

How did you calculate 144? Posting additional details would be helpful.
Read https://www.kernel.org/doc/Documentation/gpio/sysfs.txt, for how to control gpios via /sys/class/gpio. Its not a bad idea to make sure you can control the gpio in linux before trying to get it working in the DSP.

'int tcDspFpgaGpio::SetPinDirection(unsigned int Bank, unsigned int Offset,bool IsOutput, unsigned int Value)'
'int tcDspFpgaGpio::SetPinValue(unsigned int Bank, unsigned int Offset, unsigned int Value)'
I need to set it using a function such as Bank=0, etc. How should I input it into the variable?

Thank you for answer.

It's not a bad idea to make sure you can control the gpio from Linux before operating it on your DSP.

I think that's a good thing to say. I think it's a good idea to solve problems one by one.

How did you calculate 144? It would be helpful if you posted additional details.

Rather than calculating gpiochip144 separately, it was checked in the FPGA GPIO Core Example section of the wiki below.
https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/FPGA_Core_Device_Drivers
Among the contents of the above wiki, there is the following. I don't understand this part.

“FPGA GPIO core pins start at pin #144Linux side.
So pin #144 is mapped to the first gpio of the first gpio core. The gpio core is then connected to a net name that maps to the fpga pin name in the .ucf file. For an example, see $MDK/examples/industrial_io/fpga/vhdl/IndustrialIO_rev_C.ucf."

I have one more additional question.
As far as I know, the above method seems to follow the DSP->ARM->FPGA format to control FPGA. Is it possible to control directly with DSP->FPGA?

Kyungguk Bok wrote in RE: DSP EMIF Example Code:

Thank you for answer.

It's not a bad idea to make sure you can control the gpio from Linux before operating it on your DSP.

I think that's a good thing to say. I think it's a good idea to solve problems one by one.

How did you calculate 144? It would be helpful if you posted additional details.

Rather than calculating gpiochip144 separately, it was checked in the FPGA GPIO Core Example section of the wiki below.
https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/FPGA_Core_Device_Drivers
Among the contents of the above wiki, there is the following. I don't understand this part.

“FPGA GPIO core pins start at pin #144Linux side.
So pin #144 is mapped to the first gpio of the first gpio core. The gpio core is then connected to a net name that maps to the fpga pin name in the .ucf file. For an example, see $MDK/examples/industrial_io/fpga/vhdl/IndustrialIO_rev_C.ucf."

Yup, so you should be able to export gpio 144 and access the gpio

cd /sys/class/gpio
export 144 > export
cd gpio144
cat value
cat direction

I have one more additional question.
As far as I know, the above method seems to follow the DSP->ARM->FPGA format to control FPGA. Is it possible to control directly with DSP->FPGA?

The tcDspFpgaGpio code, writes directly to the mapped EMIF register address space so the ARM isn't involved.