We've already had CDNLive EMEA, but here is a look at a presentation from CDNLive Silicon Valley by Amlogic on how they do software development using both the Protium and Palladium platforms. It was presented by Jerry Cao, the director of platform software. He started by pointing out that Amlogic doesn't just sell SoCs, they have to provide reference software. As a result, any delay in the software is also a delay in revenue. But software development needs to get started and cannot just wait for availability of the SoC. The software needs to be ready to run when silicon comes back from the fab. However, there are limits to what a software development team can put up with. “We are software guys, we don’t want to know everything about the chip. We want a normal development flow: compiler, download, and run on platform.” It also has to be fast: "Yeah, we understand it is not the real speed. But we want to boot the kernel in minutes. The set-top box runs Android, we need to boot full Android in hours (overnight).” Palladium and Protium Methodology They had tried FPGA prototyping but, without any dedicated resources, it was just too hard. They needed to modify the design to get the platform running so in practice it was just too much trouble. So they switched to a methodology based on Palladium emulation and Protium FPGA-based prototyping. The big attraction was that they didn't need to make any changes to the design to get things up and running. Out of the box, they get 1MHz with the Palladium platform and 5MHz with the Protium platform. They knew that with some more effort, they could get the Protium platform's speed up more, but without a team to help, "that's what we get." For software developers it is just like running on real silicon. Compile the code, "flash", and run. Their software development has to take place in parallel with the hardware design. They start by not entirely trusting the hardware team, so they have a set of use cases to check that they have good hardware. There is no point in a software developer trying to chase down a subtle bug, if it turns out that the hardware is the source of the error. However, the purpose of these test suites is not to help hardware verification, it is to give the software team confidence that the hardware works correctly, at least in the appropriate areas. Later in the design process, however, running a real software load allowed accurate power measurements to be gathered, something that can't really be done entirely at the RTL level since there just aren't good vectors for power analysis that can simply be created within the chip design team. The whole process is shown in the above diagram. Once RTL is available, then the iterative software development process can start. This continues with subsequent RTL drops until RTL is frozen, the chip tapes out, and, eventually, silicon is received. I've not personally done this sort of software development, but I have done development where the compiler is itself under development, and it is most frustrating. Some problems are obviously your own (off-by-one errors in loops, for example) and others (the system crashes) might be either. It really slows development down. If you have a solid compiler or hardware, you assume all bugs are your own and work hard to identify them. If you are in an unreliable environment, it is all too easy to assume that bugs are not in your code and not put in the effort. Of course there is a lot of finger-pointing. I hate to think what it is like developing for a new microprocessor where the chip, the compiler, the operating system, and your own code are all moving pieces. Detailed Methodology Their use of the Palladium and Protium platforms was to use Palladium for early driver bringup. The Palladium platform can be partitioned to run multiple jobs at the same time, and do parallel verification of different drivers. The big advantage of the Palladium platform (over the Protium platform, or even real silicon) is that it is easy to examine any signal, capture the contents of memory, stop the system, and so on. However, it is slower than the Protium platform, so when the system is close to being stable, then the Protium platform can be used for full system verification to bring up the entire software stack (Android up to the user interface), verify full system functionality, and even run standard software benchmarks such as Imbench or Antutu. Whether it was the Palladium platform or the Protium platform being used, the rest of the environment was the same, with virtual display, SpeedBridge interface, and more to interface the "chip" to the test environment in which the real chip would eventually have to function. See the above image. Results One of the results of this type of software development process that the team hopes for is that when they get the silicon, it boots up and runs. The experience of Jerry's team is that basic Android came up on the chip in 30 minutes and a full set-top box demo was delivered to a customer in three days. That was just 20% of what was previously required. Similarly, to get to the first software release took just 15 days after receiving silicon (two weeks), a saving of about two months. See the above graphs. During the Q&A, someone asked how they divided use between one Palladium XP emulator and two Protium (Protia?) platforms. Jerry said it was mostly one Protium platform for mutlimedia (display and decoding) and one for the platform software team, at least in the early phase until Android would come up properly. Palladium was mainly used by the platform software team unless the display team needed to do a lot of detailed debugging. Even when silicon was back, problems would often be debugged on the Palladium platform since the visibility is a lot better than on silicon. Conclusion and Future This methodology allowed continuous software development before silicon was back. The Palladium platform also has unique debug capabilities lacking in silicon for root-cause analysis. Results: On-time software delivery. You can see the full presentation (you need to register if you don't have a Cadence username, but you do not need to have been an attendee at CDNLive).![]()
![]()
↧