Open source virtual prototyping for faster hardware and software co-design
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Delbergue, Guillaume
Co-designing hardware and software is a long and iterative process specific to embedded system design. Mainly driven by hardware prototype iterations, it makes project time and cost hard to forecast. While software modifications can be done in a modular and non-destructive way, reworking on hardware implies production of new prototypes. Moreover, software optimizations being strongly hardware-dependent, the software development could remain idle during hardware re-prototyping. This uncertainty on time and cost makes embedded systems projects hard to fund. In the end, ambitious projects are mostly reserved to large companies. Hardware simulation and virtual prototyping contributes to solve this issue. A virtual prototype consists in a software application representing the system's hardware behavior, allowing system's software to be directly executed without the real hardware. Once available, a virtual prototype reduces embedded system time-to-market and development cost. However, virtual prototype development cost makes them inaccessible. Hardware simulation leverages models which are hard to find and which interoperability is lacking. Each company should invest and maintain its own virtual prototyping solution. That is why in Hiventive, we believe that the emergence of an open source, unified, normalized hardware and software ecosystem leveraging state-of-the-art virtual prototyping technologies and methodologies is necessary to boost and widely generalize the use of virtual prototypes. Thus, we will present our innovative open source collection of solutions to enable and empower virtual prototyping for everyone.
 Hi everyone, I'm Guendel Bernge and I will talk to you about open source virtual prototyping for faster hardware and software code design. So first, does anyone in this room already heard about virtual prototyping? Okay, okay, so let's start. So sorry, I only have just 10 minutes, so let's start. So a virtual prototype is a software application simulation. This is a hardware behavior. It provides ready to execute a development for your next platform. Virtual prototype aims to solve various use cases. Okay, it's okay for everyone? Okay, let's continue. Okay, so it enables after development that the rest of the testing begins before the real hardware is available and it can also be used for later use when the hardware is available. It is an alternative to prototyping on the hard boards. It expands the software developers productivity allowing them to develop on its other development platform months before the real hardware prototype. Okay, let's slow down. Okay, so how do you design your product now? So you have an ID and you ask to your software developers and your hardware developers to build their parts, so application and the physical prototypes. During the development, you don't really have communication between both teams, between the hardware team and your software team. And then you have the integration. So the hardware team gives physical prototypes to the software team and software team can begin to run the application on it. Most of the time, it doesn't work. So you have to go back and to try again. And finally you have your product, but you spend time, you lose your time, and you spend your lost money. So here is a new way to design your product. You still have ID, of course, but instead of building a physical prototype and waiting for it, you design a virtual product. So using a virtual prototype. So people from software can directly run their software without having to wait for the physical board in their hands. It enables you so continuous integration. Okay, great. So just to slow down, so virtual prototyping is a technology which is a software application simulating the hardware behavior. It provides a ready to execute environments for your next platforms. It allows you fast virtual prototype for hardware and software co-simulation. Okay, so how does it look like? Let's take an example. Here it's just a simple Raspberry Pi. So a Raspberry Pi is composed of a system on chip, the BCM2835 or 36 or 37, depending of the revision of the Raspberry Pi. Inside this system on chip, you have your CPU, your M, your UART, GPIO, or control. They are all called IP inside your SOC, also called as peripherals. And we will model all this IP. The model will represent the behavior of your IP, which it will be like a software application. And we will model the entire system on chip. The result is a binary, a software application where you can run your original bare-material binary operating system like on your physical board. Okay, so what does a model look like? And how do you build a model? So we just take the data sheet, we extract the architecture behavior, so it's from the programmer view. And we describe, for example, here is for the PL011, we extract and we describe all registers and fields and the behavior. For example, when you write on a specific register, here it's for clearing the interrupts, then we update the interrupt status to propagate the value. Okay, cool, that's look amazing. But this is what people feel when they want to start building virtual prototypes. Why? First, models are hard to find. So if you want to start now, you will have some issue to find some models on GitHub, on GitLab, or anywhere else. You have to, you need a new quest, develop, development of models. Many models are missing for your rights level abstractions, depending on the accuracy you need. You have, there is an insufficient communication of efforts on models. There are too much components, you can't model all components, sorry, instead we should commonize the efforts and the industrial efforts are not shared. Virtual prototypes involve easy development, today it's hard to start from scratch. There is a model interoperability issue, which doesn't mean easy reuse. Some people are inventing their own standard, degreasing the interoperability between models. And of course, a non-promised framework deployment is currently missing. Okay, so what's the multi-point of with virtual prototypes? So first, the key is the interoperability. An open standard API is a key. If you want to build models, it's okay. But if you want people to reuse your models, you need interoperability. You would like to interconnect all models you can find on GitHub or GitLab, really easy using open standard. The reuse ability, you don't want to reinvent the wheel. You would like to take advantage of the community. So you would like to improve and contribute to existing models instead of duplicating the code. You don't want to spend a month to start, for example, a Raspberry Pi. So you need good documentation and easy tutorials. And finally, you want something easy to build. You don't want to read a book with thousands of pages to know how to write a model. So that's why we are considering higher level language to describe IP models. And for us, the key is clearly the open source. The open source is the unsworn of all those issues. So here is just a demo. As we have no time, so it's not really for real. It's a boot of Raspberry Pi, sorry, for the quality. So we have a Linux kernel booting on a virtual prototype. So you can see it's really fast. It's run on a laptop. And you can directly interact with a virtual prototype as you can do on a real physical board. It's a low-force demo. And we are currently working on intuitive tools for design. So we would like to provide a place to share what we call virtual components models. Continuous integration so people can directly test their software on their hardware to decrease regression. A graphical designer to assemble different models and, of course, community support. So we believe we can make hardware and software development more agile. So with more intuitive virtual component editor, with open source virtual prototype readers, with clever system simulator, we would like to, from the description of the virtual prototype, we would like to be able to export initial build of materials and schematic. And this, of course, enables more collaborative development, open source hardware, community, and functional system integration test automation. So sorry, time is over. But we are currently opening a beta next week with including the virtual prototype of Raspberry Pi. So if you want to try, so just join the beta. We will, of course, then after the beta, open everything to the community on our GitHub, on GitHub.com-iVentive. So if you want to try or to give us feedback with the Raspberry Pi, we would be happy to hear your feedback. Thank you. Questions? I have a question. How do you attempt to achieve interoperability? Because there is system C and TLM. These are established systems in the industry. Okay. So the question is about interoperability with the Raspberry Pi. Okay, yes, so I didn't really talk about system C and TLM. System C and TLM are industrial standards, which is an open standard used for interoperability between IPs, but also for models. Okay, so currently we are directly supporting system C and TLM. System C, we mainly focus our development on TLM because TLM provides an interface with a higher level of abstraction for fast simulation. And we mainly focus our development for software. So we would like fast virtual prototype, so fast virtual platforms. So currently we mainly support TLM interface. But of course you can integrate existing system C model, which may be with a lower abstraction level like RTL. So you can mix all of them in a world virtual prototype. Yes? Yeah. It's actually two questions in one. It's about the simulation of the modules of the components. How do we know, for example, if you use the complex I2C chip, how do we know it's well configured? Because most of the software that works on the Raspberry Pi is not a good idea. So if you put the wrong registers, the wrong bits in the registers, then it won't work. The software will run, but it won't work. How do you plan on getting the output of your components? Is it about the behavior of the register when you write on it? No, it's what it does when you write on those registers. Yes. For example, a radio chip will start emitting or transmitting something. Of course. How do you know it? You did the right thing. Oh, okay. I see. It's about the compliance of your model. Okay. I see. This is a good question. So the question is about how can we check the model, finally, is right according to the hardware, according to the real hardware. Okay. This is a really good question. So we can say the model is totally right. We are only following the data sheet. But we believe with open hardware, we can have accurate models because we have all the source code. And we hope we will have more IP open and so more accurate models. But there is another answer. People today, many people today begin to develop the hardware with low-level like RTL. But you can do the reverse. You can begin with your model and your model will drive then your development. Your model can be used from the software and then for the hardware to write low-level part like the RTL with the HDL or the RELOG. Okay. There are many questions. I'm sorry, but we have a talk in three minutes. So somebody with a very urgent important question. Yes. How do you plan on getting manufactured data for their custom IP of their chips versus I had a USB hub for my previous board that I worked on. How do you know for sure that you have the correct parameter? Okay. So the question is about how can we get the data sheet from a private IP or private peripherals? Okay. This is a good question. So we can spend our night to do reverse engineering, but we don't have time. We need to sleep. Now, currently we are trying to discuss with manufacturer and IP provider to see how industry can share more, maybe more models with the community to avoid to re-event the wheel. Maybe because the IP provider already have models. They do models when they build their system on chip. So if we convince them to share models to the community, I hope it will be great. But currently with private IP, we don't really have an answer. Okay. Let's thank you again. Thanks. Hi. How it goes. It's wonderful.
 Hi everyone, I'm Guendel Bernge and I will talk to you about open source virtual prototyping  for faster hardware and software code design.  So first, does anyone in this room already heard about virtual prototyping?  Okay, okay, so let's start.  So sorry, I only have just 10 minutes, so let's start.  So a virtual prototype is a software application simulation.  This is a hardware behavior.  It provides ready to execute a development for your next platform.  Virtual prototype aims to solve various use cases.  Okay, it's okay for everyone?  Okay, let's continue.  Okay, so it enables after development that the rest of the testing begins before the  real hardware is available and it can also be used for later use when the hardware is  available.  It is an alternative to prototyping on the hard boards.  It expands the software developers productivity allowing them to develop on its other development  platform months before the real hardware prototype.  Okay, let's slow down.  Okay, so how do you design your product now?  So you have an ID and you ask to your software developers and your hardware developers to  build their parts, so application and the physical prototypes.  During the development, you don't really have communication between both teams, between  the hardware team and your software team.  And then you have the integration.  So the hardware team gives physical prototypes to the software team and software team can  begin to run the application on it.  Most of the time, it doesn't work.  So you have to go back and to try again.  And finally you have your product, but you spend time, you lose your time, and you spend  your lost money.  So here is a new way to design your product.  You still have ID, of course, but instead of building a physical prototype and waiting  for it, you design a virtual product.  So using a virtual prototype.  So people from software can directly run their software without having to wait for the physical  board in their hands.  It enables you so continuous integration.  Okay, great.  So just to slow down, so virtual prototyping is a technology which is a software application  simulating the hardware behavior.  It provides a ready to execute environments for your next platforms.  It allows you fast virtual prototype for hardware and software co-simulation.  Okay, so how does it look like?  Let's take an example.  Here it's just a simple Raspberry Pi.  So a Raspberry Pi is composed of a system on chip, the BCM2835 or 36 or 37, depending  of the revision of the Raspberry Pi.  Inside this system on chip, you have your CPU, your M, your UART, GPIO, or control.  They are all called IP inside your SOC, also called as peripherals.  And we will model all this IP.  The model will represent the behavior of your IP, which it will be like a software application.  And we will model the entire system on chip.  The result is a binary, a software application where you can run your original bare-material  binary operating system like on your physical board.  Okay, so what does a model look like?  And how do you build a model?  So we just take the data sheet, we extract the architecture behavior, so it's from the  programmer view.  And we describe, for example, here is for the PL011, we extract and we describe all registers  and fields and the behavior.  For example, when you write on a specific register, here it's for clearing the interrupts,  then we update the interrupt status to propagate the value.  Okay, cool, that's look amazing.  But this is what people feel when they want to start building virtual prototypes.  Why?  First, models are hard to find.  So if you want to start now, you will have some issue to find some models on GitHub,  on GitLab, or anywhere else.  You have to, you need a new quest, develop, development of models.  Many models are missing for your rights level abstractions, depending on the accuracy you  need.  You have, there is an insufficient communication of efforts on models.  There are too much components, you can't model all components, sorry, instead we should  commonize the efforts and the industrial efforts are not shared.  Virtual prototypes involve easy development, today it's hard to start from scratch.  There is a model interoperability issue, which doesn't mean easy reuse.  Some people are inventing their own standard, degreasing the interoperability between models.  And of course, a non-promised framework deployment is currently missing.  Okay, so what's the multi-point of with virtual prototypes?  So first, the key is the interoperability.  An open standard API is a key.  If you want to build models, it's okay.  But if you want people to reuse your models, you need interoperability.  You would like to interconnect all models you can find on GitHub or GitLab, really easy  using open standard.  The reuse ability, you don't want to reinvent the wheel.  You would like to take advantage of the community.  So you would like to improve and contribute to existing models instead of duplicating  the code.  You don't want to spend a month to start, for example, a Raspberry Pi.  So you need good documentation and easy tutorials.  And finally, you want something easy to build.  You don't want to read a book with thousands of pages to know how to write a model.  So that's why we are considering higher level language to describe IP models.  And for us, the key is clearly the open source.  The open source is the unsworn of all those issues.  So here is just a demo.  As we have no time, so it's not really for real.  It's a boot of Raspberry Pi, sorry, for the quality.  So we have a Linux kernel booting on a virtual prototype.  So you can see it's really fast.  It's run on a laptop.  And you can directly interact with a virtual prototype as you can do on a real physical  board.  It's a low-force demo.  And we are currently working on intuitive tools for design.  So we would like to provide a place to share what we call virtual components models.  Continuous integration so people can directly test their software on their hardware to decrease  regression.  A graphical designer to assemble different models and, of course, community support.  So we believe we can make hardware and software development more agile.  So with more intuitive virtual component editor, with open source virtual prototype  readers, with clever system simulator, we would like to, from the description of the  virtual prototype, we would like to be able to export initial build of materials and schematic.  And this, of course, enables more collaborative development, open source hardware, community,  and functional system integration test automation.  So sorry, time is over.  But we are currently opening a beta next week with including the virtual prototype of Raspberry  Pi.  So if you want to try, so just join the beta.  We will, of course, then after the beta, open everything to the community on our GitHub,  on GitHub.com-iVentive.  So if you want to try or to give us feedback with the Raspberry Pi, we would be happy to  hear your feedback.  Thank you.  Questions?  I have a question.  How do you attempt to achieve interoperability?  Because there is system C and TLM.  These are established systems in the industry.  Okay.  So the question is about interoperability with the Raspberry Pi.  Okay, yes, so I didn't really talk about system C and TLM.  System C and TLM are industrial standards, which is an open standard used for interoperability  between IPs, but also for models.  Okay, so currently we are directly supporting system C and TLM.  System C, we mainly focus our development on TLM because TLM provides an interface with  a higher level of abstraction for fast simulation.  And we mainly focus our development for software.  So we would like fast virtual prototype, so fast virtual platforms.  So currently we mainly support TLM interface.  But of course you can integrate existing system C model, which may be with a lower abstraction  level like RTL.  So you can mix all of them in a world virtual prototype.  Yes?  Yeah.  It's actually two questions in one.  It's about the simulation of the modules of the components.  How do we know, for example, if you use the complex I2C chip, how do we know it's well  configured?  Because most of the software that works on the Raspberry Pi is not a good idea.  So if you put the wrong registers, the wrong bits in the registers, then it won't work.  The software will run, but it won't work.  How do you plan on getting the output of your components?  Is it about the behavior of the register when you write on it?  No, it's what it does when you write on those registers.  Yes.  For example, a radio chip will start emitting or transmitting something.  Of course.  How do you know it?  You did the right thing.  Oh, okay.  I see.  It's about the compliance of your model.  Okay.  I see.  This is a good question.  So the question is about how can we check the model, finally, is right according to  the hardware, according to the real hardware.  Okay.  This is a really good question.  So we can say the model is totally right.  We are only following the data sheet.  But we believe with open hardware, we can have accurate models because we have all the  source code.  And we hope we will have more IP open and so more accurate models.  But there is another answer.  People today, many people today begin to develop the hardware with low-level like RTL.  But you can do the reverse.  You can begin with your model and your model will drive then your development.  Your model can be used from the software and then for the hardware to write low-level part  like the RTL with the HDL or the RELOG.  Okay.  There are many questions.  I'm sorry, but we have a talk in three minutes.  So somebody with a very urgent important question.  Yes.  How do you plan on getting manufactured data for their custom IP of their chips versus  I had a USB hub for my previous board that I worked on.  How do you know for sure that you have the correct parameter?  Okay.  So the question is about how can we get the data sheet from a private IP or private peripherals?  Okay.  This is a good question.  So we can spend our night to do reverse engineering, but we don't have time.  We need to sleep.  Now, currently we are trying to discuss with manufacturer and IP provider to see how industry  can share more, maybe more models with the community to avoid to re-event the wheel.  Maybe because the IP provider already have models.  They do models when they build their system on chip.  So if we convince them to share models to the community, I hope it will be great.  But currently with private IP, we don't really have an answer.  Okay.  Let's thank you again.  Thanks.  Hi.  How it goes.  It's wonderful.
Open_source_virtual_prototyping_for_faster_0_155.png Open_source_virtual_prototyping_for_faster_156_527.png Open_source_virtual_prototyping_for_faster_528_635.png Open_source_virtual_prototyping_for_faster_636_695.png Open_source_virtual_prototyping_for_faster_696_743.png Open_source_virtual_prototyping_for_faster_744_791.png Open_source_virtual_prototyping_for_faster_792_1451.png Open_source_virtual_prototyping_for_faster_1452_1631.png Open_source_virtual_prototyping_for_faster_1632_3275.png Open_source_virtual_prototyping_for_faster_3276_3791.png Open_source_virtual_prototyping_for_faster_3792_5099.png Open_source_virtual_prototyping_for_faster_5100_5903.png Open_source_virtual_prototyping_for_faster_5904_6131.png Open_source_virtual_prototyping_for_faster_6132_6191.png Open_source_virtual_prototyping_for_faster_6192_8015.png Open_source_virtual_prototyping_for_faster_8016_10007.png Open_source_virtual_prototyping_for_faster_10008_10799.png Open_source_virtual_prototyping_for_faster_10800_11471.png Open_source_virtual_prototyping_for_faster_11472_12335.png Open_source_virtual_prototyping_for_faster_12336_20507.png Open_source_virtual_prototyping_for_faster_20508_20555.png Open_source_virtual_prototyping_for_faster_20556_20689.png