Zibb

Ron WilsonEDN Executive Editor Ron Wilson explores how IC design teams really work: the struggle for power efficiency and performance, wrestling with semiconductor processes and design methodologies, the challenges of global design teams. How do we somehow herd architecture, IP, design and verification into a successful tape-out?



   Advertisement

Profile

RSS Feed

  • Add this blog to your RSS newsreader!

Recent Posts

Recent Comments

Most Commented On

Archives

By Category

Blog

Tuesday, October 13, 2009

Synopsys introduces Matlab-to-RTL synthesis path for datapaths

Oct 13 2009 10:16PM | Permalink |Comments (8) |


Leveraging high-level synthesis technology developed at Synplicity, Synopsys this week introduced a unique approach for generating synthesizable datapath RTL from algorithm descriptions in the Matlab environment. Unlike other high-level synthesis tools, which start with a system description in SystemC or another C dialect, Synopsys's Synphony tool starts with the native scripting language of Mathworks Matlab, M-files. Synopsys refers to this mathematics-like scripting as the M Language, which is not to be confused with the M (or MUMPS) language used to develop database applications.

Synphony offers a two-step conversion process. After algorithm designers have explored and verified their algorithm in Matlab's implicitly real-number space, Synphony converts the model to fixed-point using a tool called M-Compiler. This automatic conversion step bypasses what would ordinarily be months of manual recoding from M-files into a model with fixed-width datapaths. At this point users may reverify the model in the Mathworks Simulink environment. In the second conversion step, Synphony then converts this fixed-point model into synthesizable RTL, in the process generating other useful files.

More specifically, in the first stage Synphony uses a Synopsys-provided IP library of fixed-point functions to generate a fixed-point model from the M-files, subject to constraints provided by the user. In this step the tool can either generate datapaths and propagate the path widths based on the requirements of the algorithm, or the user can explicitly intervene with the constraint file and set path widths directly. The tool reports encounters with the constraints, insertion of quantizers, and other important events. The model executes in the Simulink fixed-point management environment, allowing the user to relatively quickly verify operation, and to run the model against the original Matlab testbench to examine the effects of quantization.

Once the user is satisfied with the model, on to step two. The user feeds the fixed-point model and further constraints into the Synthesis Engine. This tool offers a number of optimizations, including pipeline insertion, resource sharing, and loop unrolling. It can also infer some interface structures—for example, inserting a buffer to pack a serial operand stream into a matrix. The tool also introduces target-specific optimizations for either FPGA or ASIC target hardware. The constraints files direct the optimizer to meet timing while minimizing area.

Along the way, the Synthesis Engine provides early timing estimates using its own timing engine, and it can call Design Compiler to get more accurate estimates on specific paths. There is at present no provision for power estimation.

As outputs, the Synthesis Engine produces an RTL file for either the Synplify or DC synthesis tools, a synthesis constraints file, an RTL testbench, and an ANSI C file that is a cycle-accurate representation of the RTL. The tool also extracts memory instances for passing to third-party memory compilers. The C output is intended for system-level verification, but, curiously, it requires wrappers to bring the code into a standard SystemC/TLM verification environment.

On the whole, it appears that Synphony is not intended to be a direct competitor to the other high-level synthesis tools in the industry, such as those from Cadence, Forte, or Mentor. Rather, it is an IP-library-based tool for converting M-files into fixed-precision models for Simulink, coupled to a synthesis engine to convert these fixed-point models into RTL datapath designs for input into Synplify or Design Compiler. It is a rather specialized tool, but a sorely needed bridge between the worlds of Matlab algorithm exploration and RTL development.


Related entries in: DSP | EDA | 


Reader Comments



at 10/14/2009 2:14:44 PM, EDA Person said:
Isn't this exactly what AccelChip produced in 2002? If so, then "unique" surely isn't appropriate in the first line of this posting! Check out the "AccelDSP" tool on the Xilinx website.... Symphony is an exact clone!! I'm guessing Ken McElvain took a look at acquiring AccelChip and decided he could do it better and passed... 4 years later here's his clone.

AccelChip then sold their Matlab compiler to Xilinx who now very likely provides it for free (that's the typical expectation from EDA vendors -- the FPGA guys "give away" their tools). Word on the street is this tool from Synopsys is priced at $165K per year ... are FPGA designers (who are the main target of Synplicity) really willing to pay this much for a tool like this when all their other tools (VHDL Sim, Logic synth, etc) are practically free from the FPGA vendors? Most EDA analysts would argue that the Symphony price point is way too high no matter how sorely needed it is. 4 years later here comes the Synplicity clone and Xilinx has been handing out their exact same tool for free for 4 years!! Does any of this make sense?

ASIC designers appear to be very C/C++ centric ... MATLAB and the M language are mainly used by algorithm developers who want to verify their algorithms in hardware (FPGAs). Is this why Synopsys hasn't entered the high-level ASIC synthesis market ... that is, Synplicity has developed a M-Compiler for FPGA designers (though they claim it is for ASIC design too but ASIC designers don't write M code - it's all about C/C++ in ASICville) --- would it be too confusing if Synopsys also had a C/C++ compiler for ASIC designers?

Always appreciate your insight/perspective! This Synopsys announcement is confusing!!!



at 10/14/2009 2:25:14 PM, Gerald Smith said:
An interesting step forward. After many years of academic develop in Europe and America(Yay! Berkeley) the tools are hitting the mainstream.
The questions are: How good are they and what will they mean to design cycles and IC design group head count?



at 10/14/2009 11:19:00 PM, ron said:
EDA Person:
Great point. I missed the AccelDSP connection entirely!
Gerald:
Yes, that's the next question. When vendors who claim to be great at datapath synthesis buy companies to improve their datapath synthesis, the situation cries out for public benchmarks.
ron



at 10/15/2009 7:52:04 AM, Mark said:
Matlab-to-RTL high level synthesis for datapaths sounds pretty much like Altera's DSP Builder Advanced blockset too; so again perhaps not unique.



at 10/16/2009 1:53:15 AM, Chris Eddington said:
Ron,

I appreciate the opportunity to quickly clear up some questions that have arisen around Synopsys’ Synphony HLS. We recognize there are some similarities with the other products mentioned when it comes to supporting the Matlab language and generating RTL. However, Synphony goes well beyond these products. For example, Synphony HLS does a significant amount of architectural optimization in the synthesis process – we offer both language-based AND model-based design, both of which support multi-rate optimization. Also, instead of being vendor-dependent, Synphony HLS supports multiple FPGA families from all the most popular suppliers, including Xilinx, Altera, Actel, and Lattice. Finally, Synphony HLS can target ASIC devices as well as FPGAs.

These capabilities and more make Synphony HLS an important step forward in addressing persistent challenges in designing algorithmic-intensive applications such as wireless and wired communications, and multimedia.

Kind regards,
Chris Eddington
Director of Product Marketing
Synopsys, Inc.




at 10/16/2009 6:49:11 PM, AnEngineer said:
It is worth noting that Xilinx has declared the end-of-life on AccelDSP, the MATLAB to RTL compiler they bought with AccelChip, and they will not be supporting it going forward.

Mathworks itself offers a product that generates RTL from Simulink block diagrams. They have one Simulink block that takes a subset of MATLAB and can produce RTL, but it doesn't do resource sharing or loop unrolling and has a very limited capability to do pipeline insertion.

Altera DSPBuilder and Xilinx System Generator are block sets for the Simulink block diagram simulation world, not MATLAB code. They are interfaces to FPGA vendor IP through block diagrams.



at 11/9/2009 2:02:03 PM, dc207 said:
We are a users of Synplify DSP (now Synphony FPGA) for some time now. Our system-level algorithms are not C/C++ based, but Matlab/Simulink based instead. Like Chris Eddington is saying, don't compare the Synphony (Simulink) capabilities to either System Generator (Xilinx), DSP Builder (Altera) or HDL Coder (Mathworks), because I asure you that it will do architectural optimizations which the other (cheaper) tools are totally incapable of. As far as pricing goes, the Altera and Xilinx solutions are pratically for free but totally technology dependant, and the technology independant tools have higher price-tags but also on average higher quality of results at a given level of abstraction. It is my impression the "pricing/level of abstraction/quality of results" ratios are comparable between the Mathworks and Synopsys. HDL Coder will not be cheap as well (as is Synphony), and it delivers RTL which is both technology- as well as (logic) synthesis tool independant, probably resulting in non-optimal implementations, or sub-optimal implementations at a lower level of abstraction.... ;-)
At the moment, no HLS tool is as good as a "clever" designer (yet!), but more than a decade ago we had the same feelings about logic synthesis tools compared to manual gate-level design. Today, a logic synthesis tools is a commodity.



at 11/12/2009 2:49:44 PM, EDA Person said:
To "dc207":

Did you compare Symphony FPGA to AccelDSP (not System Generator)?

AccelDSP did a TON of optimization. True, it was Xilinx dependent after they bought AccelChip. But it's much more mature than Symphony and my insiders say it beats Symphony QoR handily.

Are you saying you're willing to pay $160K per year to use Symphony when AccelDSP was only $750 per year because of vendor independence?

Thanks for your feedback.

Post a comment



Display Name

Change Image
Before submitting this form, please type the characters displayed above.
Note the letters are NOT case sensitive.


ADVERTISEMENT

©1997-2009 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other Reed Business sites