I'm Robert Cravotta, Technical Editor at EDN since January 2000. My interaction with computers and processors really picked up in 1980 when I created a two-pass, cross-platform assembler targeting an 8-bit z80 core. From there, I had a brief stint in the computer-game industry. I also developed a database system and created a mechanism to safely and dynamically relocate code on a system without a memory-management unit. I spent a number of years automating production-operation processes in a mainframe environment in an Information Systems (IS) group. From there I spent more years developing and working with embedded-control systems including autonomous vehicles, multiprocessor vision systems, power-management systems, and R&D for a dynamically tunable laser-sensor system. My focus evolved during those years from software- to system-level responsibility. I then spent a handful of years directing and overseeing the architecture, migration, and consolidation of independent and informal storage and computing LANs (Local Area Networks) into a single division-wide production computing environment with an Information Technology (IT) group.
My experience working with all these disparate processing architectures helps me identify and share insights with you about differences in the "care-abouts" from one development and operational context to another. My goal is to identify and put words to the issues and challenges facing the different types of developers and problem spaces so that, as an industry, we can better scale our lessons learned beyond our relatively small islands of immediate peers in the ocean that is embedded processing.
Jun 29 2009 2:46AM | Permalink | Email this | Comments (0) |
Blog This! using: Blogger.com | LiveJournal |
There are two sets of posts going out in this series in conjunction with my article on multiprocessing options – the series here and the series in our guest blog. Today’s guest post is from Mark Hermeling, Senior Product Manager, Wind River Systems. I encourage you to read both series of posts as they are intended to be complementary. I am alternating posts between the two series. My next post will expand on feedback-based multiprocessing.
If you missed the previous post in this series, ch...Read More
Jun 29 2009 12:57AM | Permalink | Email this | Comments (1) |
Blog This! using: Blogger.com | LiveJournal |
Multicore processors (processors with multiple processing cores) are being considered in more embedded designs. There are in general two drivers that are bringing people to multicore: performance and/or consolidation.
The performance driver is simple. Many devices need the best performance in the smallest package with the lowest power demands. A multicore processor provides more MIPS per Watt than a single core processor. In 'the old days' performance could be improved by increasing the processing frequency on the processor, but for many designs this is no longer the case. The networking industry especially has been ahead of the rest of the pack in the migration to multicore.
The consolidation driver covers the fact that a (for example) dual core can be used ...Read More
Jun 24 2009 3:17AM | Permalink | Email this | Comments (0) |
Blog This! using: Blogger.com | LiveJournal |
MDBM (Multidomain-based multiprocessing) is a taxonomy category that encompasses applications that span multiple software domains, such as cell phones, automobiles, and many consumer products. This type of multiprocessing has been the bread and butter of embedded-multicore designs for decades. The multiprocessing implementation in many MDBM applications is less about meeting high-end processing performance – rather it is more about: partitioning design, build, and test complexity into semi-independent and manageable chunks; providing more independence in the time domain for resources that would otherwise be in complex contention in a shared capacity such as in a single processor implementation; and providing an optimized processing platform for each type of task that needs to be performed, such as using a microcontroller, DSP, and general-purpos...Read More
Jun 17 2009 12:02AM | Permalink | Email this | Comments (0) |
Blog This! using: Blogger.com | LiveJournal |
There are two sets of posts going out in this series in conjunction with my article on multiprocessing options – the series here and the series in our guest blog. Today’s guest post is from Alan Gatherer, CTO and TI Fellow, High-Performance and Multicore Processing Business, Texas Instruments. I encourage you to read both series of posts as they are intended to be complementary. I am alternating posts between the two series. My next post will expand on multi-domain-based multiprocessing.
If you m...Read More
Jun 16 2009 11:50PM | Permalink | Email this | Comments (3) |
Blog This! using: Blogger.com | LiveJournal |
When programming multicore, debug becomes exponentially more difficult (or at least polynomially more difficult, for the literalists out there) with the number of cores. This is because there are so many more possible connections to be made (for N cores it is theoretically (N-1)!). When multicore was across a board, there was a lot of visibility to be had with a logic analyzer. But when the interconnect is “hidden” on the chip between cores the architecture has to be carefully designed to expose the right debug data without adding a large overhead in wiring to the chip. A chip that cannot be debugged is virtually useless in the multicore space.
Another item to consider - guaranteeing a certain order of events is critical when you have a complex interaction between multiple programs. Even in a single core...Read More
| Blogs | Recent Posts | Total Posts |
|---|---|---|
| How We See Embedded Processing | 0 | 18 |
| Embedded Processing | 0 | 41 |