October 13, 2003
SystemVerilog in the news (again)
Please note that contributed articles, blog entries, and comments posted on EDACafe.com are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Peggy Aycinena - Contributing Editor

by Peggy Aycinena - Contributing Editor
Posted anew every four weeks or so, the EDA WEEKLY delivers to its readers information concerning the latest happenings in the EDA industry, covering vendors, products, finances and new developments. Frequently, feature articles on selected public or private EDA companies are presented. Brought to you by EDACafe.com. If we miss a story or subject that you feel deserves to be included, or you just want to suggest a future topic, please contact us! Questions? Feedback? Click here. Thank you!

Comments from Synopsys

Meanwhile by way of a phone call later in the day, Farhad Hyatt, Vice President of Marketing for Verification Technology at Synopsys, answered some of the same questions that I had asked Dennis Brophy earlier:

“The SystemVerilog standard was ratified by Accellera in May. Our tools are just now becoming available [that support the language]. By establishing the SystemVerilog Catalyst Program we wanted to make sure that the other EDA tool vendors can provide the tools that will work with our tools in synthesis and verification. Obviously, there's a huge momentum behind the move to SystemVerilog. Close to 40 vendors have come out pledging support for the language. The fact that so many vendors are looking to support the standard is a testament to what's going on with their customers.”

“Our intent is to create interoperability with Synopsys tools. Synopsys has many open programs for interoperability - for instance the inSync program, which is designed to ensure interoperability between Synopsys tools and third-party tools. Our efforts with the Catalyst Program are absolutely not redundant with Accellera's efforts - this is a completely complementary effort to Accellera's efforts. Accellera's charter is to work towards evolving EDA standards. Synopsys' charter is to build tools that adhere to that standard. Ours is an open program. So when companies like Mentor Graphics and Cadence are ready to participate, we will be happy to talk with them as well.”

Comments from Cadence

Paul Estrada, Corporate Vice President of Strategy and Market Development at Cadence, was also willing to answer some questions by phone - particularly the 'Why now?' with regards to this week's SystemVerilog announcement from Cadence:

“We've had lots of conversation with customers over the last few months while this standards stuff has been going on, and we've been listening to them. There are some customers who think there should be one Verilog and there are some customers who don't. Some really like the idea, others don't. Some just don't care.”

“At Cadence, we believe that supporting SystemVerilog doesn't mean we're not supporting customers who don't like it or aren't interested. Right now, many hope that SystemVerilog will subsume the Verilog functionality, knowing that there are still many questions that need to be ironed out in that process. We've been pushing from the beginning to have Accellera work closely with the IEEE standards [committees], and although the timeframe is still somewhat open, [we're pleased to see that interaction happening]. [In part that is what has prompted our SystemVerilog announcement.]”

“Meanwhile, we see in the Synopsys [position] an [assumption that] the whole world will move to SystemVerilog. But here at Cadence we don't believe [that will happen]. There's a whole other world out there that's simply not interested. Currently, we have no immediate plans to join the Synopysy SystemVerilog Catalyst Program. In any case, they might have competitive issues even if we wanted to as they're providing interoperability through the program to their own tools.”

“But there still remains a whole world out there that doesn't use Verilog. They're using SystemC or other languages. SystemC is an extension of the C++ language and libraries. Many people who are doing system verification for design are using C-based languages and know nothing about Verilog or VHDL. They're working with big test structures and see their methods as a natural way to build a test environment.”

“Design is a complex world. Our long-term position is to support the standards - VHDL, Verilog, VHDL-AMS, Verilog-AMS, PSL, SystemC, and now SystemVerilog. Basically our position remains clear. There are a number of standards out there that the entire design community is interested in. We'll support all standards, including SystemVerilog, that are economically feasible. But we'll always continue to give people a choice depending on what their needs are.”

Comments from Tenison EDA

David Greaves is a Professor in the Computer Science Laboratory at Cambridge University in the U.K. He is a well-spoken academic, someone who chooses his words carefully. He's also the founder of several successful companies, including Virata (founded in 1993, a $500 million IPO in 2000) and Tenison EDA (founded in 2000). David spoke to me by phone from his office in William Gates Hall, home of the Computer Science Department at Cambridge. I asked him to address some of the same questions I had put to Accellera's Dennis Brophy, Synopsys' Farhad Hyatt, and Cadence's Paul Estrada. Here are David's comments, laced with commentary and a bit of historical perspective:

"Historically, Prolog has been the only widely known logic programming language, but we are seeking today to bring logic programming to system synthesis. I first heard of Verilog when I was at Silicon Graphics back in 1988. Silicon Graphics was among the earliest adopters of Verilog. I wrote a Verilog compiler for FPGA targets while the industry was still promoting gate-level schematic entry for FPGAs. I started teaching Verilog at Cambridge in 1993. At Virata, we used it both for FPGA and ASIC design. In 1998, I wrote a simple program that generated C code from Verilog, which we used at Virata to translate some parts of our designs into C. That led to the founding of Tenison.”

“In terms of being a general purpose programming language, Verilog has many deficiencies, including a general lack of features, or the potential to simulate differently from synthesis. The current hardware design methodologies using Verilog are simply ridiculous. We ask our engineers to encode a design at a low level and in a massively parallel way. RTL design techniques force a designer to think of a whole system as a hardware system. But [in actuality], it's much easier to write software than to write hardware.”

“SystemVerilog is a good step towards closing the difference between general purpose languages and HDLs - its assertion capabilities add another dimension to the language. SystemVerilog may be an evolutionarily legitimate step, provided it is eventually defined as a semantically clean language. Otherwise, it will just be another language - good for hardware design, but one with unpredictable properties and missing features. I have spoken about synthesis from assertions, but this is probably a long way off from reality, despite being an interesting and desirable end point.”

“Both SystemC and SystemVerilog are block-structured imperative languages that can be traced back to Algol 68. There's certainly not a lot in either of those languages that's either new or trendy, although they are both worthwhile steps forward. SystemC is really just C++, so it can be more easily integrated with software design and front-end architectural exploration. SystemVerilog is be more easily integrated with back-end low-level hardware aspects of design such as timing closure. Both SystemVerilog and SystemC provide a means of bridging the gap between what hardware engineers do and what the software people do. Although, in actual fact, the industry is being very slow to pick up
on that."

"From Tenison's point of view, using our products you can take your handcrafted hardware design and convert it into SystemC and then your software people can interact with the SystemC. The automatically generated SystemC is not actually being used to design anything. But it can be substituted into the testbed in SystemC and used for architectural exploration. There's no reason why the compilation of SystemC to hardware can't be used, but I think the current generation of workstations is not generally up to producing acceptable designs.”

“I think that most hardware and software design will be increasingly done using fully integrated tool chains. These tool chains will aim to fully support co-design through automatic partitioning between the hardware and software. However, those facilities will go largely unused initially in that designers will continue to have, at the time of design entry, a very clear idea about what is going where. As compiler power increases with increasingly [sophisticated] workstations, however, high-level design and automatic synthesis will become increasingly successful. We can see that endpoint out there today, so I [strongly] recommend designing tool chains that head for [that

“ASIC designers will continue to see their role changing over time. Today, there can be a pretty big separation between the layout, testability/test, and design teams. Perhaps [going forward], the design engineering team will need less and less contact with the back-end people as VLSI design becomes more and more turnkey.”

“Currently at Cambridge, we teach Verilog and ARM Assembler to all of our second year Computer Science undergraduates. They get to build hardware and software to interact with each other at the bus interface level. In the course of their 3-year undergraduate program at Cambridge, students are required to learn ML, Java, and Verilog. They are not required to learn C, but the commercial pressures of employment require that everyone learn C nonetheless. We also have a course on comparative languages where we detail the differences - for instance, the ability to have dynamic free variables or to cleanly support
remote procedure calls and so on.”

« Previous Page 1 | 2 | 3 | 4 | 5 | 6  Next Page »

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Peggy Aycinena, EDACafe.com Contributing Editor.

Review Article Be the first to review this article
Downstream : Solutuions for Post processing PCB Designs

Featured Video
Currently No Featured Jobs
Upcoming Events
RISC-V Workshop Chennai at IIT Madras Chinnai India - Jul 18 - 19, 2018
CDNLive Japan 2018 at The Yokohama Bay Hotel Tokyu Yokohama Japan - Jul 20, 2018
International Test Conference India 2018 at Bangalore India - Jul 22 - 24, 2018
MAPPS 2018 Summer Conference at The Belmond Charleston Place Charleston SC - Jul 22 - 25, 2018
DownStream: Solutions for Post Processing PCB Designs
TrueCircuits: UltraPLL

Internet Business Systems © 2018 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise