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
Jun 22, 2018
A myriad of mechanical and electrical specifications must be considered when selecting the best connector system for your design. An incomplete, first-pass list of considerations include the type of termination, available footprint space, processing and operating temperature...
Jun 22, 2018
You can't finish the board before the schematic, but you want it done pretty much right away, before marketing changes their minds again!...
Jun 22, 2018
Last time I worked for Cadence in the early 2000s, Adriaan Ligtenberg ran methodology services and, in particular, something we called Virtual CAD. The idea of Virtual CAD was to allow companies to outsource their CAD group to Cadence. In effect, we would be the CAD group for...
Jun 7, 2018
If integrating an embedded FPGA (eFPGA) into your ASIC or SoC design strikes you as odd, it shouldn'€™t. ICs have been absorbing almost every component on a circuit board for decades, starting with transistors, resistors, and capacitors '€” then progressing to gates, ALUs...
May 24, 2018
Amazon has apparently had an Echo hiccup of the sort that would give customers bad dreams. It sent a random conversation to a random contact. A couple had installed numerous Alexa-enabled devices in the home. At some point, they had a conversation '€“ as couples are wont to...