Six months ago I wrote a blog post that considered the question, Is System-Level Design Creating a New Class of Engineer? Since then an ongoing discussion in the LinkedIn electronic system level (ESL) design group has added some new perspectives not considered in my original blog post.
To quickly recap, the original post cited two sources. One was a DesignCon panel discussion on the "designer of the future," in which panelists talked about the inevitable move to electronic system level (ESL) methodologies and the need for engineers with new skills. A second was a free Industry Note published by analyst Gary Smith, who observed that large companies are "putting a team of ESL designers as close to the system architect as possible, even physically close. Their job is to do the modeling of the proposed system and extensive what-if analysis to come up with the optimal design." These are not conventional "hardware" or "software" developers, he said -- what they're doing is modeling.
So does ESL require a new class of engineer? Here are some of the opinions voiced in LinkedIn.
Yes and Then Some
One comment affirmed that ESL methodologies will indeed create a new class of engineer, "someone who understands algorithms, software and hardware." But beyond that it requires a new culture and a design organization that can adapt to the new methodology.
Another comment predicted a convergence in hardware design and software engineering for extremely parallel systems, because such engineering "requires a software engineer who understands fine-grain parallelism in a manner similar to hardware designers." Yet another comment simply said that non-ESL engineers "cannot do much" with today's complex embedded systems.
Maybe...or Maybe Not
The challenge, one comment said, is that very few engineers have strong expertise in both hardware and software. So, will the new "ESL engineers" hand-craft system level models, or will EDA companies provide some automation to help these engineers out? There's a fair question here: "Is EDA rising up to the challenge of creating good system-level models?"
One comment noted that ESL is an evolution, just like to move from schematics to HDLs, and suggested that "not every methodology needs a new generation of engineers." What it does require is "a new approach of thinking and planning for projects." ESL may provide some surprises but "not for engineers who are embracing the new methodology."
Another comment said hardware engineers can understand and work with some ESL tools if they are similar to Verilog, or output Verilog.
How Far Does ESL Go?
One comment suggested that ESL is essentially transaction-level modeling. Another called this view limiting, saying that some ESL technologies have grown past "transactional" to a truly architectural level. This commentator said that "ESL is a stepping stone to system level design, where the physical product, its look and feel, its human interface, the electronic hardware, and the software are all designed together as an efficient and effective flow from an architectural model to the final system." The result: smaller and better organized teams that can "outsmart" much larger organizations.
Here are some of my takeaways from this ongoing discussion:
- ESL will demand engineers who have some understanding of both hardware and software, but perhaps more significantly it will require a new company organization and a new corporate culture. It's not just a question of individual skill sets or roles.
- ESL methodologies must be backed by automation, and EDA vendors must step up to the plate. (Note: After this discussion started, Cadence announced the System Development Suite, a suite of integrated hardware/software development platforms.)
- The boundary between "hardware" and "software" development will fade for some kinds of systems, including those that have a lot of parallelism. And parallelism will be required for multi-core and many-core SoCs, fueling the need to step upwards in both methodology and training.
- We need to define our terms when talking about "ESL." Some might see it as transaction-level modeling; others might take it further to early architectural development. As one of the above comments suggested, it's not yet full system-level design.
This entire discussion is very relevant to the EDA360 vision, which recognizes software applications as the key differentiator in most electronic products today. This vision calls for engineers who can create integrated hardware/software systems ready for applications deployment, and do it quickly and cheaply.
Next question: how do we train or retrain such engineers, both at the university level and inside semiconductor and systems companies? There's more to be said in this ongoing discussion about a "new class" of engineer.