ESL tools have for a long time had a bad reputation as promising the moon and delivering next to nothing. While there are still tools out there which don’t deliver value to the designer, I’m happy to say ESL tools have evolved and this segment of the EDA space is maturing. Tools like our own PICO Extreme development environment are being used in both the ASIC and FPGA domains to create real designs going into products shipping today.
The companies widely deploying this type of design methodology have made the mental leap to move to a design abstraction higher than RTL for better productivity and faster design turn around time. Others are being pushed by increasing design complexity, need for cost reductions, and design cycle cuts to find a better way to create their IP. Seeing that the shift from RTL to a higher level of abstraction is gaining in momentum, I got to thinking how does a designer considering an ESL solution separate the wheat from the chaff and select the best ESL solution?
One obvious criteria is cost, but more importantly is what does the solution deliver. What is the design entry language? How is quality of results (QoR) achieved? How is performance met? Can the target performance be met? How is the design verified? An FPGA designer might also ask…..My design is on a expensive large prototyping part…..how do I migrate to a low cost mass volume FPGA? An ASIC designer might also ask……What about an ECO?
Before diving into the detailed answer for each of these questions, one question seems to be the first one that must be answered
How to select and deploy an ESL tool successfully both for an initial project and across the entire design team?
The exact answer depends on the type of designs created and the dynamics of the team. Having said that, here are some guidelines of things to keep in mind when selecting an ESL solution:
1. Use the highest level of abstraction possible
RTL coding is tedious, time consuming, but familiar. Many tools out there offer control and coding that is very similar to RTL. The user is giving complete freedom to specify everything happening on a clock cycle, parallelism, microarchitecture, etc. The only advantage is you don’t have to know VHDL/Verilog to generate RTL, but you are still creating RTL by hand. One thing to think about, if writing RTL is not keeping up with your needs…..why would writing RTL in another language be any different? The designer should strive to use a methodology that keeps the design code as close to the algorithm description as possible. The less changes you have to make from algorithmic code to the hardware implementation the easier it is to share and reuse IP.
2. Focus on QoR equal to hand design
Area in an ASIC is expensive. Changing from one FPGA into a larger one can also turn out to be very costly. No matter how good the tool looks or how easy it is to use, if the quality of results is not on par with hand written RTL, your management will not allow you to use the tool on a production quality design.
3. Don’t debug in the RTL
Raising the level of design abstraction needs to also cover verification and not just design entry. Verification tends to always dominate the design cycle. Debugging at the RTL level is slow, error prone, tedious, and difficult. If the ESL solution you are considering doesn’t raise verification out of the RTL level, any productivity gain in design entry is meaningless. Look for a tool that allows you to debug at the same level as your design entry. For example, a C based tool should allow you to to all debugging at the C level. The RTL simulation should be a final validation that everything is fine with the design. It should not be the place where all issues in the design are discovered.
4. Don’t benchmark or make flow decisions on a small block
Testing an ESL tool on something simple such as an FIR filter is fine for getting an initial feel for the software. Making a decision on a tool choice or flow changes requires a realistic example. Be prepared to invest the time in testing the tool with a design representative of what you are building. Testing the approach with a realistic test case will save headaches later. Last thing you want to do is propose your company acquires a tool, which does not solve any of your problems.
5. Take advantage of high level abstraction for optimization
One of the big advantages of ESL tools is the quick turn around from algorithm change to new hardware implementation. Take advantage of this speed to explore new architectures, explore power reduction at the algorithm level, explore different algorithms to solve the same problem. Look for built-in analysis utilities which give you complete information about every aspect of your design. What’s the dataflow, where is the performance bottleneck coming from, where is the area going….are all basic questions your ESL tool should quickly answer.
6. Build a hierarchical methodology that promotes IP sharing and reuse
Think about how you want to reuse your algorithmic IP. From an algorithm point, the same codec can go in a set top box or in a cell phone……the hardware and performance requirement for each case is completely different. Look for solutions which allow you to freely use your algorithms across different projects with little or no modification. Changes in terms of clock frequency and throughput should be an input to the tool and separate from the algorithm code. Look for the capability of pulling in as much of the design as possible into the ESL solution. Chopping up an algorithm into small blocks, building them in a tool and manually stiching them together doesn’t work. Also, think about the capacity constraints of a tool and the size of designs you are building. How large of a design can you build with a tool and how large a design do you need to build? Are you looking at a few thousand gates, a few hundred thousand gates or beyond a million gates?
7. Assume architectural awareness in the code, but don’t code in details
Expecting any tool to create optimized hardware from random code is unrealistic. You should expect to embed architectural awareness into your code. By architectural awareness, it means that the code should have a notion of how the memory is organized, how inter-block communication is happening. Communication between blocks in terms of streams vs shared memories vs scalars are natural architectural decisions which should only be made by a designer.
Things like explicitly stating parallelism and having to control the level of pipelining should not be required of the user. Forcing the user to deal with these things lowers the level of abstraction and productivity. If the tool you are considering requires you to state parallelism, pipelining and other fine level of details, it is not the right tool to solve your RTL design issues.
8. Build and end-to-end flow: algorithm -> physical implementation
Getting an algorithm from C to RTL is not enough. You need to pass verification, synthesize and close timing on the ASIC library or FPGA part with a netlist that is area optimized. Look for elevating the verification of the IP up to the level of design entry. If you are designing in C, it only makes sense to verify and debug in C and not have to wait until RTL. Tools which only allow you to debug/verify at the RTL level shouldn’t even be considered. Also, look for integration into industry standard back-end flows for place and route. Consider vendors who can help you create and end-to-end solution, leaving you to figure out everything on your own just doesn’t work.
9. Develop internal expertise
Moving design abstraction from RTL to something like C is a major methodology change for any design team. Be prepared in developing the time in developing in-house expertise on the new methodology. A phased approach, which leverages local experts, is the safest bet for a successful deployment. Trying to move all designers at once will just create tension, discontent and sets up your ESL adoption for failure.
10. Plan for what you will need 2 to 5 years down the line
Look at your product roadmap, what kind of designs are you expecting in terms of complexity and size? Look at the roadmap of your ESL vendor, does their plan track with what you expect to need? Keep in mind that once you switch from hand written RTL to a higher level of abstraction, the methodology change is here to stay. You won’t be trying ESL and then retooling to go back to hand written RTL. You will need to make sure that your preferred ESL vendor not only helps in your immediate problems, but that they also have a plan for supporting your needs in the future. Changing vendors is much easier than changing design methodology……..but if by doing a little bit of research you can find the perfect fit the first time around, why wouldn’t you?
Thanks for the info. Some questions:
Q1
“On bullet #4. Don’t benchmark or make flow decisions on a small block”
[krishna] What do you recommend as a reasonably sized complexity for doing the evaluation. Maybe 802.11a OFDM transmitter?
Q2
I think there are two evolution paths for the current hand coded RTL for wirless basebands – a) Using DSP processors capable of vector processing and b) using algorithmic synthesis tools.
From your experience, can you share some cost/benefit analysis of a) vs b).
Thanks,
Krishna
Ps.
Can we have an option to send me an email whenever you have replied to this comment.
Hi Krishna,
Very good questions. Here is my reply to both of them.
Q1. The size of the evaluation design has to be representative of what you will try to build as a product using an ESL tool. It is very easy to get impressed by a canned example of an FFT, a filter or some other prebuilt component in the ESL tool library. The real question is, once you try to build something in the order of digital receiver in a 802.11n to ship in your next product, will the tool be able to handle it or leave you without a solution. The digital portion of 802.11a can be a good evaluation candidate, but it is probably going to be mostly throw away work after the evaluation is done. When selecting an evaluation application, you should keep in mind the following. If the evaluation goes well, is this design something that can be used as either a stepping stone or part of a production project.
Q2. For wireless baseband the cost/benefit equation depends on if you are comparing the cost/benefit of taking RTL to a custom ASIC vs a DSP or an FPGA implementation vs a DSP. I will assume you mean FPGA vs DSP as both are readily available off-the-shelf components. I think in this case, algorithmic synthesis tools bridge the usability gap in terms of getting a working design between FPGA and DSP. For cost/benefit, algorithmic synthesis tools allow you to develop your algorithm in a high-level language such as C, which is familiar to DSP designers. Then the tool takes care of the proper RTL generation to get the design working at speed on the FPGA. I think you will see more designs in wireless baseband transition to an FPGA because of the cost/performance point of the part when compared to a DSP, and because of the usability gained by using algorithmic synthesis tools in the design capture phase.
Thanks.
You are really right in saying that only if outcome of the evaluations gets used into some production designs, and it works well, the management will consider a new design flow
.
I accept your perspective on DSP implementation vs ESL to FPGA way, though a part of me tells me that ‘DSP is bit more flexible’. Anyhow, the DSP story is not relevant to this thread.
Two more questions:
Q3: What is your take on pros of Synfora viz a viz your competition (like Catapult, AccelChip to name a few…).
Q4: Prior to acquisition by Xilinx, Accelchip was the only company offering a Matlab-to-RTL solution. Rest of the competition was offering C-to-RTL solution. Do you have a take on which one is a better way.
Ps. I used to think Matlab-to-RTL might be preferable, but now am tending towards C-to-RTL.
Hi Krishna,
This is not the correct forum to discuss the pros and cons of Synfora tool chain vs our competitors. This is a technology forum and not a Synfora specific forum. If you’d like to know more about how we differ from the competition and where we are better, you can visit our website at http://www.synfora.com or contact me directly.
As for Matlab-RTL or C-RTL, I believe the better route is C-RTL, because it does not tie you in to a specific tool vendor. You are free to choose what design flow works best for you. Also, a vast majority of reference models people use to start their designs are in C and not in a proprietary language like the Matlab M-code.
Hi Fernando,
Thanks, I understand. I will checkout synfora.com and may revert back for additional clarifications.
Regards,
Fernando,
Good points on selecting an ESL solution. Thanks for sharing them.
Some questions on the following point though.
Don’t debug in the RTL:
1) As we know, an ESL model’s ‘high level abstraction event’ will expand into multiple clocks at RTL level after HLS. How would you guarantee a working RTL for highly-clock sensitive blocks such as a write-back Cache Controller where every decision has to be made at clock level on multiple read/write coherent/non-coherent/snoop requests pending from multiple masters.
In other words, if an ESL model is functionally accurate, there is a good chance that the clock accurate RTL will have bugs for multi-master coherent transactions that collide at clock level.
Any solution on such logic from the ESL world?
2) Some have suggested that there are formal tools out there that guarantee equivalence beteween an ESL model and it’s RTL counterpart. Even if such equivalence is established, wouldn’t there be (back to clocks!) concurrency bugs at clock level between blocks that cannot be verified at ESL level (for example a priority encoded arbiter that makes decisions at clock level on who to give grant to).
I note that you do point out that RTL verification is necessary but should not be the starting point. Agreed. But I think that even if ESL models have been thoroughly verified, the RTL based SoC will still need good dose of verification.
Thanks for any input you can share.
Regards.