Frank Schirrmeister is the director of product management at Synopsys Inc. He is responsible for the System-Level Solutions products Innovator, DesignWare System-Level Library and System Studio with a focus on virtual platforms for early software development. Prior to joining Synopsys, he held senior management positions at Imperas, ChipVision, Cadence, AXYS Design Automation, and SICAN Microelectronics. He also writes about system-level issues in his blog,
"A View From the Top." Email address: fschirr@synopsys.com Web site: http://www.synopsys.com
8 results found for Frank Schirrmeister , displaying items 1 - 8
July 29, 2009
[From Systems to Silicon] Embedded Hardware And Software—Like Two Camps With A River Full Of Sharks In Between
At least for the last decade, we have been hearing about the worlds of embedded software and hardware growing closer, but there has been very little measurable evidence to back up those claims. Still, I’m cautiously optimistic that we are starting to see a shift toward true co-development of hardware and software, or at least its co-debug. My optimism is driven by the results of a couple of user surveys Synopsys conducted last year.
May 28, 2009
[From Systems to Silicon] Virtualization Innovations Drive Cost Optimization
The 2007 edition of the International Technology Roadmap for Semiconductors (ITRS) states that “design cost is the greatest threat to the continuation of the semiconductor roadmap.” While this claim has been made even long before then, in light of the current economic situation, its meaning could not be more relevant. Given that the semiconductor industry has been through economic cycles before, however, the ITRS is also able to suggest a remedy. It’s called innovation!
May 15, 2009
[From Systems to Silicon] When One Plus One Has To Be Less Than One
A customer recently suggested he could only add new steps to his process if the sum of the current workload and the additional workload to add the steps would result in less work overall. It took a little while for me to let that math settle in, but in retrospect this comment precisely explains one of the key issues preventing mainstream adoption of system-level design. ROI for system-level design is not quantifiable “enough,” which often deters metric-driven verification teams.
April 28, 2009
[Design View / Design Solution] TLM-2.0 APIs Open SystemC To Mainstream Virtual Platform Adoption
At the 45th Design Automation Conference in June 2008, the Open SystemC Initiative (OSCI) announced the ratification of the TLM-2.0 standard, enabling interoperability for transaction-level models (TLMs). The next steps after ratification were to formalize a TLM-2.0 language reference manual (LRM) and eventually contribute the LRM to IEEE for further standardization once complete.
March 11, 2009
[From Systems to Silicon] Is System-Level Design About Discipline?
We’ve all heard it, and it’s said in many ways. Preparation is everything! System-level design is all about thinking early and implementing later. So why not apply what we already know? We even have statistics. Everybody seems to know and agree that it becomes more difficult to find and fix defects the further a project has progressed.
February 12, 2009[From Systems to Silicon] Is ESL Adoption Really All That Difficult?
The debate about design at the electronic system level (ESL) seems to be in full swing again. Some claim there is too much “stuff” in ESL and basically suggest incremental approaches. Others say that today’s approaches aren’t visionary enough and are calling for the “real ESL to please stand up.” I was just handed video footage of some ESL tools that were presented at the 2001 Design Automation Conference (DAC), now almost eight years ago. At that...
January 21, 2009
[From Systems to Silicon] What’s In A System?
There's a buzz about system-level design, specifically around ESL, centering around which technologies should be considered part of ESL. Some system-level advocates suggest limiting ESL to the next step above hardware. Others say it encompasses many techniques, which only have in common the fact that they are applied prior to RTL. Instead, I will focus on what matters to developers, who don’t care about the names given to technologies they are using.
