Skip to content

Mike In India

When designers gathered in Noida, India for the annual India SystemC User’s Group (ISCUG) Conference recently, Forte’s Mike Meredith was there. As our Vice President of Technical Marketing and former president of the Open SystemC Initiative (OSCI), Mike is well known in the SystemC community. He was there to present to a large and enthusiastic group of designers, a designer community ready to embrace a SystemC-based chip design approach with many already having adopted high-level synthesis (HLS).

Mike Meredith

Forte's Mike Meredith

Starting with a three-hour tutorial titled “Using SystemC for high-level synthesis and integration with TLM (transaction-level modeling),” Mike covered the key reasons for raising the abstraction level and looked at the synthesizable SystemC subset that makes HLS a practical reality. Mike talked about the history and “basics” of HLS, provided an in-depth analysis of what HLS is, and dove into the intricacies of HLS and SystemC that he is so uniquely qualified to cover. He concluded the presentation with user experiences, and later on gave an additional talk called “A look at the origins of SystemC and the future directions of SystemC”.  His entire presentation is available on our website.

ISCUG was a big success for Forte Design Systems, and we want to thank Umesh Susodia of CircuitSutra for organizing this great event.  Take a look at the event photos (where Mike isn’t too hard to spot).

In the end, Mike obviously generated a lot of interest in HLS — he spent the rest of the week demonstrating Cynthesizer onsite at companies all over India.

If you couldn’t make it to ISCUG and want to see what all the fuss is about, there’s a great opportunity coming up — DAC! Come on down to Austin June 2-6 and see us in booth #1547, where you can register for one of our sessions and see for yourself.

Happy Cynthesizing!

Brett
@BrettCline

The Man Who Came Back to HLS: Observations of a Reformed FAE

I’m coming back into the field of High Level Synthesis after a sojourn in emulation, and I’m struck by the parallels between the two industries. Eight years ago, most chip companies were not interested in using emulation. The majority of engineers didn’t have any direct experience with emulation, but they had heard it was expensive and hard to use. The engineers that did have some experience with it often had a bad experience, and didn’t want to try it again. The management wasn’t interested in looking at emulation because their current methodology had worked fine for their last chip. The combination of ignorance and complacence made it easy for these companies to dismiss emulation as unnecessary.

There were a few companies getting a lot of value from emulation, but they were being very quiet about it. These folks saw emulation as a competitive advantage and they didn’t want to let their competition know what they were doing. They were right (selfish, but right), and their refusal to talk about what they were doing reinforced the prevailing opinion that emulation wasn’t interesting .

The increasing demand for modeling complex software running on complex hardware before the hardware design is committed to silicon put enormous pressure on software simulation systems, and changed emulation from a competitive advantage into a competitive necessity for many types of SoC designs. Companies that didn’t want to think about emulation before are now scrambling to adopt it–a really painful process when you have to simultaneously figure out how to use it, and get it working on your production project.

So how does this compare with the High Level Synthesis market? The HLS market is almost identical to the emulation market 10 years ago. There are a number of designers that have been using HLS for production designs for years, but they don’t want anybody to know about it. Most of the engineering community has a vague notion that HLS is difficult to use and not very effective, completely unaware of what a modern HLS tool can do. The engineers who have experience with first generation HLS tools don’t want to try HLS again. Management sees that the existing RTL methodology worked for the last chip, and therefore thinks there is no pressure to change. But the pressure is there. There is demand for the ability to produce more high quality RTL faster. There is demand for efficient design reuse. There is demand for the ability to rapidly change implementation technology. HLS satisfies all of these demands. It’s hard to predict when one of these demands will become critical for your business, but when it does (and it is when, not if), the history of emulation shows that the people who were thinking ahead have a much happier life.

Forte has been delivering HLS since the early 2000’s and the technology goes back even further than that. When I worked on HLS in the mid-2000’s, adoption was primarily limited to a bunch of forward thinking Japanese companies and a handful of others around the world. Things have changed in the last 8 years. Now, some of the largest and most successful US companies have invested heavily as well as leaders in Korea, Taiwan, India, and other major regions.

If you evaluated HLS tools a long time ago and thought they just weren’t ready, it may be time to take another look.  I just took another look myself, and I rejoined Forte Design Systems because of it.  I’m now in a position to help companies that are interested in HLS jump in and achieve first time success. It reminds me a lot of when I joined the emulation field 8 years ago and the road to success seemed impassable. With a truly mature HLS tool like Forte Cynthesizer, there are bridges, shortcuts and fast lanes you never knew existed.

2012: A Banner Year for Cynthesizer … Thanks to You!

Hello, everyone,

Thank you for helping make 2012 a banner year for Cynthesizer High-Level Synthesis. Cynthesizer now has more than 1,400 registered users and has had incredible growth in the USA, Korea, and Japan. Cynthesizer was also named the #1 high-level synthesis product by Gary Smith of Gary Smith EDA in his 2011 market share report.

Last week, we announced that Hitachi JTE became a customer in late 2012, joining other large customers in Taiwan, Japan, Korea, and the USA. We expect this trend to continue as design teams move away from other HLS tools limited to ANSI-C and block-based design. Many of you have told us what we’ve been saying all these years is true: it may be easy to start a design with these other tools, but to get your design out the door you need the high-level approach of SystemC and Cynthesizer.

While 2012 was a great year for Forte, we aren’t standing still. Our product team is hard at work developing a number of new features and capabilities designed to get you better results in less time. We’ve announced support for SystemC 2.3 and that is just the tip of the iceberg. We’ll have more features, SystemC IP, and new products rolling out soon. Stay tuned for more news from us over the coming months.

The team will also be out and about throughout the year at major conferences and trade shows, including DVCon, DATE, SNUG DCE, SystemC India, SystemC Japan, and DAC.  Don’t forget to come by and see why each year more of you are choosing Cynthesizer SystemC synthesis for your leading-edge ASIC, SoC, and FPGA designs.

Thanks again to all of you for continuing to make Cynthesizer the industry standard for high-level synthesis.  We look forward to making you even more successful in 2013!

Brett

A Forte Design Systems Profile From EDACafe

Russ Henke, a contributing editor at EDACafe, recently profiled Forte. We’re repurposing it here in its entirety because we think it’s an accurate depiction of where we’ve come from and what we’ve accomplished.

We hope you like it as much as we do. Please send your comments.


A Profile of Forte Design Systems

Let’s start with a picture of a building that’s likely to appear familiar to a lot of readers – the front of the New York City Public Library.

New York City Public Library

Did you know that the two marble lions prominently visible in front of the famous library are named “Patience” and “Fortitude?” We shall see how these words might also describe many of the people of Forte Design Systems, and perhaps similarly named statues should be placed in front of Forte’s headquarters at 100 Century Center Court in San Jose, CA.

Forte Design Systems logo

The tale of this high-level synthesis company starts with the successful 2001 merger of two companies, CynApps and Chronology. Executives of the newly formed company wisely chose a descriptive name for the combined company, since “forte” means “good at” or “strength” though patience and fortitude, and the people of Forte have both in abundance.

Brett Cline

Forte’s long-time vice president of marketing and sales Brett Cline said the following: “Forte’s been around for many years now and is the major driver of a whole new market segment. I consider us to be a definer of the high-level synthesis market. And, we’re good at it.”

The Forte Corporate Culture and its Founder
Let’s pause here and define from 10,000 feet the term “high-level synthesis software.” From all accounts, it enables electronics hardware engineers to work at a higher level of design abstraction.

Any story about Forte must start with Dr. John Sanguinetti, the EDA luminary noted for launching Chronologic in the 1990s and developing VCS, the Verilog Compiled Simulator, which is still in widespread use today.

After Chronologic was acquired by Viewlogic in 1994, he started looking for his next adventure. (As an aside, Viewlogic was itself acquired by Synopsys in 1997). Since Dr. Sanguinetti’s expertise was performance analysis and design verification, he understood that there were two basic problem areas in EDA –– logic verification and logic synthesis. He already had tackled logic verification; a closer look at logic synthesis seemed in order. For more than a decade, he had known that a change in abstraction levels from gates to RTL (Register Transfer Level –> see ”Acronyms” at conclusion of article) would improve design and verification efficiency, and that such a change might be enabled by logic synthesis.

Dr. John Sanguinetti

A true entrepreneur in every sense of the word, John is Forte’s CTO today. He is also a 2011 ACM Fellow for contributions to hardware simulation. He serves as a role model and mentor for many entrepreneurs and engineers and has been quoted as saying: “In a technical field like EDA, understanding the problem, and understanding the technology, are prerequisites.”

Since John’s name is synonymous with the word entrepreneur, let’s find out how that came to pass. “I was caught up in startup fever from my first year in the Valley (1982). Ardent was my first real startup (1986), but it was a big-time operation –– I was #24. After that, I knew I wanted to start something, but it took a while to figure out what.” That something was Chronologic.

John has been and continues as an active angel investor in the EDA industry, helping drive EDA technology and businesses forward. He has put “seed” funding into many EDA companies that have had successful exits, including Ambit, Magma, Moscape, CoDesign, Surefire, Hier Design, Innologic and, most recently, Nextop. John has been or is actively involved in more than 20 other ventures as an angel investor, mostly in EDA and many still going.

Becoming an angel investor started innocently enough. “I was introduced to Rajeev Madhavan right after selling Chronologic to Viewlogic. Rajeev was trying to start Ambit, and I was interested right away.”

Rajeev Madhavan

“I spent lots of time with Rajeev trying to pitch Ambit to interested VC’s. I not only made money on the investment, but gained a good friend, and felt like I had made a contribution to a worthwhile venture.”

John said he had no investment formula when he got started and referred to his early choices as “haphazard.” Many entrepreneurs approached him after his success with Chronologic and he found it hard to say no. After five or six years and a string of failures of promising ideas and technology in divergent fields, John restricted himself to EDA. “So far, none of my non-EDA investments had a positive return. All of my successes have been EDA.”

Influence on Forte
John’s technical vision, business acumen and hard-earned experience are strong parts of the corporate culture at Forte Design Systems.

Telecommuting has long been another hallmark of Forte’s corporate culture, something that’s far more common today with other companies than it was in 2001. Forte may be headquartered in San Jose, but it also has offices throughout the United States, including Pittsburgh PA, and Redmond WA, and international offices in England, Japan and Korea.

As Brett Cline, who works from Boston, pointed out, “It’s a small world. We may be in different states or on different continents, but we make use of all the available collaboration tools.” And it seems to be working.

The Forte team at the 49th DAC, San Francisco, June 2012

Carving Out the High-Level Synthesis Market
In 1998, John Sanguinetti and two other engineers founded CynApps to create a higher level design environment, along with a synthesis product that would produce RTL code from higher level designs. A tool challenge and one not easily solved, and it took a long, long time, but Forte finally did it.

In this achievement we realize that this is where patience and fortitude paid off. Forte succeeded where other companies haven’t, by exhibiting dogged determination, winning over design teams one at a time, while the industry as a whole struggled to define the market category.

Long-time EDACafe readers might well recall the names of other companies with behavioral synthesis that morphed into architectural synthesis, ESL and algorithmic synthesis. None of the names stuck and their tools eventually failed. But Forte stayed on course with high-level synthesis, a term now widely adopted by the EDA industry, as the production-quality tools themselves go mainstream.

Success has finally come to Forte. John gives loads of credit to investors who believed in Forte and didn’t give up. In particular, Sam Lee, managing director at Infinity Capital, has been an investor since December 1999 and holds a board seat. Likewise, another EDA luminary Lucio Lanza of Lanza TechVentures participated in Forte’s Series A funding way back in November 1998 and has served continuously as chairman of the Forte board. “Stalwart” is the word John uses to describe both.

As an aside, investors in Forte’s first round of funding reads like a Silicon Valley Who’s Who: Andy Bechtolsheim, who was that series’ largest investor; Gordon Bell; Steve Blank; Paul Huang; and Jon Rubinstein.

Meet Sean Dart of Forte
Sean Dart is Forte’s CEO and is highly technical, an unusual combination in today’s business climate, but vital to an emerging EDA company. Sean grew up in a small town 400 miles north of Sydney, Australia, and moved to Sydney to study computer science at New South Wales University.

Forte CEO Sean Dart

His decision to study computers was a curious one, considering Sean had never seen a computer. The decision came after talking to career counselors. He was a good student in all subjects but preferred scientific studies. The advice he received was that computing was the up and coming field. This appealed to Sean because he could combine his interest in math with the practical, giving him an opportunity to merge the intellectual with a job. And, he loved it.

Today, everybody has a personal computer, so it’s difficult to imagine the days of computer centers. [Maybe for Nanette, but not for others, such as your Contributing Editor]. Sean said that he and his colleagues used hand-marked cards, not even key punched cards. He mused that even later, the 30 VAX terminals from the computer lab at his college had one-thousandth the capabilities of an iPhone.

Sean’s first job out of college was working for STC (Standards Telephones & Cables) in Australia designing embedded programming for PBX systems. After two years, he was designing operating systems for small business computers and then moved on to Olivetti. He was subsequently transferred to Colorado to work with AT&T to customize telecommunications equipment for the Australian market. Once that project was abandoned, Sean and his American wife moved to Switzerland where he worked for a company that second-sourced ASIC designs. His role was to manage the network and develop tools and utilities to support the design services team. The company needed utilities, especially for verification, to help retarget designs.

After a fashion, the company decided it was making more money in the tools area and became an ESDA company, Sean’s introduction into EDA and a forerunner to high-level synthesis. The company, Speed Electronics, was sold in 1997 to Mentor Graphics.

After 10 years in Switzerland, the Dart family, that now included two children, relocated to Silicon Valley in pre-Internet 1997 but quickly discovered that the SF Bay Area was an expensive place to raise a family. After looking around the EDA companies in the Seattle and Boston areas, he liked what he saw at Chronology in Redmond, Wash., less than 20 miles from Seattle.

So in 1997, after only five months in Silicon Valley, he and his family moved to a town 15 miles east of Redmond. “It’s a great place to live,” he noted.

It’s at this point that we need to hear more from Brett Cline, who truly has his finger on the pulse of the high-level synthesis market and someone who has been a major contributor to Forte’s success. Brett may be a bit more informal than the consummate executive of old, but one is not fooled by the informality. Anyone who talks to him will pick up on his competitive streak. “Massively competitive,” he admitted, “I hate to lose and don’t accept losses that well. I push myself to do things better and I try to encourage others to exceed as well.” He admires winners, but firmly believes that it’s important to be a team player as well, something that’s apparently important as well to the 35 or so Forte employees.

You may have also heard that Brett is one marketing executive willing to dress in costume, as the situation calls for it. In 2003, he donned a hockey goalie uniform to present a DVCon paper titled, “Why You or Your Replacement will Use SystemC for System Design,” claiming he needed the padding for his defense in front of a room of skeptical RTL designers.

In 2005, Brett dressed in a chicken suit at DAC after losing a bet to John Cooley, editor of ESNUG and DeepChip. They agreed to a “Gentlemen’s Bet” over whether SystemC adoption would be more than 50% in the results of the DeepChip Verification Census. Brett said it would, John Cooley said it wouldn’t. John Cooley ruled that day, “but he was counting the votes,” laughed Brett. “It would be interesting to see if he is willing to make that bet again now.”


Brett in the chicken suit

© 2012 Forte Design Systems/Brett Cline


Brett still in the chicken suit talking with John Cooley

© 2012 Forte Design Systems / Brett Cline

Brett is a friendly New Englander who grew up in Manchester, CT. He moved to Boston to attend Northeastern University and worked at GE as a co-op student. EDA has a few Northeastern grads, but younger readers may not know that Northeastern is renowned for its five-year co-op program where students get real-world experience by working in companies before graduating (Other schools of course offer co-op university programs, such as the University of Cincinnati where the Contributing Editor obtained his engineering degrees).

After graduating, Cadence in Massachusetts came calling because Brett’s background included both hardware and software. Brett was put to work on a waveform project, then VHDL simulation graphical tools and was tasked to work with the SimVision team. He enjoyed working with the sales and FAEs, and eventually moved into technical marketing for many of the same products he had spent time building.

SimTech recruited him in 1997 to be the East Coast application engineer, before SimTech was acquired by Summit Design that same year. In 1998, he ran marketing for the ex-SimTech products, then picked up corporate communications responsibilities as well.

It was in November 1999 that Brett called a friend at CynApps about joining. He knew the legend of Dr. John Sanguinetti from late nights at Cadence working with the Verilog-XL and NC-Sim teams to compete with VCS and Brett was eager to meet Dr. Sanguinetti.

Brett liked much of the CynApps story, especially the verification piece, but he remained a bit skeptical about behavioral synthesis, a still unproven technology. He wasn’t certain the electronics industry was ready for behavioral synthesis, but he became more and more excited about CynApps’ entire product portfolio, including a simulation library that could be marketed as an open source product with C++ simulation, services and debug and analysis tools that captured his imagination. He signed on and then CynApps acquired DASYS in January 2000, which further cemented the focus on behavioral synthesis.

Concluding remarks about John Sanguinetti
The first thing one learns about John Sanguinetti when talking with him, is his modesty. The second is his candor.

When asked what influenced him to study computer science, John said, “After my freshman year of college, I had a summer job in the Navy Department in Washington, D.C. where I wrote output reports in Fortran for a shipyard simulation program that was being developed. I learned Fortran from a self-study course that the government had. After that, I took as many programming courses as I could. This was 1967-70, when Computer Science was not much more than programming courses.”

While many of us associate John with Michigan and the University of Michigan, he’s originally from Silver Spring, MD, a suburb of Washington, D.C. “I went to college at University of Michigan for 11 years, so it’s fair to say I’m from Michigan, too.”

His fondness of the University of Michigan and Ann Arbor is strong. He met his wife in college and his daughter Anne was born in Michigan. “I still go back there to play in the alumni Marching Band at homecoming,” noted John. A fine trombone player since he was a teenager, he has also performed with the Peninsula Symphony for 25 years.

We talked as he was getting ready to leave on a vacation at the Maryland home he owns, a home that has been in his family for many years. It sits on the beach of the Chesapeake Bay, giving him ample opportunity to sail his Sunfish sailboat off the beach or take the wooden kayak he and his wife built several years ago.

Yes, a wooden kayak. John recalled finding a company that sells kits for building wooden boats. Over the course of two summers, two weeks at a time, they built a kayak now housed at Chesapeake Bay. He said, with characteristic modesty, that the experience was like any other woodworking project, which meant following directions. It was straightforward, though he recalled lots of sanding. And definitely a bit of patience and fortitude.

The wooden kayak

Merging Chronology and CynApps
The 2001 merger of CynApps and Chronology created an interesting dilemma and one that was debated all the way to the board room. The question was how to make Forte Design Systems both a verification company and a synthesis company. Chronology was making money as a verification provider, but was not doing as well as Verisity (now part of Cadence).

CynApps was making a little money in the synthesis area, though not enough to pay all the bills; however, it was able to secure funding to grow the company. The decision was made to continue to focus on high-level synthesis and to utilize the plethora of verification tools to build a high-level synthesis environment with verification at its core.

And in that same year, Sony, Ricoh and Fujitsu became high-level synthesis customers of the newly combined Forte and the push was on.

Moving to a high-level synthesis business model was practical. Cynthesizer, Forte’s high-level synthesis software, was gaining traction, though Brett Cline said that the first few years of the merger were killers as Forte honed down at least five products into essentially just one with add-on capabilities. (Chronology’s TimingDesigner was still around in a separate division and ultimately sold to EMA Design Automation in 2007.)

Asia adopted a high-level synthesis methodology ahead of other world regions, willingly making a huge investment in a methodology shift. John, Sean and Brett all credit this turning point to the large number of consumer electronics companies. The high-level synthesis trend started in Japan because consumer device designs were a natural fit for this kind of software. High-level synthesis can implement image-manipulation algorithms, for example, into hardware. Japanese hardware engineers saw high-level synthesis as a way to stay ahead of the design curve from challengers in Korea and China. Moving up the abstraction level and adopting SystemC was a way to leapfrog ahead.

Brett acknowledged a few key and savvy individuals who led this methodology shift, many of whom are still in the business.

At this point in our interview, Brett opened up a spreadsheet and noted that Japan accounted for 99% of 2004 HLS revenue. Over time, it’s become about half of Forte’s revenue and still remains a large and important region.  United States, Korea and Japan, in particular, are design centers where Cynthesizer is in use for all kinds of applications. The USA is Forte’s fastest growing region, designing everything from custom processors to wired and wireless communication devices.

As we’ve seen in this profile, acquisitions have been good for Forte and it did another in 2009. It acquired Arithmatica to complement its product offerings with a portfolio of IP and datapath synthesis technology that has been integrated directly into Forte’s Cynthesizer product.

Typical Cynthesizer design flow

Today, Cynthesizer is chosen primarily by design teams that want to reduce time-to-market pressures by designing at a higher level of abstraction and who require substantial improvements in circuit size and power. In many cases, teams create designs that would be impossible using RTL with their given resources.

The long-term benefit is generally not well understood. The value of SystemC-based IP and the ease at which it can be retargeted and reused is at the beginning of a project, are some things Verilog RTL has never achieved.

A Long Trek for Forte
“It’s been a long trek, in terms of finding the right set of customers who need a flexible format for IP reuse for the future,” said CEO Sean Dart. “Getting a product to that point was much harder than we expected. In 2000-2001, we never expected it to be this difficult. People shrug their shoulders and say, what’s so hard about a translator with clock cycles, far under-estimating what’s involved. The high-level synthesis tool needs to be able to handle different kinds of design styles, implementation methods and coding styles. It must be able to work with all of the downstream tools and libraries. It’s hundreds of things. Everybody underestimates the project.”

Many designers still hand code RTL for most of their designs, even now. Sean noted there’s a bit of inertia in the designer world, and Brett agreed. After all, any new change in the design flow can create more problems. For a designer, it introduces something new –– risk. They need to write in another language at another level of abstraction and change from what has been comfortable for them. “For a company like Forte, we need to prove we can make people successful and show a flexible format for reusing IP where a designer can get great results,” remarked Sean.

And, it finally happened with Cynthesizer. “We created a groundswell of support,” Sean stated, with Brett nodding his head in agreement. “Designers came to understand the utility. Otherwise, their product will miss the time-to-market window. IP development is so much shorter. Once people have the experience, then a second experience, that’s when the groundswell happened.”

He continued: “IP must be compatible and it should be automatically implementable. It’s a key selling point for us. There are reasons to buy the first time and a reason for change. Design teams don’t go into high-level synthesis for IP that will give them two or three times performance. However, as process geometries get smaller, fully timed RTL IP may not be reusable. That’s where high-level synthesis can make a difference.”

At this point, Sean became even more animated and noted: “High-level synthesis offers a way for designs to be retargetable for the next level and an optimal solution for technology, speed and longevity of the design. A key selling point for Cynthesizer is that the IP can be used on another project with almost zero effort.” Forte estimates that while the productivity gain on first development of an HLS-based IP may be 5-10X, reusing that IP block next time around yields over 25X.

“Design teams are experiencing that reuse benefit,” he concluded.

The Career Opportunity
A small company like Forte can offer loads of opportunity, as Sean and Brett found.

Sean’s moved into the CEO position in 2006 and yet is completely comfortable talking with engineering teams and understands their technical challenges. He can see their point of view and feel the pain of their daily lives.

Meeting customers, setting product directions was something Sean did as vice president of engineering. He was involved in many high-level meetings and traveled to Asia quite often. When he moved into the role of CEO, he learned more about the financial side of the business and working with the board and investors. Since assuming the CEO role, he sold a division (Chronology’s Timing Designer in 2007) and acquired a company (Arithmatica in 2009).

“I’ve had three different jobs at Forte and watched about 30 competitors come and go,” affirmed Brett. He started out in marketing at CynApps and was sidetracked in 2005 to work in an operations role for Forte. His task was to set up a post-sales support organization to make sure that Forte serviced its customers to ensure their success. That meant an explicit focus in post-sales support rather than an implicit one. “I’ve always tried to dive into whatever needed to be done and deliver to the best of my ability and, at the time, this was extremely important,” he reported. “Small companies must work closely with every customer to make sure each design project is a success.”

With that mission accomplished, Brett went back to marketing and took over sales in 2006. “We have grown each year since 2006 and we are proud of it,” he said. He also takes pride in having done a lot of things to merge new companies into Forte.

At this point, John Sanguinetti interjected: “It’s gotten a lot easier than it was before. I take a step back and see the market coming around to understand the need for high-level synthesis.” From there, he described a more mature product and a codified sales process that helps identify and better qualify opportunities, something Brett’s done over the past four years.

Sean concurred. Forte’s doing well and, from his perspective, keeping the momentum going is all important. His goal and one shared by Brett and John is to keep the team executing. “Our charter should be to create relationships with customers to get paid fairly for our products. The real trick is to deliver enough value and to be paid fairly for what we do.”

The EDA Industry
As the interview came to a close, Sean was asked for his perspective on EDA. He paused for a moment and answered: “Often the goals of the large (EDA) companies are different from those of the small (EDA) companies. Disrupting the status quo isn’t such a bad thing,” he added and believes that the need for continued innovation comes from small companies. “EDA is a small industry, but an important one. What would happen if everyone in EDA quit to build web pages? It would stop the world economy. We do have an important place in the ecosystem and should be recognized. We need to foster small EDA companies.”

John Sanguinetti, of course, agreed and had one final comment about Forte: “Patience and fortitude really do characterize Forte. We’ve kept at it and appreciate our success.”

So ends our current profile of Forte Design Systems. If personalities are the foundation of a successful company, Forte has them in spades. Forte’s people clearly exhibit the qualities from the names of the two lions in front of the New York Public Library: Patience and Fortitude!

Note: Forte has been the sponsor of a live bagpipers’ performance at DAC since 2001. EDACafe’s Peggy Aycinena captured this year’s performance. Her video is posted on her blog, “49DAC Unplugged:

http://www10.edacafe.com/blogs/whatwouldjoedo/2012/06/12/49dac-unplugged-images-from-san-francisco/

Acronyms:
ACM: Association for Computing Machinery
CEO: Chief Executive Officer
CTO: Chief Technical Officer
DAC: Design Automation Conference
EDA: Electronic Design Automation
ESDA: Electronic Systems Design Automation
ESL: Electronic System Level
GE: General Electric
nm: Nanometer
I/O: Input/Output
IP: Intellectual Property
RTL: Register Transfer Level
SoC: System on Chip
STC: Standards Telephones & Cables
VAX: Virtual Address eXtension, an early mainframe computer from Digital Equipment Corporation (DEC)
VCs: Venture Capitalists
VCS: Verilog Compiled Simulator

Forte Coverage:

EDN: “Sage words of advice from Forte Design Systems founder John Sanguinetti” by Brian Bailey

EDN: “Time to rethink EDA flows and tool infrastructure” by Brian Bailey

EDACafe’s What Would Joe Do: Forte: “Anchor Tenant in the ESL Mall” by Peggy Aycinena

EETimes: “2012 will be the year of power, again” by Brett Cline

EETimes’ EDA DesignLine: “Control dominated design” by Mike Meredith

EETimes’ EDA DesignLine: “Gearing Up for DAC – Above RTL” by Brian Bailey

Electronic Design: “Implement Abstraction By Encapsulation In SystemC” by Mike Meredith and John Sanguinetti

GABEonEDA: “Bagpipers a DAC Tradition” by Brett Cline

High-level Synthesis is not just for Hardware Designers, It’s for Verification Engineers, too!

We’ve seen an uptick in interest in high-level synthesis (HLS) around the world lately. Some of the increased interest is from designers that have MBOs to investigate HLS in 2012. Some interest is from the visibility that Forte’s Cynthesizer and HLS have had this year. And some is from people that simply do not have enough time to get their projects done with the allocated resources. This is where we can really help.

Cynthesizer automates many of the mundane coding tasks that hardware designers have to suffer with using Verilog daily. Through that automation, it will allow designers to quickly perform “what if analysis” on their macro and micro-architectural decisions without wasting months of effort.

Since the design model will now be in SystemC, a C++ class library, the functional code will be written in C or C++. Technically, it’s all C++ because we are using a C++ compiler, but the reality is that ANSI-C can pretty much be used as-is. The benefit of SystemC and C++ come from the addition of hierarchy, clock and bit accuracy, and other hardware specifics not available in standard ANSI-C. And, since SystemC is an IEEE standard, designers know that they are being locked into a proprietary language or set of extensions.

We are often asked about the verification benefits of using SystemC models for design and it’s a great question. While there are numerous others, here are three areas that will benefit from the higher-level approach.

First, hardware design and verification teams will benefit from significantly higher performance models. SystemC models typically run between 10x and 100x faster than RTL Verilog and even faster in some cases. This allows verification teams to setup and debug their verification environment faster, as well as run far more cycles through the high-level model. Since the model can be either a transaction-level model (TLM) or a pin-cycle accurate model (PCA), the verification team can vary the level of interface detail while maintaining high-level functional code.

Second, this model can be used for Virtual System Prototypes (VSPs). These highly abstracted models require far less code to implement (usually 10-20x less code) and are available months before the RTL designs.

Third, the SystemC model with HLS can be quickly targeted for an acceleration or emulation platform, including some of the big emulator “boxes” as well has home-grown FPGA solutions. This flow gives design and verification teams the best of both worlds –– the ability to quickly make changes, and get results into the hardware and get hardware accurate simulations at high speeds. Since SystemC models for Cynthesizer are technology independent, they can be quickly retargeted from FPGA to ASIC and back saving time.

Obviously, some of these benefits are hard to quantify. If we simply look at hardware verification benefits, we can quantify some. Working with a design team, we collected data using an ARM bus-based multi-function printer system. The design consisted of several blocks, both control and datapath, entirely in SystemC.

Here’s a look at simulation performance and the huge difference between the TLM behavioral model and the Verilog RTL model –– almost 500x!:

* This is a process by which the Cynthesizer RTL output is converted to cycle accurate SystemC and simulated in SystemC.

We also measured lines of code for each design:

While generated code tends to be a bit more verbose than handwritten Verilog RTL code, it’s not off by much and it’s easy to see a 10x reduction here. In a paper published at DVCon 2012, a Cynthesizer user claimed a nearly 40x reduction in code. Now that is productivity improvement!

SystemC and HLS provide a myriad of benefits to the designers in the form of better productivity, better quality of results (QoR), and true design reuse through technology-independent design. What had been less clear are the substantial benefits in verification as well.

From high-level models developed much faster to high-speed verification, high-level synthesis really is about delivering a better methodology. It allows designers and verification engineers to spend time on real hardware design problems, not on mundane tasks required by the 20+ year old Verilog RTL methodology.

Follow me on Twitter at @BrettCline!

Simulation

Runtime

(hh:mm:ss)

Ratio

(Compared to TLM)

TLM Behavior

00:00:11

1

PIN Behavior

00:04:40

25

Verilog RTL

01:28:21

482

Cycle-Accurate RTL*

00:25:51

141

This Year’s DAC in San Francisco a Success!

As DAC opened in the Moscone Center’s South Hall this year, it poured rain around the Bay Area and the buses with attendees from Silicon Valley crawled along the streets to the convention center. No one seemed particularly troubled, just surprised. After all, who hasn’t heard: it never rains in June in San Francisco.

No matter. Attendees hurried into Moscone under umbrellas, shook them off, slid them into umbrella sleeves provided by the convention center and rode down the escalators. Game on!

San Francisco is a great place for DAC and a bit of rain –– that stopped mid afternoon –– didn’t dampen anyone’s enthusiasm for the show. Booth traffic was great throughout most of the week, though it did trail off toward the end of show and during keynotes. Our demo suites were almost always full of motivated designers looking for ways to climb up the abstraction level.

SystemC and high-level synthesis have become hot commodities with the design community, and commercial HLS software has become widely deployed. Designers have adopted it for large, critical portions of their designs because HLS provides results that are better than hand-coded RTL. HLS includes control and datapath support, hierarchy support, custom TLM interfaces and numerous other advanced features.

As a result, we had a steady stream of attendees who wanted to see demos highlighting the benefits of SystemC-based high-level synthesis. This year’s demo was based on a real-world example that used an ARM-based image processing system with multiple control- and datapath-type blocks connected with line buffers, and other sophisticated interfaces.

We recently joined forces with HighIP Design Company, a SystemC IP provider who licensed Cynthesizer. As part of the licensing agreement, we resell a high-level, re-targetable USB 2.0 device and embedded host controller for SoCs and FPGAs in synthesizable SystemC form and Verilog RTL code.

We hosted a presentation in our booth by Phil Tharp, HighIP’s principal engineer, who offered a look at how he used high-level synthesis for the design of a USB 3.0 controller. For more details on HighIP’s design methodology, see a DeepChip post Phil wrote that appeared in ESNUG 500, Item 7 found at: http://www.deepchip.com/items/0500-07.html.

Once again, we hired a caricature artist who did well over 100 caricatures in two days this year, something we’ve done for many years. The first year, the artist used traditional paper and a drawing pencil. Since then, our artist has a team of other artists that he works with and has gone digital. We’ve seen various tablets and an iPad used. This year was a combination of a high-end drawing tablet and an 11” Macbook Air. Attendees get a printout of their caricature on the spot and they can also download the digital version from our website.

No DAC ends without the strains of Bagpipers and this year was no different. Forte’s been the sponsor of a live version of the bagpipers’ performance since 2001 and just about everyone left on the floor comes over to see the closing of the show. Peggy Aycinena of EDACafe captured the performance. Her video is posted on her blog, “49DAC Unplugged: Images from San Francisco,” found at: http://www10.edacafe.com/blogs/whatwouldjoedo/2012/06/12/49dac-unplugged-images-from-san-francisco/.

Rain or no rain, DAC went on and the Executive Committee deserves credit for a job well done. I’m looking forward to the 50th DAC in Austin next year.

Follow me on Twitter @BrettCline.

Modular Interfaces Part III: Custom Interfaces

Continuing with our series on modular interfaces, today we’re going to talk about one of the most powerful features in Cynthesizer–the ability to create custom interfaces and use them at a high level. These are more than just ready/valid handshakes or external memory interfaces like I showed you last time. These are very complex streaming and buffer-style interfaces that transfer entire data structures.

Anyone who has designed a complex interface in RTL knows that one of the biggest chores is keeping track of the details, and it’s difficult to reuse the work you did before if any of the interface details change in any way.  If the data is a multidimensional array, the interface needs to know things like the row and column parameters so the array is formatted properly. If the data is moving from one thread or module to another, the interface needs to understand how to synchronize between them. And most interfaces require some kind of internal memory to temporarily store data in case the reads and writes happen at different speeds.

All in all, when you design interfaces in RTL you spend all your time and many lines of code getting all these details resolved. There’s no way to just say “take the data from here and put it over there.”

But in Cynthesizer there is, and it does it in a way that drastically reduces the amount of code you have to write and the time you spend verifying it. The keys to this are interface generation and packaging the details up so that you can write your algorithm at the transaction level. Keep reading and I’ll show you some hard data on that.

Interfaces ‘R Us
So I want to create an interface, a real complicated one. What do I do?

Well, in Cynthesizer there’s a tool called the Interface Generator. The Interface Generator is a combination of really sophisticated IP and a graphical editing window where you can create any custom, fully parameterized interface. This interface then becomes a packaged component (actually a set of C++ classes) I can use in a high-level SystemC design. Here’s a rundown of familiar interface types you can create in the Interface Generator:

  • Buffer
    • Transfers data between two modules or threads through a shared buffer.
  • Line Buffer
    • Transfers an array and stores multiple rows of data for reading.
  • Circular Buffer
    • Transfers data over a circular buffer where the reading and writing operations are tightly synchronized.
  • Streaming
    • Transfers an array of streaming data over one or more clock cycles.
  • Trigger/Done
    • A master/slave architecture with acknowledgement signals at the beginning and end of data transfer.
  • P2P Stream
    • A general form of Forte’s CynWare point-to-point interface with features for creating specialized fifos.

For each type of interface, the Interface Editor window in Interface Generator shows you a diagram of the read/write structure, a diagram of the access pattern for the datatype being transferred, and many related parameters that you can define for your needs. Best of all, the interface you create will have transaction-level functions like get(), put(), x_done(), next_y(), etc. that let your algorithm execute entire interface accesses with a single function call.

A Real Example
Let’s take a look at creating an interface part and using it in a SystemC algorithm. I will describe what I want the interface to do in words because it would be too daunting to describe in RTL.

I want an interface that does the following:

  • Allows a reader and a writer to share an array of 16-bit unsigned integers
  • Allows the writer to write to the array in groups of values, working from the beginning of the array to the end
  • Allows the reader to read the array in groups of values working from the beginning of the array to the end
  • Coordinates the activities of the reader and writer so that there is no need to store the whole array in memory or registers

Okay, that’s the basic function and it seems easy enough. But for something like this to work in the real world you need to cover that stuff I mentioned before—the details. And the details are things like this:

  • Implement the internal buffer to be 1024 words long
  • The writer puts the first group of input values (let’s say 2 at a time) in the first two words of the buffer (words 0 and 1), put the next group of inputs in the next two words of the buffer (words 2 and 3), etc.
  • The reader gets the first group of output values (let’s say 8 at a time) from the first eight words of the buffer (words 0-7), get the next outputs by shifting once and reading the next eight words (words 1-8), etc.
  • When the writer has put inputs in the last two words of the buffer, circle around and put the next inputs in the first two words of the buffer
  • When the reader has grabbed outputs that go beyond the edge of the buffer, circle around and get the remaining values from the beginning of the buffer
  • Maintain input and output buffer pointers to make sure the correct buffer contents are read or written
  • Synchronize the interface at the beginning and the end of the algorithm’s execution
  • Synchronize the interface at the beginning and the end of any iterating loop in the algorithm
  • Fully handshake all interface accesses

Suddenly this is not looking so easy. If I was designing the old way I would have to create a buffer array, set up a bunch of pointer variables, make complicated address assignments to keep everything pointing to the right place, keep track of where I was in the memory to handle that circular wraparound requirement, and harness all reads and writes with some kind of ready/valid handshake. Sigh.

But now I’m using Cynthesizer. Here’s what the Interface Editor window looks like for an interface that does exactly what I need:

[Click to enlarge]

Note first I have chosen to create a circular buffer interface because of the wraparound requirement. In the “Reader” and “Writer” sections I can choose the size of the working set on each side of the interface. I need an array of two input values on the writer side and an array of eight output values on the reader side, so you see 2 and 8 in those boxes. Also, the output pointer needs to shift by one when read, so I entered 1 in the “Adjustment” box. Now all that’s left is to define what is transferred over this interface. In the “Parameter” section I’ve specified a sc_uint datatype, which is the SystemC standard for an unsigned integer, and given it a width of 16 in the “#Bits” box. Then I sized a “1D”, 1024-word buffer for the needed internal storage. Finally, I specify RAM2 as the memory part I want the interface to use to implement the buffer. I created RAM2 myself previously using Cynthesizer’s Memory Editor window. Please read Part II of this blog series for information on creating memories. I saved my interface as a part named my_if.
So “my_if” now exists as an interface part in my library. Let’s put it to good use in an algorithm that does something like this:

My module DUT needs to do the following:

  • Read an input port din, calculate two values and put them in the interface. I’ll create a thread called writer() to do this.
  • Get eight values from the interface, make a calculation with them, and write the result of that calculation to an output port dout. I’ll create a thread called reader() to do this.

First, I have to define a DUT module, declare the ports and threads and instantiate my interface:

SC_MODULE( dut ) {
    cynw_p2p< sc_uint<16> >::in		din;
    cynw_p2p< sc_uint<16> >::out	dout;
    my_if::direct<>	 		m_if;
    …
    void writer();
    void reader();
    …
    SC_THREAD( writer, clk.pos() );
    SC_THREAD( reader, clk.pos() );
}

In red I show an instance of my_if using the ::direct<> template class. This is one of the member classes in my_if, and it is used to represent an internal interface communicating directly between two threads. Conversely, there is a ::chan<> class to use when the interface is external and communicates between two modules.

Now in the DUT module we’ll define the writer() and reader() threads to interact with the interface.

void writer()
{
    …
    m_if.w_start_tx();
    // 512 gets (working set of 2; fills 1024 length buffer)
    for( int i=0; i < (1024/2); i++ ) {
        m_if.w_start_iter();
        vin = din.get();
        m_if[i*2] = vin;
        m_if[i*2+1] = vin+1;
        m_if.w_end_iter();
    }
    m_if.w_end_tx();
}
void reader()
{
    …
    m_if.r_start_tx();
    // 1016 puts (working set of 8 with read adjustment of 1)
    for( int i = 0; i < (1024-8)+1; i++ )
        m_if.r_start_iter();
        v1 = m_if[j];
        v2 = m_if[j*8-1];
        val = (v1 + v2)/2;
        dout.put( val );
        m_if.r_end_iter();
    }
    m_if.r_end_tx();
}

That’s it.  I’m done.

In red I have highlighted some more of the transaction-level member functions that save me a lot of time and keep my algorithm at a high level. They are:

  • w_start_tx(), w_end_tx()
    • Synchronizes the algorithm on the writing side of the interface
  • r_start_tx(), r_end_tx()
    • Synchronizes the algorithm on the reading side of the interface
  • w_start_iter(), w_end_iter()
    • Synchronizes a loop iteration on the writing side of the interface
  • r_start_iter(), r_end_iter()
    • Synchronizes a loop iteration on the reading side of the interface

So with the Interface Generator I defined a few parameters and instantly had a SystemC interface part loaded with powerful classes and functions, and using them I was able to describe the algorithm at the transaction level in just 58 lines. This same design in RTL would have taken well over 4600 lines!

Next time, we’ll conclude our series on modular interfaces with some final suggestions of things you should consider.

Modular Interfaces Part II: External Memories

In the opening entry of this series, we introduced modular interfaces and talked about their importance in high-level synthesis (HLS). We touched on the ways that other HLS tools force you to create interfaces–with limiting approaches like ANSI C or off-the-shelf IP–and contrasted that against the strengths of our Cynthesizer tool. By designing with Cynthesizer using SystemC, we showed examples of how the verification, standardization and customization of interfaces is all made easier.

The second part of our series on modular interfaces deals with external memories. It’s unavoidable when you’re designing at an abstract level–at some point you’re going to need a memory. High level algorithms, by nature, make extensive use of loops that operate on arrayed datatypes. Not all HLS tools handle external memories well.  With some you have to schedule the memory interface by hand!  There are several different ways that Cynthesizer can implement those arrays for you, but it is when they become external memories that Cynthesizer’s modularity really shines.

Arrays In HLS
Let’s say you have an array in your design, maybe something like this:

sc_uint<16> mem[16];
…
for ( int i = 0; i < 16; i++)
{
    acc = acc + coeff * mem[i];
}

What can you do with it? Well, in Cynthesizer there are three things you can do. You can:

  • Flatten it
    • Using a directive or command-line switch, Cynthesizer will flatten the array into individual registers. This is helpful if you want a short latency—your architecture will have access to all array locations in the fewest possible cycles.
  • Make it an internal memory
    • Using Cynthesizer’s Memory Model Editor, you can create a memory model that Cynthesizer will allocate to store your array. This is good if you have a few extra cycles to spare and don’t want the added muxing of a flattened architecture.
  • Make it an external memory
    • Using the same memory model, you can instruct Cynthesizer to implement the memory externally.  Cynthesizer will synthesize an interface to this memory for you. You will not have to worry about controlling the address, data or enable ports.

It is the ease of making a memory external (and the lack of changes required to your SystemC source code) that we will get into now.

Going External
So you want your array to be an external memory? First thing you need to do is build it. To do that you can invoke the Memory Model Editor in the Cynthesizer Workbench GUI. Here’s what it looks like:

[Click to enlarge]

There’s actually not that much you have to do here. We set “Word Size:” and “Number of Words:” both to 16 to match our array’s size and indices. The “Latency:” is 1 by default, and the “Setup time:” and “Output Delay:” should be a nonzero time value based on the data from your technology library. And since this memory will be external, the “Area:” is 0.

By default this will be a single-port memory. If you want something different you can click the “Ports” tab, where you can increase the number of ports, edit the names of the address and data lines, specify any enable lines or masking, associate each port with a clock or reset, and configure the ports as read-only, write-only or both.

But the real power for us is in the “Internal memories” and “External memories” boxes where you can specify chaining or registering of the memory I/O. That’s right, the SystemC memory model we create will be usable as either an internal or external memory.

So once we’ve generated the memory model (I called it “mem_part”), how do we use it? All you have to do is turn your array declaration into a memory port instantiation. Previously we had this:

sc_uint<16> mem[16];

now we have this:

mem_part::port<ioConfig, sc_uint<16> >  mem;

port<> is a templated class in the generated SystemC memory model that represents an external port connection. Its arguments are the I/O configuration, which can be defined for TLM or pin-level simulation, and its datatype. The memory model will also have to be connected to clock and reset but there are high-level functions available to do that.  Why, you ask, do we have to do all this?  Chances are you chose an external memory because it needs to be shared with other modules.  The classes like port<> make it possible to accurately simulate intermodule communication through a shared memory at the behavioral level.  With other tools that use ANSI C or don’t have customizable interfaces, you have to wait till you have RTL to verify anything like this.

What do you have to do to the source code? Well, nothing:

for ( int i = 0; i < 16; i++)
{
    acc = acc + coeff * mem[i];
}

The array access looks exactly the same as before. Cynthesizer knows to associate your array access with an external memory port, and it schedules the interface automatically based on your latency constraints.  The external memory has become a truly modular interface, and it was all created for you. If you generate RTL for this design you will see the synthesized interface in the port list:

module dut(clock, RSTN, inp_busy, inp_vld, inp_data, outp_busy,
           outp_vld, outp_data, mem_WE0, mem_DINw, mem_DOUTw,
           mem_Aw, mem_REQ0);
  input clock;
  input RSTN;
  …
  input [15:0] mem_DOUTw;
  output mem_WE0;
  reg mem_WE0;
  output [15:0] mem_DINw;
  output [3:0] mem_Aw;
  reg [3:0] mem_Aw;
  output mem_REQ0;
  …

Next time, we’ll take a look at the techniques used to build custom modular interfaces using Cynthesizer’s Interface Editor.

Modular Interfaces Part I: Benefits

High-level synthesis (HLS) is just that–high level–a design approach that lets you work at a level above having to wade through pins and wires and state machines. There are many factors to consider in choosing an HLS tool, but one of them is so fundamental that it often gets overlooked.

It’s interfaces. I’m not just talking about declaring ports and hooking them up. I’m talking about high-level, modular interfaces that encapsulate very complex I/O protocols into easy-to-use function calls. Most of the tools out there offer some kind of interface solution, but we think they miss the mark in giving you what you need to be successful. Some let you describe I/O behavior with standard ANSI C only to add the actual pin-level interface details later in synthesis (which, unfortunately, will be the first time you can actually verify the interface). Some offer only off-the-shelf interface IP but then provide no means of creating custom interfaces. We developed Cynthesizer with all of this in mind. Cynthesizer designs are written in SystemC, where the clock and pin level activity of an interface can be simulated before the tool is run. And Cynthesizer has a family of standard interface IP in addition to an editor where you can create any interface you want.

This is the first in a four-part series on designing and working with modular interfaces in Cynthesizer. Today I’ll be detailing the benefits of modular interfaces. In the coming weeks we’ll be talking about how useful they are with external memories, we’ll detail some of the techniques we use to build them, and we’ll show what exactly is available interface-wise from Forte.

What Is A Modular Interface?
When we talk to customers or prospects we use the word “transaction” a lot. And this is probably the best word to use in describing a modular interface. A transaction, in essence, is what is being communicated across a modular interface. A modular interface can be, for example, a burst write to a standard AHB bus model. Or it can be an exchange of data that follows a strict protocol in a fixed number of clock cycles. Or it can simply be the writing of a vector or datatype value with ready/valid handshaking. The modular interface combines the I/O protocol of your transaction (i.e. ports) with the actual functionality of the transaction. Whatever the case, to you as a user it is a single function call alongside your other high-level code.

Why Use Them?
There are many benefits to designing this way. Your code is much simpler and you can describe an algorithm in fewer total lines. Your design effort can concentrate solely on the core of the algorithm at transaction level, all while retaining the flexibility to write custom interface protocols. Your connections become easier because all the pins involved in the interfaces are encapsulated in high-level channels. But the real benefit is in verification. Since handshaking is built into a modular interface, all you need is one testbench to verify all of the RTL architectures your HLS tool produces. Also, as mentioned above, Cynthesizer interfaces correctly simulate the interaction of their clocks and pins at the behavioral level, before you run any synthesis. Remember that SystemC supports both TLM and pin-level I/O configurations. We can’t state enough how critical this is to your HLS success–once your interface is verified behaviorally, it stays verified all the way down to gates or anywhere you reuse it.

Without modular interfaces you would spend a lot of time down in the trenches of I/O protocol design. You would have to declare whatever ports are needed for your transaction, make sure the direction of the ports was correct, declare signals in the parent module to connect them with, and then make sure all the connections are correct. But then comes the hard part, writing some kind of handshaking or acknowledgement scheme so that you only read input data when it is valid and only write output data when the downstream module is ready for it. This means an manual assertion of a ready signal, followed by a loop that sits and waits on a valid signal, followed by reading the data and storing it properly. And remember, you will repeat this for every interface you have.

Just look at the difference of this code with modular interfaces:

in_data = inp.get();
out_data = my_function( in_data );
outp.put( out_data );

as compared to the same code written without modular interfaces:

inp_rdy = 1;
do {
    wait();
} while( !inp_vld );
in_data = inp.read();
inp_rdy = 0;
out_data = my_function( in_data );
do {
    wait();
} while( !outp_rdy );
outp.write( out_data );
outp_vld = 1;
wait();
outp_vld = 0;

And this is only for a basic ready/valid handshake. As the interface becomes more complex, the difference in the amount of code becomes more dramatic.

How Does SystemC Help?
We’ve touched on it already, but SystemC really lends itself to modular interface design. A SystemC modular interface has two sides: a tidy, transaction-level side like the .get() and .put() calls you see above; and a rougher, pin-level side where the gritty details of the cycle-accurate protocol are defined. Some people criticize SystemC because the OSCI synthesizable subset requires modules to have pin-level ports like sc_in<> and sc_out<>, but in this case it’s an advantage. While you as a designer work at a high level, it is the pin-level ports that are presented to your HLS tool. With the pins broken out, the tool can more optimally combine your interface protocol and datapath with the control FSM. Using modular interfaces does not mean sacrificing quality or reusability.

Next time, we’ll get into designing with external memories–a specific case where modular interfaces save loads of time and effort.

SystemC Hits A High Note

Two weeks ago in Yokohama, several companies hosted SystemC 2010 Japan. Over 200 design and verification engineers, architecture and algorithm engineers, EDA specialists, managers, and software designers attended the event. Presentation were made by EDA vendors and users alike, with leading companies like Renesas, Ricoh, and Sony discussing their experiences with SystemC, ESL and high-level synthesis. By all reports it was a great success (on a scale of 1 to 5, almost 75% of the attendees gave the seminar a rating of 4 or 5!) and speaks to the continued momentum that SystemC has in the market.

In a survey, 65% of the attendees said they have used or are now using SystemC and SystemC tools in their current flow. More than 52% said that they are using high-level synthesis (HLS) — the most of any category. So what does all of this tell us?

Well, it’s clear that SystemC and SystemC HLS have moved well beyond the trial phase. Some of the most respected companies in the world were discussing their methodologies in use today and their vision for the next couple of years. The user community for SystemC design is now setting the direction. Japan has been a leader in SystemC HLS since 2000, and the attendees made it clear they intend to continue the push forward.

Why SystemC?
This is a question that never seems to get old.  Maybe it’s because for years EDA marketeers have told us ANSI-C is all you’ll ever need! The fact is that ANSI-C cannot handle real design and verification needs and the designers in Japan know it. Those surveyed at SystemC 2010 Japan said their SystemC usage falls into these 5 categories (multiple answers allowed):

  • 52.7% HLS
  • 44.8% Functional verification
  • 33.5% Virtual platform / software design
  • 30.5% Architecture design
  • 1.5% Other

So why use SystemC instead of ANSI-C? It’s true that ANSI-C and SystemC can both be synthesized, but that’s not where the problem lies. The problem is in the modeling and design environment that you need to build. Sure you can synthesize a serial algorithm in ANSI-C — but real designs have hierarchy, concurrency, control and complex interfaces where data is exchanged in parallel. What about modeling a virtual platform and the design architecture? You could add non-standard language extensions or develop your own event manager (effectively creating a custom simulator), but is that what you want to spend your time doing? Let’s face it — ANSI-C just doesn’t cut it. SystemC was developed specifically to rectify ANSI-C’s shortcomings for hardware design.

SystemC is a C++ class library that is “hardware aware,” and there’s a lot of online material to help you learn about its advantages. Forte’s CTO, John Sanguinetti, has written a couple of articles about the topic. I’d recommend reading “Transitioning from C/C++ to SystemC in high-level design” that appeared recently at Embedded.com, as well as “I can’t imagine designing hardware in C…” that appeared right here in Forte’s CynCity blog. Read these and you’ll see why ANSI-C doesn’t work for anything more than trivial hardware design.

Want more? There was a panel about it at DAC this year! And while they probably won’t admit it, even the EDA vendors who trashed SystemC a year ago are starting to sing a different tune.