Open side-bar Menu
 What Would Joe Do?
Peggy Aycinena
Peggy Aycinena
Peggy Aycinena is a freelance journalist and Editor of EDA Confidential at www.aycinena.com. She can be reached at peggy at aycinena dot com.

John Sanguinetti: Grand Challenges in EDA, Chilling Challenges in Security

 
June 1st, 2017 by Peggy Aycinena


Master technologist John Sanguinetti
has made major contributions to the EDA industry in the first decades of his career, and is now doing the same for the IP industry. After finishing his PhD at University of Michigan, Sanguinetti worked at DEC, Amdahl, Elxsi, Ardent Computer, and NeXT, was President at Chronologic, Modellogic, and CynApps, and was CTO at Forte Design.

In 1990 while still at NeXT, Sanguinetti became convinced he could write a better simulator than Cadence’s VerilogXL, so working nights and weekends for several months he wrote VCS. The potential of the tool inspired Sanguinetti and Peter Eichenberger to found Chronologic. They launched the product in late 1992, and sold the company to Viewlogic in late 1994. Synopsys acquired Viewlogic in 1997, and VCS has continued on there as a foundational element of the company’s verification strategy.

Currently Sanguinetti is serving as Chairman at Adapt-IP, but given his long and distinguished history with EDA, he agreed to opine this week on Grand Challenges in EDA. In the following conversation, he offers two Grand Challenges in EDA and two in Security, the latter being an issue of rapidly growing concern worldwide.


********************

SystemC IDE …

Sanguinetti framed the issues within the structure of his company: “At Adapt, we do IP design using high-level synthesis, and high-level design in general. From what I see, the challenges we have include design entry and manipulation, and dealing with verification.

“In my personal experience, we really need something like a SystemC IDE [integrated development environment] that is more comprehensive than what the vendors provide. Cadence has one and I’ve used it for years, but it’s representative of a class of tools that is not well done in the industry.

“The Cadence [IDE] has a bunch of nice features. It knows about SystemC and hardware conventions, but that’s all it knows. It has a broader mandate than just design entry.

“There is an opportunity here to create a kind of higher-level IDE than the one Cadence offers, something that makes it easy to add modules, modify port lists in the modules, and just do general IDE-like things putting together designs in both a graphical and textual way.”

Recalling past offerings available in the industry, Sanguinetti said, “There was a tool from Summit Design that would let you take a set of blocks and construct a design, which was killed when Summit was sold to Mentor, even though it had some traction.

“There’s also a tool from Xilinx called Vivado that does a lot of this in a Verilog context. It actually does support C++.

“I’ve looked over the shoulder of Mac McNamara [CEO at Adapt-IP and DAC 2017 General Chair] while he’s been using Vivado. Initially we were fairly impressed with its capabilities, but only in a Xilinx environment. It really should be available in SystemC.”

Reading from a list of Grand Challenges I published here in 2012, I asked Sanguinetti to comment on one of them: High-level design.

“The problem with high-level design,” he said, “is that you’re dealing with engineers who are used to working in Verilog or SystemVerilog. [Problems develop] when asking them to move to what feels like an unfamiliar language. The ideas are not different, but the expression of them is.

“And engineers need for the whole thing to be simpler. But there’s a big problem with SystemC – it’s based on C++ and is not simple.

“People sometimes say, we’ll do the synthesizable subset of C++, but there really isn’t one. You can put in some restrictions, you can use this feature or that one, but you can’t synthesize it because there isn’t really a synthesizable subset.”

“You do need tools that automate some of the grunt work,” Sanguinetti continued, “because there is a fair amount of grunt work [involved in] expressing hardware in SystemC. Some guys out there say it proves SystemC is not the right language. But there aren’t any other better languages.”

Are there other options than just C or C++?

“Bluespec tried,” Sanguinetti noted. “And Synopsys will say that SystemVerilog is the right one to use, but they don’t even pretend to have a high-level design flow from SystemVerilog to implementation.

“True, the advantages of being C-compatible are great enough – and we’ve been saying this for 15 years – that there’s a strong incentive to fight through the language and complexity problems to get compatibility with C. These days compatibility with C means compatibility with C++.

“And that’s the issue: If somebody can come up with a better language, they will be successful. But I don’t know how to do it.

“Although actually, the answer is a higher-level tool that knows about the language and can deal with the complexity of expressing hardware in SystemC.”

I asked Sanguinetti why, in their market-speak, some companies claim to offer system-level tools targeted at specific systems like automotive or the IoT?

“You’ve got me,” Sanguinetti said. “Is there some particular language feature that’s specifically targeted at automotive applications? Of course not.

“Potentially, there’s a collection of IP that is [relevant to a particular system], but then you need the tools to put that together.”


********************

Verification IP …

“There are big challenges in the IDEs,” Sanguinetti continued, “but right now the main Grand Challenge in EDA is verification IP. We use verification IP extensively in our work at Adapt-IP, and from what I’ve seen it needs to be much simpler.

“But there’s a problem with UVM and its [associated] tool complexity. When you try to marry verification IP in SystemVerilog with UVM, it turns out there’s a lot of complexity that you don’t get any value for. And, integrating it into verification IP consumes a lot of time.”

“Maybe that’s a common complaint, and that’s the way life is,” Sanguinetti acknowledged. “But it seems you could do a better job of making the interface to verification IP more usable.

“Instead, what you end up doing is buying the verification IP, which comes with a bunch of tests for your particular application – but not all. The tool you buy has a means of extending so you can write your own tests, but from what we’ve seen that is not easy to do.

“There are a lot of assumptions being made [that are not realistic], so the tests are not compatible with what you need. You have to write your own tests or be limited as to what you can do.”

Sanguinetti turned philosophical: “I think VIP is a tough business, and I don’t really understand at all how it’s a good business.

“Although, Cadence seems to do okay with it. Their VIP unit is doing very well. Truechip in India also gets business, helped by lower costs of labor. We’ve been working with them for a long time, using their stuff to test our stuff.”

Would you buy from other players, say Synopsys or Mentor, I asked, if they could do it better?

“The answer to that,” Sanguinetti said, “is at what price? We do pay for VIP, but we would sure like it to be better.”


********************

Security for the IoT …

I noted that Sanguinetti had proposed two Grand Challenges in EDA: Better verification IP and a better SystemC IDE. “What else?” I asked.

“Yeah, now we can go to Security,” he replied. “In the IP space, one of the products we’ve been developing for a while is a baseband for 802.11 ah.

“It’s really appealing technology [used] in standard application areas. It’s low bandwidth, low bit-rate, ultra low power which is good for IoT, and something that has a whole world of interesting applications.

“But security is something that really wasn’t addressed in the 802.11 ah standard, although it’s something that can be layered on top.

“But if you’re making an IoT product to do the physical layer, the baseband basically lives in the PHY with a MAC above it and has to talk in a pretty intimate way [to the physical layer]. And you must have a security story.”

Sanguinetti enumerated the different applications that definitely need that story: “Pacemakers, for instance. If your pacemaker is accepting commands to change its function, [there are security problems].

“And the same is true with automotive applications. With insufficient security today, anyone can just walk by a car with a handheld transmitter and see what they can do.

“There are security standards out there [to address problems] at all levels of the communication stack, but these are only nascent standards and haven’t gotten wide acceptance yet. This is something that has to be addressed – it’s definitely a Grand Challenge.

“Think what you could do with a sensor and an actuator out in the field. The constraint is that it will live [in the field] for 5 years without changing the battery and up to a kilometer from its base station. And the base station will be able to support up to 8000 devices.

“These IoT devices are going to be [produced] in the billions. When you think about all the different places where you could employ this kind of technology – sensor and actuator, or just a sensor – you can come up with a big list. And these things are going to be cheap.

“[Meanwhile], there are competing standards. NB-IOT, for instance, is based on cell-phone technology, so the carriers are involved and you pay $1-$2 a month for the privilege of getting a signal from the cell-phone tower.

“But then look at factory automation. Why would you want to pay a carrier, when you could install client and base stations. You put one access point in, and with it can control the whole factory. That’s pretty appealing.

“But the security issues definitely will need to be addressed and it’s going to take a lot of work, [particularly] as not all of the issues are understood. There are a lot of embedded applications, with software and hardware and control systems all involved.

“Until recently, nobody thought about security [in all of this], but people are thinking about it now. And still, they’re putting insecure systems out in the market.”


********************

Security for Legacy Systems …

“Which brings up the final Grand Challenge,” Sanguinetti said. “The security of legacy systems.

“For instance, we have a product prototype that we’re just starting to take out and show to people. It’s a USB firewall, because it turns out there’s been an insecurity in the USB system that’s been there since Day 1. It’s just appalling.

“Although when you look at the engineering in a USB device, it’s clear you would have designed it just that way and not provided security. But now you have to start thinking about all the bad actors and what they can do with this insecurity.

“Because you can take this USB device that looks like a memory stick, but inside is really a little computer that is not only has memory, but a keyboard as well.

“You put this USB device into your PC and the system asks, ‘What kind of device are you?’

“In response, the USB device says I’m a memory stick and I’m a keyboard. And because it has been programmed to inject keystrokes, it can now inject anything it wants to into your PC.”

“This is almost a perfect device for infecting a system with ransomware,” Sanguinetti warned. “It loads a rogue file, works on it for 3 hours or so, perhaps starting at midnight, and starts to collect ransom in Bitcoin in the morning.

“It’s been out there for a few years now and works against Windows, Chromebook, and MaciOS. In our work, we’ve programmed one of these USB devices to infect all three of these operating systems and found that none of them can protect against it.

“Worse yet, it turns out there’s a website, the HackShop, that sells these devices for just 50 bucks. It’s called a Rubber Duckie and comes with an SDK that lets you program the thing to inject anything you want.”

“So there are legacy operating systems,” Sanguinetti reiterated, “[potentially] under threat from millions of legacy USB devices out there. The only real protection is to not use a USB device at all, which for some companies is actually the answer.

“Or you can use our USB firewall to protect your system. It won’t let a [corrupt] USB device be recognized, although admittedly having a single firewall to protect against all possible threats from a USB device is a very difficult proposition.”

“And by the way,” Sanguinetti added, “the same guys who made the Rubber Duckie now have the Bash Bunny. These things are malicious, inexpensive, and are out there for the bad guys to buy.

“It can send your data across whatever Internet connection you’ve got, and can presumably download that data. This device is being used for something other than injecting ransomware. Whoever uses it, wants to steal whatever files they can find which could be useful.”

This is a very chilling view of the world, I said. Quite pessimistic.

Sanguinetti agreed: “You know how many billions of USB devices are out there? Billions of memory sticks. So the question is: How do we protect against this when the legacy systems can’t be changed?

“Yeah, it’s chilling. But again, it’s also a market opportunity. There may be software solutions for these legacy systems but for things like USB, a firewall is a hardware solution.”

“Security is going to be a dominant theme,” Sanguinetti concluded, “a Grand Challenge for some period of time because we’re all so exposed right now.

“But we’re not going to stop using the Internet because of it, so we are just going to have to figure it out.

“And yes, I agree. Lives will be lost before it’s solved, particularly if you look at medical devices where security is critically important. If people use today’s insecure medical devices, at some point someone is going to get killed because their device is vulnerable.

“On the other hand, if the person who needs the device has to wait until the manufacturer figures out the security issues, they might die anyway.”

Still you’ve convinced me, I said. I’m just going to stop using the Internet.

Sanguinetti chuckled: “Okay, but just think about how the Internet has improved our quality of life.

“I certainly wouldn’t want to live without it.”


********************

John Sanguinetti Profile …

Read here to learn more about John Sanguinetti’s contributions to the EDA industry, including his role in developing VCS.

********************

Related posts:

Tags: , , , , , , , , , , , , , , , ,

3 Responses to “John Sanguinetti: Grand Challenges in EDA, Chilling Challenges in Security”

  1. […] John Sanguinetti: Grand Challenges in EDA, Chilling Challenges in Security […]

  2. Scott Thibault says:

    In my experience, EDA tools seem to lag in general compared to the state-of-the-art in software design tools. I’m not sure how you could argue against the power that a rich semantic-based IDE could bring. I also believe the modern C++ language has a lot to offer in terms of delivering higher-level design. Although my target audience is not the traditional hardware engineer, I’ve done work on high-level synthesis from embedded Domain Specific Languages in C++. These leverage a familiar syntax for embedded and software engineers and really raise the level of abstraction. If you put that together with an IDE that understood the DSL, we’d have something pretty amazing.

  3. […] in the ecosystem about Grand Challenges in IP and EDA – Sonics, CAST, Silvaco, Synopsys, Adapt-IP, and Mentor […]

Leave a Reply

Your email address will not be published. Required fields are marked *


*




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:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise