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
Oct 19, 2020
Sometimes, you attend an event and it feels like you are present at the start of a new era that will change some aspect of the technology industry. Of course, things don't change overnight. One... [[ Click on the title to access the full blog on the Cadence Community si...
Oct 16, 2020
Another event popular in the tech event circuit is PCI-SIG® DevCon. While DevCon events are usually in-person around the globe, this year, like so many others events, PCI-SIG DevCon is going virtual. PCI-SIG DevCons are members-driven events that provide an opportunity to le...
Oct 16, 2020
If you said '€œYes'€ to two of the items in the title of this blog -- specifically the last two -- then read on......
Oct 16, 2020
[From the last episode: We put together many of the ideas we'€™ve been describing to show the basics of how in-memory compute works.] I'€™m going to take a sec for some commentary before we continue with the last few steps of in-memory compute. The whole point of this web...

Featured Video

Four Ways to Improve Verification Performance and Throughput

Sponsored by Cadence Design Systems

Learn how to address your growing verification needs. Hear how Cadence Xcelium™ Logic Simulation improves your design’s performance and throughput: improving single-core engine performance, leveraging multi-core simulation, new features, and machine learning-optimized regression technology for up to 5X faster regressions.

Click here for more information about Xcelium Logic Simulation

featured Paper

New package technology improves EMI and thermal performance with smaller solution size

Sponsored by Texas Instruments

Power supply designers have a new tool in their effort to achieve balance between efficiency, size, and thermal performance with DC/DC power modules. The Enhanced HotRod™ QFN package technology from Texas Instruments enables engineers to address design challenges with an easy-to-use footprint that resembles a standard QFN. This new package type combines the advantages of flip-chip-on-lead with the improved thermal performance presented by a large thermal die attach pad (DAP).

Click here to download the whitepaper

Featured Chalk Talk

Selecting the Right MOSFET: BLDC Motor Control in Battery Applications

Sponsored by Mouser Electronics and Nexperia

An increasing number of applications today rely on brushless motors, and that means we need smooth, efficient motor control. Choosing the right MOSFET can have a significant impact on the performance of your design. In this episode of Chalk Talk, Amelia Dalton chats with Tom Wolf of Nexperia about MOSFET requirements for brushless motor control, and how to chooser the right MOSFET for your design.

More information about Nexperia PSMN N-Channel MOSFETs