feature article
Subscribe Now

Connecting the Camps

Mathworks Bridges System and Hardware Design

The MathWorks is bucking that trend, however, because they’ve approached the problem from a different direction. First, they won the hearts and minds of the electronic design community with their general purpose (non-EDA-specific) tools like MATLAB and Simulink. Then, when they apparently noticed that they had thousands of seats of software in places where only EDA companies typically played, they set about developing domain-specific technology to try and capitalize on that market presence.

This week, The MathWorks made another bold step across that line from supplier of general-purpose software tools to head-on competitor for some of EDA’s most prized software seats – those in the emerging electronic system-level design (ESL) space. For years, MATLAB has been the analysis and experimentation tool of choice for high-level system designers (you know the ones – they’re sitting down the hall from you right now wearing long flowing robes and staring knowingly at strange differential equations scrawled on their ivory whiteboards). These folks would enter their algorithms into MATLAB, twiddle a few coefficients and exponents, and officially pronounce the signal-to-noise problem solved. Actual hardware implementation was left as an exercise for the student (…or to the rest of us engineers that have to occasionally actually build stuff).

The path from all those MATLAB-proven algorithms to working hardware is the stuff careers are made of, requiring savvy hardware engineers to decode the system designers’ intent and then create complex micro-architectures hand-coded in VHDL or Verilog to implement the system guru’s vision. That gap, between the top-level theoretical system design and the implementation-level hardware and software, is the primary playground for EDA’s hottest new segment, ESL (Electronic System Level design).

Until now, The MathWorks has played a completely complementary role to EDA – filling in gaps and providing interfaces like their ModelSim verification interface that made life easier for people using EDA tools and MathWorks tools together. Now, however, The MathWorks has announced a new tool that almost certainly signals a deeper foray into EDA’s protected turf.

With this week’s introduction of their new “Simulink HDL Coder,” the company has launched directly into the implementation path for high-level system designs making their way into hardware from MATLAB and Simulink. Basically, given a design created in Simulink with The MathWorks’ model-based design approach, You can use HDL Coder to generate simulatable, synthesizable HDL code that can take you right along to your implementation flow for hardware. Sounds great, right? We just took that hardware engineer right out of the loop.

OK, it’s not quite that simple.

Like any high-level design methodology, you have to know the downstream tools and technologies and create your high-level design with some provisions for your chosen tool path. Perhaps the best way to explain the system is to begin with a discussion of what it is not – HDL Coder is not high-level or behavioral synthesis. It does not attempt to take a generic, untimed algorithm and create a micro-architecture that will implement that algorithm in hardware. Therefore, you will not see this tool competing directly with solutions like Mentor Graphics’ Catapult, Celoxica’s DK Design Suite, Forte’s Cynthesizer, etc. In creating your design for HDL Coder, you explicitly craft a data path and control logic in Simulink and its companion “Stateflow” tool. Unlike many of the existing Simulink-based design flows, however, HDL Coder does not require you to use a specialized library. This means that your source design is still generic in terms of implementation technology and could even be used to generate software implementations for something like a DSP processor.

Because The MathWorks is already in the analysis and verification business to some degree, the new tool has an already well-established verification flow – something that’s difficult to achieve with a typical “methodology shift” tool. Also, the new tool capitalizes on the fact that the entry mechanism – via Simulink and MATLAB — is already the dominant methodology for many types of high-level system design. If The MathWorks wanted to flex their substantial muscles and throw a wave of competitive fear into the EDA industry, this seems the perfect way to do it.

Of course, HDL Coder is designed to play nicely with the EDA tool chains already in place. By generating HDL, it lets you roll right into your existing synthesis, simulation, and verification tools on the back end. It also is compatible with your legacy HDL IP – an important consideration because almost every design today has a large legacy of pre-existing hardware behind it. Designing with a blank sheet is almost never an option in the real world. You can black-box import your legacy IP blocks and use them in your simulation, analysis and implementation process. HDL coder allows you some flexibility in your implementation with serial versus parallel implementations and some retiming options. It also provides automatic generation of HDL test benches for downstream simulation and verification.

The aspect of HDL Coder that will likely be the hardest to push into some teams is the subtle repartitioning of responsibility and the resulting requirement for slightly different skill sets in the engineering team. Traditionally, system designers have worked at a very abstract level with little consideration of details like the micro-architectural details of datapaths. Those details were the purview of hardware engineers with their knowledge of timing constraints, resource sharing, pipelining, and multiplexing. With the HDL Coder design methodology, some of the responsibility for the design of a successful microarchitecture comes back to the system designer. For many design teams, that expertise sharing has already begun, and the shift will be a non-issue. For some, however, such a shift of design responsibility could pose a significant challenge.

The benefits should be worth it, however. Bridging the gap between the abstract system-level design world of MATLAB and Simulink and the architecture and technology-specific world of HDL-based hardware design is a major step in the evolution of the system design process. Clearly The MathWorks’s work is not done here. One can extrapolate a large and challenging list of future capabilities that could bolster this product offering. One thing is clear, though. Notice has been served. The ESL space is up for grabs, and it won’t be just the traditional EDA companies fighting for a piece of it.

Leave a Reply

Connecting the Camps

MathWorks Bridges System and Hardware Design

It happens from time to time. Some well-meaning high-tech company notices that they’ve got some pretty cool design tool technology and says to themselves, “Hey, we’ve got some cool design tool technology. Let’s jump into the EDA market!” These are fateful thoughts, however – best pushed aside. In practical terms, they are akin to “Hey, I’ve got myself a pretty cool racing bike – I think I’ll compete in the Tour de France!” Sometimes, though, a company that, perhaps, developed some nice tools for their own internal use, feels just too tempted and takes that ill-advised plunge. The results are typically disastrous. These adventurers usually soon discover that creating tool technology is the easy part. Getting electronic designers to adopt and depend on your software, regardless of how novel and necessary it may seem, is a much more daunting challenge.

The MathWorks is bucking that trend, however, because they’ve approached the problem from a different direction. First, they won the hearts and minds of the electronic design community with their general purpose (non-EDA-specific) tools like MATLAB and Simulink. Then, when they apparently noticed that they had thousands of seats of software in places where only EDA companies typically played, they set about developing domain-specific technology to try and capitalize on that market presence.

This week, The MathWorks made another bold step across that line from supplier of general-purpose software tools to head-on competitor for some of EDA’s most prized software seats – those in the emerging electronic system-level design (ESL) space. For years, MATLAB has been the analysis and experimentation tool of choice for high-level system designers (you know the ones – they’re sitting down the hall from you right now wearing long flowing robes and staring knowingly at strange differential equations scrawled on their ivory whiteboards). These folks would enter their algorithms into MATLAB, twiddle a few coefficients and exponents, and officially pronounce the signal-to-noise problem solved. Actual hardware implementation was left as an exercise for the student (…or to the rest of us engineers that have to occasionally actually build stuff).

The path from all those MATLAB-proven algorithms to working hardware is the stuff careers are made of, requiring savvy hardware engineers to decode the system designers’ intent and then create complex micro-architectures hand-coded in VHDL or Verilog to implement the system guru’s vision. That gap, between the top-level theoretical system design and the implementation-level hardware and software, is the primary playground for EDA’s hottest new segment, ESL (Electronic System Level design).

Until now, The MathWorks has played a completely complementary role to EDA – filling in gaps and providing interfaces like their ModelSim verification interface that made life easier for people using EDA tools and MathWorks tools together. Now, however, The MathWorks has announced a new tool that almost certainly signals a deeper foray into EDA’s protected turf.

With this week’s introduction of their new “Simulink HDL Coder,” the company has launched directly into the implementation path for high-level system designs making their way into hardware from MATLAB and Simulink. Basically, given a design created in Simulink with The MathWorks’ model-based design approach, You can use HDL Coder to generate simulatable, synthesizable HDL code that can take you right along to your implementation flow for hardware. Sounds great, right? We just took that hardware engineer right out of the loop.

OK, it’s not quite that simple.

Like any high-level design methodology, you have to know the downstream tools and technologies and create your high-level design with some provisions for your chosen tool path. Perhaps the best way to explain the system is to begin with a discussion of what it is not – HDL Coder is not high-level or behavioral synthesis. It does not attempt to take a generic, untimed algorithm and create a micro-architecture that will implement that algorithm in hardware. Therefore, you will not see this tool competing directly with solutions like Mentor Graphics’ Catapult, Celoxica’s DK Design Suite, Forte’s Cynthesizer, etc. In creating your design for HDL Coder, you explicitly craft a data path and control logic in Simulink and its companion “Stateflow” tool. Unlike many of the existing Simulink-based design flows, however, HDL Coder does not require you to use a specialized library. This means that your source design is still generic in terms of implementation technology and could even be used to generate software implementations for something like a DSP processor.

Because The MathWorks is already in the analysis and verification business to some degree, the new tool has an already well-established verification flow – something that’s difficult to achieve with a typical “methodology shift” tool. Also, the new tool capitalizes on the fact that the entry mechanism – via Simulink and MATLAB — is already the dominant methodology for many types of high-level system design. If The MathWorks wanted to flex their substantial muscles and throw a wave of competitive fear into the EDA industry, this seems the perfect way to do it.

Of course, HDL Coder is designed to play nicely with the EDA tool chains already in place. By generating HDL, it lets you roll right into your existing synthesis, simulation, and verification tools on the back end. It also is compatible with your legacy HDL IP – an important consideration because almost every design today has a large legacy of pre-existing hardware behind it. Designing with a blank sheet is almost never an option in the real world. You can black-box import your legacy IP blocks and use them in your simulation, analysis and implementation process. HDL coder allows you some flexibility in your implementation with serial versus parallel implementations and some retiming options. It also provides automatic generation of HDL test benches for downstream simulation and verification.

The aspect of HDL Coder that will likely be the hardest to push into some teams is the subtle repartitioning of responsibility and the resulting requirement for slightly different skill sets in the engineering team. Traditionally, system designers have worked at a very abstract level with little consideration of details like the micro-architectural details of datapaths. Those details were the purview of hardware engineers with their knowledge of timing constraints, resource sharing, pipelining, and multiplexing. With the HDL Coder design methodology, some of the responsibility for the design of a successful microarchitecture comes back to the system designer. For many design teams, that expertise sharing has already begun, and the shift will be a non-issue. For some, however, such a shift of design responsibility could pose a significant challenge.

The benefits should be worth it, however. Bridging the gap between the abstract system-level design world of MATLAB and Simulink and the architecture and technology-specific world of HDL-based hardware design is a major step in the evolution of the system design process. Clearly The MathWorks’s work is not done here. One can extrapolate a large and challenging list of future capabilities that could bolster this product offering. One thing is clear, though. Notice has been served. The ESL space is up for grabs, and it won’t be just the traditional EDA companies fighting for a piece of it.

Leave a Reply

featured blogs
Dec 14, 2018
Yesterday I wrote a sort of overview of the Cadence Automotive Summit that took place in November, in the post Automotive Summit: The Road to an Autonomous Future . Today, the focus in on a key part... [[ Click on the title to access the full blog on the Cadence Community si...
Dec 13, 2018
In November, we continued our mobile updates to the website, released a couple of new content experiences, and made placing sample requests even easier. Read more below on these and the rest of the major updates to Samtec.com for November 2018. Continued Improvements to our M...
Dec 10, 2018
With Apple'€™s '€œWearable'€ category of sales setting a new record this September with growth over 50%, and FitBit seeing growth in both trackers......
Nov 14, 2018
  People of a certain age, who mindfully lived through the early microcomputer revolution during the first half of the 1970s, know about Bill Godbout. He was that guy who sent out crudely photocopied parts catalogs for all kinds of electronic components, sold from a Quon...