- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear community,
I’m fairly new to the SoC-World and I have a few things I would like to discuss with you guys. I have to design a board with the new Cyclone V SXF SoC system for my company. We mostly want to run control algorithms on the FPGA, with the more advanced ones (e.g. model predictive control) being assisted by the HPS. Seeing as real-time is a must, we thought the best way to achieve this integration of the HPS in the control system was by configuring the FPGA to our needs and then making the FPGA run Bare-Metal-Applications on the HPS unit. However, while searching through this forum I learned that Bare-Metal-Applications are actually not recommended, as they do not exploit the full potential of the Cortex-A Class processors, especially given the dual core version of the Cyclone V SXF. So my question is: Would a Real-Time-Operating-System (RTOS) be more suitable for our application? If yes, why, and which one in particular? Many thanks, X ClaudiaLink Copied
13 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Claudia,
I have similar project, according to functionality and demands you described. We choose Threadx as RTOS. It is simple enought and has realtime scheduling. The bare-metal library is actually core part of Threadx drivers for Cyclone V SOC. My answer to the question is yes, the RTOS (like Threadx, vxworks, etc) are more suitable. The reason is multitasking support and scheduling. Gery- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If use 1 thread in any RTOS, come in Baremetal application ! :)
If only that RTOS may will start from any flash ! :) Wait 1-2 year, and Baremetal learn to work on SoC FPGAs ! :)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It depends on the how 'hard' the real-time requirements are.
If you have very strict real-time requirements you can't afford the randomness that an RTOS will generate. IMHO I'd avoid vxworks ...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Gery,
--- Quote Start --- I have similar project, according to functionality and demands you described. We choose Threadx as RTOS. It is simple enought and has realtime scheduling. The bare-metal library is actually core part of Threadx drivers for Cyclone V SOC. My answer to the question is yes, the RTOS (like Threadx, vxworks, etc) are more suitable. The reason is multitasking support and scheduling. --- Quote End --- I’m sorry for having to ask – but what is realtime scheduling? I would have thought the most important reason is the ability to use multiple cores. Have you tried other RTOSes as well? Because Threadx is fairly expensive and I would have to explain the benefits for choosing Threadx over a free solution to my boss. Hi Witfed, --- Quote Start --- Wait 1-2 year, and Baremetal learn to work on SoC FPGAs ! :) --- Quote End --- My appologies, but what exactly do you mean by bare-metal learning to work on SoC FPGAs? Is bare-metal not properly supported by the SoC FPGAs yet? Hi dsl, --- Quote Start --- IMHO I'd avoid vxworks ... --- Quote End --- Okay, thanks for the tip! --- Quote Start --- It depends on the how 'hard' the real-time requirements are. If you have very strict real-time requirements you can't afford the randomness that an RTOS will generate. --- Quote End --- That’s interesting. So an RTOS with the ability to use multiple cores will still not outperform a bare-metal application? I am given to understand that bare-metal applications cannot use both cores of the ARM Cortex-A9 and I would have to run a separate bare-metal application on the second core – or leave it idle. Thank you guys! Claudia- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Claudia,
I hope below link will help for understanding of real-time http://en.wikipedia.org/wiki/real-time_computing You should define what are the real-time demands in your project and it may help to accept the Linux as a solution. Choosing Linux reduces the bringup time and may provide many already done solutions from open source world. Gery- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Now Baremetal applications may only be debugged in DS-5, and not started independent on power + from flash with regular Altera-s Preloader without semihosting support.
If for task solution is enough only original Altera-s SoC and run your program in debugger, may use current state, else need demand to Altera for revision and upgrade Preloader, about that I scream long time ! :) For small transparent private application (no Internet, USB, CAN) without threads, semaphores and other "piles" best way is -- in one thread with one stack cycling with polling of all inputs, processing new data with not great portions and deliver results to outputs, then again read inputs and call most-priority handler... If need be urgent reactions to fast events in 10-20 tacts, may be used interrupts -- as exception, usually this urgency is not need. Try start with one powerful processor core -- it may be sufficient for your tasks, and 2nd may only cause troubles in interaction and divide all works between all cores. Although if your tasks good divides on independent parts -- may run its on independent processors. RTOSes have big initial costs for application developers, demand many unnecessary code (> 1/2) for supplying interaction and unnatural parallelizm, big times of task switching, volume of memory and unpredictable time of reaction. And many-many all-ready obscure sources and followers ! :) With weak possibility of debugging -- by order greather even with powerful debugger.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- Now Baremetal applications may only be debugged in DS-5, and not started independent on power + from flash with regular Altera-s Preloader without semihosting support. If for task solution is enough only original Altera-s SoC and run your program in debugger, may use current state, else need demand to Altera for revision and upgrade Preloader, about that I scream long time ! :) --- Quote End --- Hi WitFed, So bare-metal applications cannot boot on their own from SD-Card or QSPI Flash? I have to have a usb cable attached and configure via JTAG to run bare-metal applications? But what do OSes or RTOSes have that makes them able to boot on their own? Are you sure about this? Because the following tutorial tells you how to boot bare-metal applications from SD-card: (please google "HPS SoC Boot Guide - Cyclone V SoC Development Kit" and click on the first result) I didn't actually get it to work myself though... Thanks Claudia
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In booting a bare metal application from qspi flash (http://www.alteraforum.com/forum/showthread.php?t=44985) and more older topics I discuss these theme. Some people says, what they may boot from QSPI, only without concrete recipe, some confirm impossibility.
Standard bsp-editor have checkbox-es for change Preloader functionality in sources, boot not from SD-card with Linux, and from QSPI flash with filled Preloader on address 0 and application on 60000, and in practice this not work, only Linux from SD! RTOSes I not touch. I entreat Altera in detail describe this processes, because available some allusions and even is not known, where utilite must make binary image for fill application in flash and with what keys. In debugger by run both Preloader and from it my HWLIB from QSPI is clear, what not handled exception "SVC 12345" in system libraryes with call to supervisor for semihosting: work with host files as stdin, stdout and from disk. In debugger this exception is wonderful handled (if semihocting enabled), and program interact with consoles and filesystem, and in "bare" boot first ASM command "SVC 12345" right away hang. For my research I write semi-simulating handler in Preloader and may start with rbf downloading and LED blinking, and all wait Altera with officially promulgate sources of compatible with any flash-device non-semihosting starting Preloader ! May will be this in 14.1, may in 15.0 version... In OSes or RTOSes, probably, is a similar handler, or they not using HWLIB with SVC interface. For Linux really used other compiler. ...All Boot Guides I read 2 month from april and battle with obscure problems, scream on forums, while perceive truth... :) P.S. Link www.altera.com/literature/an/an709.pdf is recently, in July, its glad as Altera work, in a year may be result ! :) Where I may subscribe to Altera distribution on SoC- and Baremetal-changes on site ? In ug_soc_eds.pdf, my base document, this not described. In 709 many orthographical, punctuation and meaning errors, idea of Minimal Preloader or Custom Preloader, if BareMetal incorporates to its in 64K of available in HPS hi RAM, very not-good -- very small my code be located and badly debugged on Release. And direct execution of Preloader with big size may be only on FPGA fabric boot. If Preloaders may be max size 1 M (4, 16, ... etc. optional through BSEL pins) and these distantion with copyes, direct execution from flash sources... Good idea -- boot from FPGA if booting from flash is unsuccessful, as a fallback. Its if FPGA boots without fails :) And I want configure FPGA from HPS: this very safely. When I found HelloWorld sources contain files "test.c", "io.c" and "Debug-unhosted.ds" (in 13* and 14* SoC EDS used "hello.c"), then try next stages of writed in 709. May be, in application not using HWLIB (base of Altera for work with peripheral), and only with RS-output "Hello!", she start anyway from flash. And .ds-file-extension says me about armcc-compiler in compiling toolchain, licension of these not included in SoC CV kit!.. :)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi WitFed!
--- Quote Start --- In booting a bare metal application from qspi flash (http://www.alteraforum.com/forum/showthread.php?t=44985) and more older topics I discuss these theme. Some people says, what they may boot from QSPI, only without concrete recipe, some confirm impossibility. Standard bsp-editor have checkbox-es for change Preloader functionality in sources, boot not from SD-card with Linux, and from QSPI flash with filled Preloader on address 0 and application on 60000, and in practice this not work, only Linux from SD! RTOSes I not touch. --- Quote End --- But why doesn't it work? And why does it work for Linux? --- Quote Start --- I entreat Altera in detail describe this processes, because available some allusions and even is not known, where utilite must make binary image for fill application in flash and with what keys. In debugger by run both Preloader and from it my HWLIB from QSPI is clear, what not handled exception "SVC 12345" in system libraryes with call to supervisor for semihosting: work with host files as stdin, stdout and from disk. In debugger this exception is wonderful handled (if semihocting enabled), and program interact with consoles and filesystem, and in "bare" boot first ASM command "SVC 12345" right away hang. --- Quote End --- But what sort of exception is this? But then the application should work without the error that throws the exception. --- Quote Start --- For my research I write semi-simulating handler in Preloader and may start with rbf downloading and LED blinking, and all wait Altera with officially promulgate sources of compatible with any flash-device non-semihosting starting Preloader ! May will be this in 14.1, may in 15.0 version... --- Quote End --- What is rbf? I'd love to get a HPS program to work that just boots from the SD-Card an then blinks a couple of LEDs! --- Quote Start --- In OSes or RTOSes, probably, is a similar handler, or they not using HWLIB with SVC interface. For Linux really used other compiler. ...All Boot Guides I read 2 month from april and battle with obscure problems, scream on forums, while perceive truth... :) --- Quote End --- Yes I can understand your frustration, I find the documentation rather scarce too! --- Quote Start --- P.S. Link www.altera.com/literature/an/an709.pdf is recently, in July, its glad as Altera work, in a year may be result ! :) Where I may subscribe to Altera distribution on SoC- and Baremetal-changes on site ? In ug_soc_eds.pdf, my base document, this not described. In 709 many orthographical, punctuation and meaning errors, idea of Minimal Preloader or Custom Preloader, if BareMetal incorporates to its in 64K of available in HPS hi RAM, very not-good -- very small my code be located and badly debugged on Release. And direct execution of Preloader with big size may be only on FPGA fabric boot. If Preloaders may be max size 1 M (4, 16, ... etc. optional through BSEL pins) and these distantion with copyes, direct execution from flash sources... --- Quote End --- I also don't understand in the an709.pdf (HPS SoC Boot Guide - Cyclone V SoC Development Kit) document, why do they use a linux image at the end? I thought the purpose was to get a bare-metal application up and running --- Quote Start --- Good idea -- boot from FPGA if booting from flash is unsuccessful, as a fallback. Its if FPGA boots without fails :) And I want configure FPGA from HPS: this very safely. When I found HelloWorld sources contain files "test.c", "io.c" and "Debug-unhosted.ds" (in 13* and 14* SoC EDS used "hello.c"), then try next stages of writed in 709. May be, in application not using HWLIB (base of Altera for work with peripheral), and only with RS-output "Hello!", she start anyway from flash. And .ds-file-extension says me about armcc-compiler in compiling toolchain, licension of these not included in SoC CV kit!.. :) --- Quote End --- What is RS-output? Yes, I had a lot of licensing problems too, very annoying! Many thanks, Claudia- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- It depends on the how 'hard' the real-time requirements are. If you have very strict real-time requirements you can't afford the randomness that an RTOS will generate. IMHO I'd avoid vxworks ... --- Quote End --- Which RTOS would you recommend? Cheers, Adam
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- It depends on the how 'hard' the real-time requirements are. If you have very strict real-time requirements you can't afford the randomness that an RTOS will generate. IMHO I'd avoid vxworks ... --- Quote End --- If you're finding that whatever RTOS you are using is not meeting your "strict real-time requirements", then you are using the wrong RTOS. A RTOS should not be introducing "randomness", it should be introducing order and predictability. mAbassi from Code Time is another one to consider, and was designed specifically for multicore applications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- If you're finding that whatever RTOS you are using is not meeting your "strict real-time requirements", then you are using the wrong RTOS. A RTOS should not be introducing "randomness", it should be introducing order and predictability. mAbassi from Code Time is another one to consider, and was designed specifically for multicore applications. --- Quote End --- Thanks for the tip, I will try mAbassi! Do you know if there is an educational license? Cheers, Adam
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Claudia,
Hi, can you recommend any vendors for RTOS? Which one do you like? Thanks
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page