Android

1. The Matlab real-time compiler can be pretty finicky when it comes to writing usable C/C++ code.  If you follow their recommended programming guide for embedded code, then yes it will run without a problem.

2. I would recommend booting into Android on Core 0 and running the real-time code on Core 1.  This will make booting much much simpler.  Either way, both configurations are valid.

3. Matlab HDL Coder produces HDL (VHDL or Verilog) code that is human readable.  You would then synthesize the code with ISE or PlanAhead and put it into the Programmable Logic portion of Zynq.

Is there a specific reason why you want to use Android rather than a real-time port of Linux?

-TD

Good day,

(first note that I've only been to XFest so take any info in this answer with a grain of salt as my understanding on EPP might be off).

Would you care describing a bit more what kind of loads you are planning to implement in this design?

I'm asking as it seems you want to have on one side (hard?) RT constraints with the bare metal programming side + HDL and on the other side the Android system.

Having an OS (Android or anything alike) will probably kill your memory bandwidth as my understanding is that the DDR controller will be shared between both cores and the logic fabric (I suppose Android cannot work using only the internal cache and will have to access DDR regularly).

So if your RT load is only a pipeline and does not require too much bandwidth from the DDR what you describe should be possible.

I was also wondering why android? Xilinx will provide some linux images (and I hope also the ubuntu image that they were displaying in their demos at ESC). Linux is probably familiar for more people than Android. This might be a factor to have more interest in this project.

Cheers
DB

The DDR controller on the processing system is separate from the Programmable Logic.  Multiple DDR chips could be added to the design and used in fabric in regard to the RT code portion to save bandwidth from the Android core.

I would highly recommend reading this document:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug873_zynq_ctt.pdf

... as well as the 7-series documentation on memory controllers.

Android, if just streaming data via USB or Ethernet, should not be using DDR very often due to DMA.

I concur that Linux probably the better option here for overhead reasons.

Tim,
thanks for your answer, I was thinking in my message about the ZED board not the general case, so please correct me if I'm wrong.

Looking at your document (p14) there is a single DDR controller shared between all the blocks. So even if there are multiple controller ports (AXI?) with their own logic/queues, the global DDR BW is shared by all.

After looking at the ZED schematic, the DDR is cut in 2 16bits packages with a shared address bus (p17) so I'm not sure to see how you can dedicate a package with its BW to the logic and the other one to the OS for example.

http://zedboard.devcloud.acquia-sites.com/misc/files/ZedBoard_RevC.0_Schematic_120523_preliminary.pdf

Also even if the transfers are mainly DMA, the fact the the OS might be handling video, Ethernet and potentially other activities will shrink the remaining BW for the rest...

However I'm still convinced this platform has a great potential (I've ordered one).

Cheers
DB

My apologies - I was talking for Zynq in general, not Zed.  Yes, the Zedboard only has two DDR chips, and they are connected to the DDR hard-block controller in the Processing System (PS).  If you wanted to run an OS on one core, and bare metal on the other (on the Zedboard) you would be sharing bandwidth, correct.

I am very excited about the board as well, can't wait to get my hands on it and start putting together demo's!! :D

You can also place weight to the DDR arbitration inside of the device.  The cache arbiter has four ports, and a control signal that is 4 bits wide.  Setting a bit to high set's it's priority to high, this guaranteeing max bandwidth.

-TD

All, thank you for replying to the thread.  The reason why I am interested in Android is simply because I am an Android developer and am very familiar with writing java and the entire tool flow.  I also would like to have a 7 inch touch screen that is connected to this device, and coding up a nice vector based GUI is very straight forward with Android.  In the end I agree the Linux is another viable alternative especially for those more familiar with it. 

I am presently in communication with the Mathworks with regard to this concept (real time vhdl in PL, real time bare metal core 1, android/linux on core 0).  It would be great if their tool flow would automate some of the difficult low level details. 

I will read the great links that you guys posted as soon as I can and I hope to hit the ground running as soon as I get my ZED Board.  Will you guys be working on similar projects? Maybe we can put together some sort of lessons learned page so that we all don't have to struggle through the same pitfalls.

Doctor K,

Glad you found the information posted helpful!

I know that Avnet, Xilinx, and other third parties are going to be putting together Lab's and how-to's for Zed - these should help you come up to speed quickly.

Do keep us posted of your progress!

-TD

I am facing problem in my Matlab software when i open it i see an error like uncompleted files can you please tell me what file my matlab want. http://www.ordercollegepapers.com/mba-assignment-help