1 / 14

Challenges in KeyStone Workshop

Challenges in KeyStone Workshop. Getting Ready for Hawking, Moonshot and Edison. In the old days… A single player. Classic DSP engineering (i.e. Shannon) System architect is part of the team Resource management is explicit application configures everything

nariko
Download Presentation

Challenges in KeyStone Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Challenges in KeyStone Workshop Getting Ready for Hawking, Moonshot and Edison

  2. In the old days… A single player • Classic DSP engineering (i.e. Shannon) • System architect is part of the team • Resource management is explicit • application configures everything • Open, init, configure is part of the application • A good engineer knows everything and does everything • A good engineer must knows how to debug using CCS and using other debug features in the applications

  3. KeyStone I training approach • Overviews on the system architecture and the core • Overview of important peripherals and IP (NetCP, Navigator, HyperLink, and more) • Overview of the software • A little how to use – mostly LLD and CSL interfaces • Even less on high level libraries • BIOS, CCS and Advanced Debug

  4. Now there are multiple players System Architect Linux applications development team Linux Kernel/System engineer DSP Engineer

  5. And what they are interested in?Not the same topics

  6. Architect • Understanding the device capabilities • Partition of the problem between DSP and ARM • Resource management, memory management, peripheral management • Who configure the SRIO? • Can we use the SRIO to transfer data to the ARM and the DSP • Inter processor communications • msgCom? IPC?, MPM?, PKTIO?

  7. Linux Kernel – System Engineer • Reboot, U-BOOT • Lab • How to manage the resources • Device tree? Considerations to what resources the LINUX use • How to manage the memory • Device tree, mpm config, resource management, resource policies • peripheral management • What needs to be developed? • Do TI functions and APIs configure everything? • What do we need to develop (if any thing) • How to implement the IPC • What needs to be developed? • Do TI functions and APIs configure everything? • What do we need to develop (if any thing)

  8. Linux Application Engineer • ARM core architecture and ARM’s software support • What libraries and API TI provides • What tools I can use? • Example Labs • Do I need to configure anything • If so, how? • How do I debug my code • Example Labs • Communication • With the DSP and other IP on the device • Outside of the device • Examples and Labs

  9. DSP Engineer • DSP Core, code development, BIOS, CCS • Resource management – what are available for me, how do I get it, how do I cooperate with the ARM team • What do I need to configure? • LLS and CSL • Communication • With the ARM or other IP on the device • External to the device • Do I need to configure, and if so how • Examples and Labs

  10. Challenges Moving into Open Enrollment KeyStone II How to partition the presentations and the contains between DSP discussion and Linux User mode and Kernel Mode discussion What is consider device information and thus needs to be presented, and what is consider standard Linux information that is not covered by TI What if we are explicitly asked about standard Linux information – what depth we should go How to partition the Labs between DSP and ARM/ what level of competency we expect from mixed group of people? Can we run two different Labs for DSP engineers and to ARM engineers? How to explain simple DSP concept to ARM people without insulting the intelligence of the engineers? How to explain simple LINUX concept to the DSP guys without insulting the intelligence of the engineers? More so, in a diverse group, how to gauge what is obvious and what is not, what to explain and what can be taken for grounded as common knowledge

  11. Germantown Workshop Observations The 10 people group was divided between DSP engineers and general purpose (ARM) engineers.  As it turned out, the ARM guys were more vocal and tried to push the conversation toward LINUX.  Several interesting issues were discussed: What are the limitations of the Linux system on the target?  Can we compile LISP code on the cross compiler? On the target? Can we re-compile the compiler and run it on the target?  What else we can do on the target?  Are all of the above standard LINUX questions or we should have to answer? When it comes to LINUX programming of the peripherals and IP we send mixed messages. On one hand we want to show TI advantages by having IP so we want to cover the architecture and the capabilities of the IP, on the other hand, we tell the participates that all configuration is done easily using Linux API and kernel functions.  The immediate question is: Why do you teach us the IP features instead of just showing us an example how to use it? How does the mpm server and client work?  Can we have the source code and add features to the mpm server? Can we have example where the mpm sends data across from the ARM to the DSP and back?  The MPM Lab that we had only sends messages from the DSP to the ARM and not exchange data, can we have a Lab that actually exchange data and use the MPM? How the IP configuration is done when the application uses Library that uses IP? For example, where is the QMSS configuration done when msgCom library is used on the LINUX? Does all the configuration is hidden from the application? Is it done by the system?

  12. Gaps that we need to close Need to modify the peripherals presentations to emphasis Linux configuration including device drivers and high level APIs Libraries) Need a discussion on MPM usage, including resource management, device tree, mpm configuration and U-BOOT to explain the dependencies when DSP and LINUX are working together. Give a clear understanding of all dependencies We need ARM-DSP real communication Lab. I started working on msgCom lab before the workshop but was unable to finish. The original code that we had runs on release 10 but not on release 12 or 14. Need to make msgCom example running on release 14 for me. Need lab example to show IPC V3 exchange data and messages between ARM and DSP Need to add a peripheral Lab, for example configure and build an Ethernet project

  13. One Suggestion on MPM Functions Ping Run Reset Load (program) Core Dump State I miss load data function Looks like we almost have all the components Load program moves out files from the file system to DSP memory. Cannot we use a similar mechanism to move data from user’s domain to DSP memory mapped?

  14. What about other IPC methods msgCom is part of SYSLIB. IPC is part of ipc release The instructions how to build SYSLIB unit test are very hard to follow, no instructions how to run the tests (or at least I have not found) We miss a name next to every module. A person that can answer questions about the module Unclear to me who tested the modules and why the unit tests are not part of the release

More Related