Blog
Tell us What You Think
We want to know what you thought about this Discussion. Let us know by adding a comment.
Prototypes: Let’s get physical
Brian Bailey
12/20/2011 11:10 AM EST
Having discussed prototypes that are created before the existence of RTL, or model the hardware at a higher level of abstraction, we now turn out attention to those prototypes that are at the RT level or below, or in other words, rapid prototypes and silicon prototypes, collectively called physical prototypes. The characteristic that is common to all of these prototypes is that they are cycle accurate and thus represent the hardware with a level of accuracy not seen in the virtual prototypes. We still have a plethora of potential users for these prototypes, ranging from the hardware engineers themselves, to the verification team and the software team. The primary criteria used to decide which prototype is more useful are speed, cost and visibility into the hardware for debug. There is a second primary distinction between commercial available solutions and custom solutions.
Lauro Rizzatti, Vice President of Marketing, and GM of EVE-USA put it this way:
Within the physical prototyping space, there are two buckets: Commercial and in-house (or roll-your-own) FPGA prototyping boards. Commercially available FPGA prototypes are commonly generic solutions that will fit any design within the capacity of the board. They are able to handle any style of architecture, clock tree distributions, clock domains and memories structures.
In-house prototype boards are made for specific designs. They are not generic solutions, but specific for the application. Of course, there are exceptions, but a generic commercial tool is a compromise because it doesn’t have the speed of the in-house tool. An in-house tool will only fit one design. Commercial solutions don’t push the envelope of design capacity, which is limited to whatever capacity the few FPGAs mounted on a board can provide. The most we’ve seen commercially are 20 FPGAs on one board. It’s different with in-house prototyping boards that can have more than 50 FPGAs. We’ve heard anecdotally that there are 80 FPGAs on one big board in use today.
Austin Lesea of Xilinx and Doug Amos of Synopsys authored the book FPGA-Based Prototyping Methodology Manual. They make the general case for using physical prototypes: Prototyping today has morphed from the typical ASIC and ASSP of the past, to the System on a Chip (SoC) of today. Not only do the developers require their logic to work, but their multicore microprocessor, graphics engine, memory controller, peripherals, and all the software to work as well. The cost of failure (making new masks) means that a prototype is not an option, but a requirement.
Some projects seem to get hung up on the so-called“make or buy" decision about hardware. You have to have FPGA-based prototype hardware, you know how much logic, memory, fast IO and other resources are needed, so the only question left to agonize over is should one build or buy? Each has its advantages and disadvantages but it is important that the decision is made in the light of all the facts, and reappraised for each new project.
Who are the users for these prototypes? This is where each of the vendors sees it a little differently and this is probably explained by the capabilities that each of their systems has chosen to focus on. I will let them use their own words:
Howard Mao GM for the front end products group with Springsoft says: At most major companies today, prototyping is used for early software integration and system validation. The primary users are the software engineers who assume the hardware is running correctly on the prototype board. Secondary users are the hardware engineers who want to verify that the hardware is functions correctly in the system environment using high-speed prototype board. He goes on to say: For co-emulation applications, the use model is reversed with the hardware team as the primary user. The main reason is that co-emulation using prototype boards enables engineers to verify that critical IP, design modules or entire systems function correctly much earlier in the development cycle than is feasible with traditional in-circuit emulation.
EVE’s Rizzatti half agrees: Typically, they are software developers. The physical prototype is made for supporting software development and not hardware design at all.
Mick Posner, manager, product marketing, FPGA-based prototyping, Synopsys says: For FPGA-based prototyping the primary focus is validation – establishing by objective evidence that the design conforms to user needs. With this in mind the primary users are typically system engineers responsible for the product’s overall operation. These system engineers are typically software-focused as many of operations for today’s products are dictated by software applications on top of the base hardware capabilities. But before getting to system validation, usually other teams have already been using the FPGA-based prototype. The prototype can be defined by these secondary users even if their tasks may actually precede the system validation engineers’ task. Specific hardware and software validation would have been executed by members of both the hardware and software teams. The FPGA-based prototype may have been used to develop the lower level firmware of hardware-aware code all as part of the HW/SW integration and system validation tasks.
Lesea and Amos also see this as a progression of users: In order of usage during a given project, there is first is the system architect. Next is the hardware team (verilog/VHDL) or the classic "ASIC design" folks. Then there are the programmers who need to deliver their software on time, and working when the silicon arrives. Finally the marketing and sales organizations may use the prototype with customers (to run their apps intended for the SoC). We have also seen companies secure second round funding because they could demonstrate a working prototype. In terms of volume of usage, the primary users are software engineering, who uses the FPGA-based prototype to get a head-start on validating their embedded software.
There are fewer problems associated with getting models for physical prototypes because they are essentially using the implementation model. Getting the prototype up and running is normally performed by the hardware engineers although in larger companies they may have a team of people responsible for this and setting up the environment for in-circuit emulation or co-emulation.
Brian Bailey – keeping you covered
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
Lauro Rizzatti, Vice President of Marketing, and GM of EVE-USA put it this way:
Within the physical prototyping space, there are two buckets: Commercial and in-house (or roll-your-own) FPGA prototyping boards. Commercially available FPGA prototypes are commonly generic solutions that will fit any design within the capacity of the board. They are able to handle any style of architecture, clock tree distributions, clock domains and memories structures.
In-house prototype boards are made for specific designs. They are not generic solutions, but specific for the application. Of course, there are exceptions, but a generic commercial tool is a compromise because it doesn’t have the speed of the in-house tool. An in-house tool will only fit one design. Commercial solutions don’t push the envelope of design capacity, which is limited to whatever capacity the few FPGAs mounted on a board can provide. The most we’ve seen commercially are 20 FPGAs on one board. It’s different with in-house prototyping boards that can have more than 50 FPGAs. We’ve heard anecdotally that there are 80 FPGAs on one big board in use today.
Austin Lesea of Xilinx and Doug Amos of Synopsys authored the book FPGA-Based Prototyping Methodology Manual. They make the general case for using physical prototypes: Prototyping today has morphed from the typical ASIC and ASSP of the past, to the System on a Chip (SoC) of today. Not only do the developers require their logic to work, but their multicore microprocessor, graphics engine, memory controller, peripherals, and all the software to work as well. The cost of failure (making new masks) means that a prototype is not an option, but a requirement.
Some projects seem to get hung up on the so-called“make or buy" decision about hardware. You have to have FPGA-based prototype hardware, you know how much logic, memory, fast IO and other resources are needed, so the only question left to agonize over is should one build or buy? Each has its advantages and disadvantages but it is important that the decision is made in the light of all the facts, and reappraised for each new project.
Who are the users for these prototypes? This is where each of the vendors sees it a little differently and this is probably explained by the capabilities that each of their systems has chosen to focus on. I will let them use their own words:
Howard Mao GM for the front end products group with Springsoft says: At most major companies today, prototyping is used for early software integration and system validation. The primary users are the software engineers who assume the hardware is running correctly on the prototype board. Secondary users are the hardware engineers who want to verify that the hardware is functions correctly in the system environment using high-speed prototype board. He goes on to say: For co-emulation applications, the use model is reversed with the hardware team as the primary user. The main reason is that co-emulation using prototype boards enables engineers to verify that critical IP, design modules or entire systems function correctly much earlier in the development cycle than is feasible with traditional in-circuit emulation.
EVE’s Rizzatti half agrees: Typically, they are software developers. The physical prototype is made for supporting software development and not hardware design at all.
Mick Posner, manager, product marketing, FPGA-based prototyping, Synopsys says: For FPGA-based prototyping the primary focus is validation – establishing by objective evidence that the design conforms to user needs. With this in mind the primary users are typically system engineers responsible for the product’s overall operation. These system engineers are typically software-focused as many of operations for today’s products are dictated by software applications on top of the base hardware capabilities. But before getting to system validation, usually other teams have already been using the FPGA-based prototype. The prototype can be defined by these secondary users even if their tasks may actually precede the system validation engineers’ task. Specific hardware and software validation would have been executed by members of both the hardware and software teams. The FPGA-based prototype may have been used to develop the lower level firmware of hardware-aware code all as part of the HW/SW integration and system validation tasks.
Lesea and Amos also see this as a progression of users: In order of usage during a given project, there is first is the system architect. Next is the hardware team (verilog/VHDL) or the classic "ASIC design" folks. Then there are the programmers who need to deliver their software on time, and working when the silicon arrives. Finally the marketing and sales organizations may use the prototype with customers (to run their apps intended for the SoC). We have also seen companies secure second round funding because they could demonstrate a working prototype. In terms of volume of usage, the primary users are software engineering, who uses the FPGA-based prototype to get a head-start on validating their embedded software.
There are fewer problems associated with getting models for physical prototypes because they are essentially using the implementation model. Getting the prototype up and running is normally performed by the hardware engineers although in larger companies they may have a team of people responsible for this and setting up the environment for in-circuit emulation or co-emulation.
Brian Bailey – keeping you covered
If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
|
|
|
|
|
Navigate to related information