AMD uses SystemC for modeling project

There's been little usage thus far of SystemC in design environments, especially in the U.S. But Joe Bailey, member of technical staff at AMD Advanced Development Labs, is using SystemC 1.01 to model a complex Infiniband system. While not an actual product, the effort will help AMD both understand the architecture and gain experience using SystemC. In this interview, Bailey discusses the pros and cons of using the new language.

EEdesign: What system are you modeling with SystemC?

Bailey: The system I'm trying to model is for the Infiniband architecture. It's a new switch-fabric interconnect for servers. The specification is well over 1,500 pages of typed documentation. It's very complex, and it's new. Techniques like this have been used in the past by different server OEMs, but they were proprietary. Infiniband requires a great deal of software support. It's not really a bus, it's a network.

What I'm developing is a simulation model for the architecture. My goal is to create an executable specification, and I've decided to approach this by developing real software drivers, and Infiniband management agents to work under a real OS such as Microsoft or Linux. And then I'm writing a SystemC model for the host channel adapter, or HCA. It's a device that would be a single chip placed on a motherboard.

EEdesign: Any plans to turn this system into a product?

Bailey: Maybe in the future. However, I can only speak about the exercise I'm involved with, which an endeavor to gain knowledge and expertise in the area of Infiniband. I chose SystemC as a way to capture that knowledge.

EEdesign: What was your methodology before, and why SystemC now?

Bailey: I've used very little C language for any kind of hardware modeling. I've generally sat down and done state diagrams and flow charts, sketched out the topology for the architecture, and gone to work writing Verilog. Then I'd build up a testbench in some simulator of choice and debug the hardware in that environment.

One thing that attracted me to SystemC is that I saw a way of easily connecting real software elements running under an OS to my model. When I compile a SystemC model I get an executable, and I can build into it interprocess calls, or IPCs, that allow it to communicate directly with the real drivers and real managers I'm writing. It gives me some flexibility I was puzzling over, had I done the modeling in RTL.

EEdesign: Are you starting your modeling efforts with SystemC?

Bailey: No, I'm beginning with UML [Unified Modeling Language]. The idea is to construct this architecture with UML, and use one of the many programs that let you forward-engineer from UML diagrams and create C++ header files and code stubs. In the case of hardware, I have to convert those to SystemC. I'm currently unaware of any product that spits out SystemC. I'll let a program like Rational Rose or Visio spit out the code stubs, and then I'll probably have to run through some sort of script to get SystemC.

EEdesign: What's your goal with the SystemC modeling?

Bailey: There are various algorithms and flow diagrams explained in the Infiniband spec. I would like to write code such that it exhibits these behaviors, without worrying about specifying registers or exact interfaces between blocks. With SystemC, you can create your own user-defined data types, and pass those in one operation through SystemC ports into other blocks. So you can set up a way of communicating between functional blocks that's pretty fast. I don't have to create an address and data bus, or a particular kind of read/write strobe. I can send the entire structure in one fell swoop to another block and pick out the pieces I want.

SystemC has a sensitivity list. That allows you to define a process that exhibits some functional behavior. You can write a C function that is awakened when a particular port on a module is written to or read from.

EEdesign: Can you do things in SystemC you couldn't do in Verilog?

Bailey: Passing user-defined structures through ports is not available in Verilog. I think there are a number of other abstract port definitions that are not available in Verilog.

EEdesign: Is there anything that's easier in Verilog than SystemC?

Bailey: The problem with C all along has been that it couldn't handle concurrency in hardware, but that's been fixed with SystemC. It might be easier to model small delays, like delays through AND and OR gates with Verilog, but I'm so far from that level of modeling that I don't really care.

EEdesign: Any limitations with SystemC?

Bailey: The only capability I would question is synthesis. I'm not sure just how well you can control the output of a synthesis engine with objectized C code. I have no requirements in this particular project to build real hardware, so I don't need to go to anything synthesizable. But I am comforted somewhat by the fact that supposedly SystemC can be synthesized. If I get that far with this project, I may find myself in a situation where I need to do some synthesis.

EEdesign: What would be your requirements for SystemC synthesis?

Bailey: I don't think there would be anything separate from the requirements of a good Verilog synthesis tool. It would have to be fast and consistent. If I write a construct in SystemC, it had better synthesize the same way. I need to constrain the design the same way I do with Verilog synthesis tools.

EEdesign: Which SystemC version are you using?

Bailey: I'm using 1.0 because I'm working on Windows NT. Version 1.2 is coming out for NT, and that will give me some abstract port constructs. Version 1.0 doesn't handle remote procedure calls, so the abstract port definitions don't work. There is a 1.2 release for Linux, but the Microsoft release will be out later.

EEdesign: Version 2.0 adds channels and events as synchronization mechanisms. Will you make use of these new features?

Bailey: Yes. The higher up the food chain I can go, the less code I have to write. If there are some higher level constructs that let me embody the same functionality, I'll use them for sure.

EEdesign: What tool support, other than synthesis, would you like to see?

Bailey: There are some folks developing semantic checkers. There are a number of things you can do with SystemC that will compile just fine, but when you try to execute the model, don't work at all. It would be nice if tools understood more about SystemC constructs.

You can definitely get yourself into a world of trouble. For example, if you use a thread process, you can insert "wait" statements inside of that process. If you put the "wait" statements in the wrong place, the process will run free and never suspend. If it does that, the simulation just hangs. When you're just starting out, you can spend a lot of time trying to figure out why you're not getting anything.

EEdesign: Was SystemC easy to learn?

Bailey: I thought it was very easy. I read the on-line documentation, downloaded some examples, brought up Microsoft Visual C++ Studio, and coded examples I found on the web. I took a three-day class from Willamette HDL. I was pretty comfortable. Even though it's object oriented, it's right up my alley because I'm a hardware guy. It has clocks, ports, signals, and modules.

EEdesign: Based on your experience so far, will you stick with SystemC?

Bailey: I think so. I haven't seen anything about SystemC that tells me that I can't accomplish my goals. Its ability to respond to IPCs from real drivers is nice. SystemC just seems to have some big momentum and some big backers.