The recently announced Synopsys IP Accelerated initiative perfectly illustrates how the functionality of a device is equally influenced by the hardware and the software. To enable applications on a particular device to use the interface IP like USB or Ethernet, a software program called a device driver is required to map the generic requests to the underlying hardware functions. Writing a device driver requires an in-depth understanding of how the hardware and software work for a given platform function.
The question in the title has been one of the most asked questions by my son lately. Or as my wife says, his brain is 90% focused on Minecraft and 10% on everything else. For those not familiar with Minecraft, it is a lego-like computer game or as the Minecraft website reads: “Minecraft is a game about breaking and placing blocks.” It has literally captured the imagination of my son and to lesser extent, of my daughter as well. They can build houses, boats, clouds, towers, bushes shaped like pokemons and so on. And since building the same stuff over and over again would be boring, the question of “What should I build next?” comes up a lot. As with any building environment (virtual or real), what you can build is bound only by the available building blocks. So the Minecraft developers have provided users with all sorts of building blocks like wood and stone. Other blocks like water and lava are also available and can be used to achieve interesting effects. Different coloring options put the finishing touch to any construction.
This month Nithya asked me to contribute a post on hybrid prototyping and add some color to how design teams have been benefitting from integration between virtual and FPGA-based prototypes. It’s been about six months since Synopsys announced the availability of a data exchange which links a Virtualizer Development Kit (VDK) to the HAPS FPGA-based prototyping system based on AMBA transactors and the HAPS UMRBus interface kit. Since that time we have further validated popular use scenarios for a hybrid prototype. So, what are the cases where there’s a benefit to connecting a SystemC TLM based model to an FPGA-based prototype?
Watching the Olympics this past summer was quite exciting. I enjoyed seeing athletes at the peak of their performance and multiple records broken in many sports. What we don’t see is the years of practice and work behind this excellence. These athletes work at the technique, strength, endurance and mental attitude of winning. To me, this is no different than the work that goes on behind the scenes of a new chip introduction or for that matter, any new product introduction.
Finally, nine months after the next-generation SoC project was kicked off, the first prototype board has finally arrived! There are just six months left to get Android and Linux up and running. Since Android should take full advantage of the latest hardware additions, let’s make sure we get it ported as quickly as possible. Unfortunately, it is not that easy. Before you can care about porting your OS and developing the drivers for your special hardware, you have to deal with the boring, but necessary initialization of the hardware. This is typically done by a so-called boot monitor. A boot monitor is a software program in ROM that gets launched after pressing the power-on button on your hardware. Even though the boot monitor is not a large piece of software (compared to the OS etc.), it provides complex functions and interacts with many hardware peripherals. As an example, the classic minimal functions of a boot loader are given below:
Transaction-level models are the main building blocks of virtual prototypes, which are used for early software development. In my last blog post, I briefly introduced the different kinds of software tasks and the implications for models. Today, I want to talk about the modeling requirements for early SoC bring up. As I mentioned, understanding the software requirements correctly provides two clear benefits: 1) it makes modeling easier through a more focused application and 2) it increases the value for the software developer through more tailored modeling capabilities such as debug features.
What do the Inchron Real Time Congress this week and my last weekend home project have in common? They both are all about complexity, real-time, apps and platforms those apps run on. In automotive and consumer domains, apps are running on platforms in systems of systems. The question to me at this point is how many platforms – like AUTOSAR, GENIVI, Android, IOS, Windows Mobile etc. – as well as versions of them can an apps interested user really handle?
The industry did it again! Once again we are tightening the loops from system-level to implementation even further. 2010 was the year in which TSMC added the system-level flow to their reference flows for the first time. This year’s TSMC Reference Flow 12 marks the second revision of a system-level flow in which we are connecting a semiconductor manufacturer.all the way up to the system-level!
This is a follow up post to my July 7th Blog entry called “Dealing with Moving Targets in Interesting Times”. In response to Nokia selling its modem division to Renesas I had thought about who the actual customers for system-design tools are in a landscape of consolidation and change. It turns out that there are actually more parties involved these days, which increases the potential for business but makes the interaction a bit more intricate. We are about to close the loop to manufacturing even tighter, just like we did in the days of PKS – Physically Knowledgeable Synthesis – back a decade ago.
Posted in Models