Blog
Comment
KarlS
Parsing the HDL and using embedded memory blocks for control logic and registers ...
Max the Magnificent
Hi Brian -- this is an interesting idea -- I wonder what the folks at Altera and ...
Do we need a new FPGA structure for prototyping?
Brian Bailey
2/22/2011 1:32 PM EST
I have been talking to a lot of people recently about the subject of prototyping. Not only do I believe that it is one of the most important applications related to the success of ESL, but to the future of design at any level of abstraction.
RTL simulation is a technology of the past, and while it still has a role to play in the verification and debug of smallish blocks, it is too slow for the kind of verification that companies are demanding before releasing a chip for production. When enough of the system is assembled to be able to see how sub-systems interact with each other, an RTL simulator is too slow or consumes too much memory to be able to simulate the types of scenarios that would allow realistic verification to be performed.
The solutions we need go in different directions based on abstraction. For the higher levels of abstraction and the most complete view of the system we have to rely on virtual prototypes. While these still rely on simulation technology, and today most of these are still event-based simulation technologies, over time we can expect to see other types of simulation becoming equally important. However, since this is a blog about FPGAs, I will not delve too deeply into this topic here. Virtual prototypes also rely on RTL prototypes in many cases, and this is a subject I will come back to in another blog.
The other direction is being able to execute increasing amounts of the design at the RT level of abstraction. Two technologies are dominating this space – emulation and prototyping, but in my mind neither of them is 100% solving the problem today.
Emulation has quick turn-around times and good controllability and visibility, but is too expensive for many of the applications that such a prototype is needed for, such as software development. While it may be used for some critical code sections, it is just not feasible to have an emulator on every software engineer’s desk. Prototyping is a much cheaper solution, but suffers in terms of controllability and visibility and has much longer turn-around times. In fact most of the people I have spoken to recently have said that turn-around time is the biggest problem associated with adoption of prototypes. This makes them more useable during the later parts of a design flow when the design is not changing so fast, but not so convenient when the RTL may be undergoing rapid changes.
So what does it take to solve these problems? While a lot of effort has been placed on increasing the debugability within the FPGA, I personally do not see this as the biggest problem. We have to tackle the turn-around time. Companies such as Synopsys (Synplicity) have two modes of operation in their FPGA synthesis flow – one for targeting the FPGA when it is to become part of the final production system and the other when it is to be used in a prototype. The prototype implementation does not require a totally optimal design so long as it is functionally equivalent. That means that place and route is not such a difficult task and – when incremental changes are made – large pieces of the layout can be left intact. The only guiding issue is that the designs should fit in the FPGA resources available. Resources that are not used can always be used for debug circuitry if and when needed. This fast mode does speed up the turn-around cycle, but still not as much as an emulator. So what gives emulators the advantage here?
The trick here is the routing structures that emulators employ. While the major emulation vendors use very different mechanism to do this, they are all designed to make compilation faster. In one vendor's solution, they bring about a certain level of independence in placement, and make timing more predictable. In other words they use hardware to make the software process of compilation easier and faster.
Now, the utilization of this type of technology is not in the best interests for the FPGA vendors in general, because these modified routing structures are larger than the equivalent routing resources found within an FPGA and thus would not be as good for implementing an actual design. If the adoption of prototyping grows, however, then there may very well be a market for some custom prototyping chips that offer better turn-around times compared to an FPGA but not at the same cost as those designed specifically for an emulator.
This may be a bit of a "Catch 22" situation where a prototyping company will have to take on the risk of designing a new special-purpose chip to solve the turn-around time problem before the market has grown enough to be able to justify its development. I wonder if any of them has the nerve to try?
Brian Bailey – keeping you covered
RTL simulation is a technology of the past, and while it still has a role to play in the verification and debug of smallish blocks, it is too slow for the kind of verification that companies are demanding before releasing a chip for production. When enough of the system is assembled to be able to see how sub-systems interact with each other, an RTL simulator is too slow or consumes too much memory to be able to simulate the types of scenarios that would allow realistic verification to be performed.
The solutions we need go in different directions based on abstraction. For the higher levels of abstraction and the most complete view of the system we have to rely on virtual prototypes. While these still rely on simulation technology, and today most of these are still event-based simulation technologies, over time we can expect to see other types of simulation becoming equally important. However, since this is a blog about FPGAs, I will not delve too deeply into this topic here. Virtual prototypes also rely on RTL prototypes in many cases, and this is a subject I will come back to in another blog.
The other direction is being able to execute increasing amounts of the design at the RT level of abstraction. Two technologies are dominating this space – emulation and prototyping, but in my mind neither of them is 100% solving the problem today.
Emulation has quick turn-around times and good controllability and visibility, but is too expensive for many of the applications that such a prototype is needed for, such as software development. While it may be used for some critical code sections, it is just not feasible to have an emulator on every software engineer’s desk. Prototyping is a much cheaper solution, but suffers in terms of controllability and visibility and has much longer turn-around times. In fact most of the people I have spoken to recently have said that turn-around time is the biggest problem associated with adoption of prototypes. This makes them more useable during the later parts of a design flow when the design is not changing so fast, but not so convenient when the RTL may be undergoing rapid changes.
So what does it take to solve these problems? While a lot of effort has been placed on increasing the debugability within the FPGA, I personally do not see this as the biggest problem. We have to tackle the turn-around time. Companies such as Synopsys (Synplicity) have two modes of operation in their FPGA synthesis flow – one for targeting the FPGA when it is to become part of the final production system and the other when it is to be used in a prototype. The prototype implementation does not require a totally optimal design so long as it is functionally equivalent. That means that place and route is not such a difficult task and – when incremental changes are made – large pieces of the layout can be left intact. The only guiding issue is that the designs should fit in the FPGA resources available. Resources that are not used can always be used for debug circuitry if and when needed. This fast mode does speed up the turn-around cycle, but still not as much as an emulator. So what gives emulators the advantage here?
The trick here is the routing structures that emulators employ. While the major emulation vendors use very different mechanism to do this, they are all designed to make compilation faster. In one vendor's solution, they bring about a certain level of independence in placement, and make timing more predictable. In other words they use hardware to make the software process of compilation easier and faster.
Now, the utilization of this type of technology is not in the best interests for the FPGA vendors in general, because these modified routing structures are larger than the equivalent routing resources found within an FPGA and thus would not be as good for implementing an actual design. If the adoption of prototyping grows, however, then there may very well be a market for some custom prototyping chips that offer better turn-around times compared to an FPGA but not at the same cost as those designed specifically for an emulator.
This may be a bit of a "Catch 22" situation where a prototyping company will have to take on the risk of designing a new special-purpose chip to solve the turn-around time problem before the market has grown enough to be able to justify its development. I wonder if any of them has the nerve to try?
Brian Bailey – keeping you covered
|
|
|
|
|
Navigate to related information
Max the Magnificent
2/22/2011 6:51 PM EST
Hi Brian -- this is an interesting idea -- I wonder what the folks at Altera and Xilinx have to say about it...
Sign in to Reply
KarlS
2/23/2011 3:35 PM EST
Parsing the HDL and using embedded memory blocks for control logic and registers to execute the HDL is probably possible using today's FPGA's. It sounds a bit outlandish, but since the memories can cycle in less than half the cycle of a typical FPGA, then one memory can decode the controls to get addresses for 2 operands and have them ready to be used at the end of the main clock cycle just as if they were in discrete registers and gated thru the usual data path. I would need to know more about the need for cycle accuracy requirements to really be sure. A crisper definition of what really constitutes the "System" in ESL would help. i.e. Is there a cpu with an operating system so the communication is via MMIO/Interrupts between the software and hardware, or is there direct connection that must happen on a cycle by cycle basis? (In other words, is the cpu on chip with direct connections?)
Sign in to Reply