The FPMM outlines a methodology called Design for Prototyping, or DFP. DFP integrates fpga based prototyping seamlessly into the asic/SoC project, so the design can be more readily implemented and made available to end users as early as possible. The approach is said to deliver productivity benefits by connecting to system level tools, like virtual prototyping, for earlier software development and, later in the project, when hardware and software are integrated for the first time.
Partly, the collaborating companies are pointing to the abilities of the latest fpgas. Amos noted: "FPGAs have kept pace with Moore's Law - perhaps even driving it – which means even the largest designs can be prototyped efficiently. But, while fpgas have never been more capable, the challenges of developing SoCs have never been greater; developing complex SoCs and software takes time and money. That means it's very important to wring the last bit of productivity from the design flow and prototyping has a large role to play."
If SoC prototyping is such a common practice, why is the manual needed? Lesea: "We've drawn on our own experience; Xilinx has a long history of fpga prototyping. But the essence of how to prototype has never been captured in a book. So we looked for where the expertise exists."
One of the problems which the authors see with approaches such as emulation is the inverse relationship between accuracy and speed; if you want one, you sacrifice the other. FPGAs, they contend, allow users to benefit from both, running at speeds approaching real time while benefiting from rtl cycle accuracy. As an example, they cite the development of a baseband processor by Freescale.
Freescale wanted to speed SoC development because of the short life cycles of products aimed at mobile communications. It decided that if protocol testing could be undertaken in advance of first silicon, months could be saved – significant in a product with a life of maybe two years.
The 5million asic gates baseband processor included a StarCore dsp for modem processing and an ARM926 for application processing. This was partitioned into three of the four Xilinx fpgas on a HAPS-54 prototype board (see fig 1), with the digital rf design loaded into the fourth device. Rather than prototyping the analogue section, network data was sourced from a protocol tester.
Previously, such a design would have been tested using emulation, required weeks of evaluation. Using the techniques laid out in the FPMM, Freescale reduced the run time for protocol tests to one day. The approach allowed the project schedule to be accelerated and got hardware, software and systems engineers working together earlier.
Amos said: "DFP is a closer integration of prototyping and the technical requirements of the design project. It comprises two parts; technical guidance and procedural guidance. In many cases, the prototyping phase will be easier if the SoC is designed in an fpga friendly way. The software team is a critical path in an SoC project and they can make the design more fpga friendly from the start. If they do that, the result will be better software available more quickly."
Lesea supported Amos' view. "FPGA prototyping allows teams to verify the most complex systems, running with cycle accuracy at high speed while interacting with the target environment. This is important when validating requirements and the integration with hardware. In the end, prototyping is all about reducing risk, the cost and the time involved in respins," he concluded.
Prototyping system designs on fpgas
4 mins read
Software is a major – some might say the major – component of any system design and that software is often targeted at specialised hardware. Making sure the software works with the hardware in the way the system architect intended is a vital part of the development process, particularly when software can make or break a product's success.
There is, on the face of it, nothing new about prototyping a system design; engineers have been doing this for as long as electronics components have been available. But that has, in the main, been a hardware focused undertaking. Neither is there any novelty in prototyping a system design on an fpga. So why has eda company Synopsys has linked with fpga vendor Xilinx to produce the FPGA Based Prototyping Methodology Manual, or FPMM?
The answer is that the companies believe the move will help system designers and architects to make the prototyping process as smooth as possible. The Manual is aimed squarely at the development of custom devices. For the purposes of clarity, it refers to these as SoCs, even if they are asics, assps or some other custom part.
The FPMM has been written by Austin Lesea, Xilinx' principal engineer, Doug Amos, business development manager with Synopsys' solutions marketing division, and Rene Richter, Synopsys' CAE manager. The three have had the assistance of engineering teams from around the world.
Contributors include engineers from Freescale, LSI, STMicroelectronics, Synopsys, Texas Instruments and Xilinx. According to Amos, producing the book has been driven by two things. "Firstly, there's more pressure on the SoC itself," he said. "These not only feature multiple cpus, but there are also other engines and this brings different verification challenges. The other driver is the fact that software is the differentiator in many applications."
Lesea noted: "The trend is clear; as systems become more complex, more and more of the effort in an SoC project is expended on software. Take the smartphone as an example; it's the software that drives market acceptance."
The FPMM aims to help designers to develop in a timely fashion the SoC and the software which will run on it. The best way, the authors believe, is to use fpgas as a prototyping platform.
The foreword to the book is provided by Helena Krupnova, prototyping team leader with STMicroelectronics. She said: "FPGAs provide a platform for SoC development and verification unlike any other and their greatest value is their ability to provide a fast and accurate model of the SoC in order to allow the presilicon verification of the embedded software."
Amos expanded on this point. "In Synopsys' experience, most asic designs use fpgas for prototyping and more than 80% of high end designs are prototyped." That latter comment may seem strange, but other methods include virtual platforms and emulation.
But there is the open admission that the use of fpgas for design prototyping is not new. Why, then, is there the need for the FPMM? Amos said: "There are many pockets of expertise and many veterans; each has their own flavours and strengths. By collecting best practice together, we have taken the first steps to make design for prototyping even better."
Lesea took up the thread, claiming the FPMM will help in three ways. "Firstly, it's a good place to start when you're developing new prototypes. Secondly, the FPMM offers ideas and guidance, with content collected from experience and from prototyping teams around the world. Finally, the FPMM is a starting point; we hope its momentum will transfer online."
The FPMM outlines a methodology called Design for Prototyping, or DFP. DFP integrates fpga based prototyping seamlessly into the asic/SoC project, so the design can be more readily implemented and made available to end users as early as possible. The approach is said to deliver productivity benefits by connecting to system level tools, like virtual prototyping, for earlier software development and, later in the project, when hardware and software are integrated for the first time.
Partly, the collaborating companies are pointing to the abilities of the latest fpgas. Amos noted: "FPGAs have kept pace with Moore's Law - perhaps even driving it – which means even the largest designs can be prototyped efficiently. But, while fpgas have never been more capable, the challenges of developing SoCs have never been greater; developing complex SoCs and software takes time and money. That means it's very important to wring the last bit of productivity from the design flow and prototyping has a large role to play."
If SoC prototyping is such a common practice, why is the manual needed? Lesea: "We've drawn on our own experience; Xilinx has a long history of fpga prototyping. But the essence of how to prototype has never been captured in a book. So we looked for where the expertise exists."
One of the problems which the authors see with approaches such as emulation is the inverse relationship between accuracy and speed; if you want one, you sacrifice the other. FPGAs, they contend, allow users to benefit from both, running at speeds approaching real time while benefiting from rtl cycle accuracy. As an example, they cite the development of a baseband processor by Freescale.
Freescale wanted to speed SoC development because of the short life cycles of products aimed at mobile communications. It decided that if protocol testing could be undertaken in advance of first silicon, months could be saved – significant in a product with a life of maybe two years.
The 5million asic gates baseband processor included a StarCore dsp for modem processing and an ARM926 for application processing. This was partitioned into three of the four Xilinx fpgas on a HAPS-54 prototype board (see fig 1), with the digital rf design loaded into the fourth device. Rather than prototyping the analogue section, network data was sourced from a protocol tester.
Previously, such a design would have been tested using emulation, required weeks of evaluation. Using the techniques laid out in the FPMM, Freescale reduced the run time for protocol tests to one day. The approach allowed the project schedule to be accelerated and got hardware, software and systems engineers working together earlier.
Amos said: "DFP is a closer integration of prototyping and the technical requirements of the design project. It comprises two parts; technical guidance and procedural guidance. In many cases, the prototyping phase will be easier if the SoC is designed in an fpga friendly way. The software team is a critical path in an SoC project and they can make the design more fpga friendly from the start. If they do that, the result will be better software available more quickly."
Lesea supported Amos' view. "FPGA prototyping allows teams to verify the most complex systems, running with cycle accuracy at high speed while interacting with the target environment. This is important when validating requirements and the integration with hardware. In the end, prototyping is all about reducing risk, the cost and the time involved in respins," he concluded.
The FPMM outlines a methodology called Design for Prototyping, or DFP. DFP integrates fpga based prototyping seamlessly into the asic/SoC project, so the design can be more readily implemented and made available to end users as early as possible. The approach is said to deliver productivity benefits by connecting to system level tools, like virtual prototyping, for earlier software development and, later in the project, when hardware and software are integrated for the first time.
Partly, the collaborating companies are pointing to the abilities of the latest fpgas. Amos noted: "FPGAs have kept pace with Moore's Law - perhaps even driving it – which means even the largest designs can be prototyped efficiently. But, while fpgas have never been more capable, the challenges of developing SoCs have never been greater; developing complex SoCs and software takes time and money. That means it's very important to wring the last bit of productivity from the design flow and prototyping has a large role to play."
If SoC prototyping is such a common practice, why is the manual needed? Lesea: "We've drawn on our own experience; Xilinx has a long history of fpga prototyping. But the essence of how to prototype has never been captured in a book. So we looked for where the expertise exists."
One of the problems which the authors see with approaches such as emulation is the inverse relationship between accuracy and speed; if you want one, you sacrifice the other. FPGAs, they contend, allow users to benefit from both, running at speeds approaching real time while benefiting from rtl cycle accuracy. As an example, they cite the development of a baseband processor by Freescale.
Freescale wanted to speed SoC development because of the short life cycles of products aimed at mobile communications. It decided that if protocol testing could be undertaken in advance of first silicon, months could be saved – significant in a product with a life of maybe two years.
The 5million asic gates baseband processor included a StarCore dsp for modem processing and an ARM926 for application processing. This was partitioned into three of the four Xilinx fpgas on a HAPS-54 prototype board (see fig 1), with the digital rf design loaded into the fourth device. Rather than prototyping the analogue section, network data was sourced from a protocol tester.
Previously, such a design would have been tested using emulation, required weeks of evaluation. Using the techniques laid out in the FPMM, Freescale reduced the run time for protocol tests to one day. The approach allowed the project schedule to be accelerated and got hardware, software and systems engineers working together earlier.
Amos said: "DFP is a closer integration of prototyping and the technical requirements of the design project. It comprises two parts; technical guidance and procedural guidance. In many cases, the prototyping phase will be easier if the SoC is designed in an fpga friendly way. The software team is a critical path in an SoC project and they can make the design more fpga friendly from the start. If they do that, the result will be better software available more quickly."
Lesea supported Amos' view. "FPGA prototyping allows teams to verify the most complex systems, running with cycle accuracy at high speed while interacting with the target environment. This is important when validating requirements and the integration with hardware. In the end, prototyping is all about reducing risk, the cost and the time involved in respins," he concluded.
