Myriad 2 is a vision processor by Movidius that delivers high-performance computational imaging and visual awareness in severely power-constrained environments. For the latest Myriad Development Kit (MDK), Movidius has introduced new tools integrated into the Eclipse framework, partly designed and developed by toem: Trace Profiler and Graph Designer.
Silexica provides a complete parallel software development tool suite for programming complex multicore applications. Integrating impulse adds impressive visualization options to the SLX programming tools.
Based on early software performance and power estimation technologies, the tools enable detailed insight into the capabilities of multicore platform architectures even in pre-silicon design stages. Silexica provides custom programming environments, tailored for selected off-the-shelf multicore chips and IP blocks.
(from Edo Franzi, uKos.ch) uKOS is a multi-tasking OS suitable for small embedded µController systems. I developed uKOS early in 1992 during the Khepera mobile robot project.
When I designed Khepera I had to think about “how to write code to control it”. So, this was the starting point of uKOS. The first implementation was written in CALM assembler (a LAMI-EPFL tool). I have completely rewritten uKOS in C in 1996; the used host computer was a Mac running OS9 with the MPW environment. Now Apple has switched to OSX (unix world) and I decided to reactivate and update it, and to share the ideas and the experiences cumulated during this project and use GCC environment to maintain it. All the sources will be available for a download. I consider this development as an open source project. I hope that this project will interest all the people that would like to be inspired by all the work I did. I do not ask royalties or licenses for the usage of all this project (schematics or sources). To increase the quality of this work all the feedback, suggestions, recommendations, etc. are welcome. Please, consult the download page regularly to discover all the latest documents, application notes, etc.
The spin project was initiated by a more spontaneous idea. After first outcome, it is time to think if it really makes sense and why (I am) not staying with systemC. Lets start with a simple question.
What is bad about systemC ?
SystemC is not really bad and neither is C++, but there are several issues that make it difficult to use, especially in Virtual Prototyping:
C++ is difficult
I guess there are not many people who don't say this. Even if I worked many years in C++/UML Architecture, compared to Java, I must say that C++ is really challenging, especially when it comes up with generics (generously used in systemC).
What I found is that hw people usually don't like C++. They can do C and they don't know Java (so difficult to say if they would like it). And it is difficult to convince hw people to start with C++ or to find people who can do both.
We are talking about Virtual Prototyping, we don't want to develop a new windows killer application, we just want to sketch hw! So the optimal language should be easy enough that hw people are able to define their hw in a simple way.
Mid of 2011 I changed to a new project doing eclipse plugin development for a patent management application. In parallel I was still supporting the company of my former project. It was about UMTS prototyping in systemC . At this time, switching between those very different projects, I felt more and more uncomfortable with systemC /C++ and all its tooling around. So I got the idea, why not doing prototyping in java instead of systemC ?
Java and a development environment like eclipse give a lot of efficiency to the developer. Java is much easier to use, to read and to extent. But this is not the point in prototyping. Important is simulation speed. That’s basically the main reasons why doing prototyping in a high-level language. It’s just much faster that RTL based simulations (but never fast enough).
With the introduction of Just-In Time compilation (e.g. Hotspot), Java execution speed has been improved drastically. Nevertheless I was very unsure at the beginning of this project if will be able to reach systemc /C++ performance. So I tried first with a simple scheduler, set up simple examples and compared with systemC. First results were very impressive, just threaded processes showed a very bad performance, especially under Linux.