BrianBailey

image
Consultant

Brian Bailey is an independent consultant working in the fields of Electronic System Level (ESL) methodologies and functional verification. Prior to this he was the chief technologist for verification at Mentor Graphics. He is the editor for the EETimes EDA Designline and a contributing editor to EDN. He has published seven books, given talks around the world, chairs international standards committees (is he crazy), and sits on the technical advisory board for several EDA companies. He graduated from Brunel University in England with a first class honours degree in electrical and electronic engineering (yes – he is another Brit, so of course he is crazy).

BrianBailey

's contributions
Articles
Comments
    • This free online class describes how factories are evolving with intelligent, connected embedded systems, and the technology that's making it possible.

    • All things IP and EDA are examined here by EDA Designline site editor, Brian Bailey.

    • Unfortunately most Analog components are highly specialized and just in the same way that we have problems with generalized abstractions for analog models, the same problems exist when trying to make them programmable, such as in an FPGA. There have been programmable op-amps, or other specific analog components, but just think about the general difficulty in taking analog components such as capacitors and resistors and routing them through a programmable fabric, when the interconnect has capacitance and resistance itself. So, unfortunately this is not possible today.

    • For many years, ESL has been just on the horizon, but never quite seemed to come into the light of day. Gary Smith faithfully draws the hockey stick curves for its growth and every year adjust the time scale to push it back a little more. So what is going on? Is ESL not a reality? The good news is that many of the issues that have held it back in the past are quickly being pushed aside and there are many companies out there now who are betting their future on it. Indeed there are some companies using it that don’t want you to know, because they see it as a competitive edge that they have over their rivals at the moment. So here is my top 5 reasons that have inhibited the growth in ESL in the past. Remember, that ESL is a huge field and parts of it are still very nascent, so this does not mean that everything ESL will eventually have to offer is here today. 1) Model compatibility - unlike at the RTL level, ESL models cannot just be plugged together. This is for many reasons, including lack of commonality in abstraction of the models, lack of interconnect standards and libraries etc. The OSCI TLM, while not perfect, has had a dramatic effect in this area already. Since the draft 2.0 was put out last year - almost every provider of virtual platforms has now standardized on this. Still a long way to go, but this problem is on the mend. 2) Languages and tools - While OSCI SystemC existed and was free, it did not have an environment around it that made it useable. For a while no EDA vendor was interested in making tools that supplemented a free simulator, but that is changing. We still do not have the same capabilities for a SystemC simulator as we do for Verilog, but some of them are now quite useable. Still a long way to go on this one. 3) Synthesis. High-level synthesis had some huge hurdles to overcome. The quality of results is the top issue on most peoples mind when they evaluate an HLS tool. But this on its own is not enough - they have to persuade people that it is worth the investment - and yes it is an investment. If you just take HLS and attempt to compare against RTL, the solutions will be similar. HLS may be a few persent bigger or smaller, faster or slower. The results are comparable. Productivity will be higher, but enough to make the switch. People, - companies have to make a methodology switch to using HLS for architectural exploration, which requires some different thinking. This is where the real benefits come from. Companies who have used these tools then often find a 30% are or timing improvement because they finish up with a better design. It is the automation that these tools provide that enable this level of exploration. 4) Verification methodologies. While these have improved significantly for RTL over the past few years, they are not properly in place for ESL. The methodologies need to be extended; even the languages have to be extended in some cases. Strategies for separation of concerns in verification have to be made and we have to find ways to convince people that they do not have to redo all verification at the RT level. We must find ways to avoid the replication of effort (be it human or computer) - something that has become woefully inefficient with the existing RTL methodologies based on constrained random generation techniques. 5) Problem complexity - this may sound like an odd one, but systems have just not been complex enough. Today we compartmentalize blocks in a system and keep them isolated as much as possible. This cuts down on the communications, which is often asynchronous in nature and makes system verification a nightmare. Think about our processor, DSP systems of today. The CPU sends a job to the DSP. It does it independently and only communicates back to the CPU when something is finished, or the CPU has to change the parameters that it is working with. All of this is changing and has to change for the next generation of systems. System complexity will skyrocket and I hope we have the tools in place to be able to solve it. So that’s my top 5 reasons that have inhibited ESL adoption. There are already companies out there who have made the switch and see the benefits even though all of the problems have not yet been solved. For some companies, it may still be too early. It really depends on how much they have to invest in the methodologies of the future. The ones investing today are seeing the returns. Edited by: Yo Yo on Sep 22, 2009 4:58 PM