How do you handle the skepticism?
The only way you handle it in this industry is by demonstration and by customer reference. You go to a customer and they say “Who else is using it?” You say “The guy down the street is using it.” If the guy down the street is across the Pacific, it has much less impact on this side of the Pacific than it does over there. Most of our business is actually in Japan. That is where our original customers were. Because of word of mouth, we have quite a number of Japanese customers. That did not translate over to the US. The Japanese customers don’t really talk abut their experiences and it is much harder to get them to write about it. In the US the way we will establish our presence here is the same way. We will get a customer to be successful, reference that customer to the next guy and it will go on from there.
If your company had developed a SPICE simulator that ran 10x faster than current competition, it would be fairly easy to demonstrate. Take a SPICE deck, run it and compare the output. With your product how much time and effort does it take you to convince the prospect that the product does what you claim.
That’s a big problem. You go to a customer and say “You should really not write your design at the Verilog RTL level. You should be wiring at a higher level in SystemC.” They say “I don’t have SystemC code. I can not test yours out. I do not trust you to give me some SystemC code and run your product on it. I know it is going to work. You are not going to show me something that doesn’t work.” The evaluation process can be very long. Typically, what happens is a customer with no SystemC code to start with will take a fairly small piece of RTL that they have already done in Verilog and rewrite it in SystemC, synthesize that and see if they get the same result as when they did it by hand. That is a kind of okay experiment. But it does not expose the real difficulties of higher level synthesis because they do just one block. The problem comes when you do multiple blocks that have to talk to each other. In particular, the choice of language. Right now you have several vendors out there saying that they will synthesize from C instead of SystemC. We do it from SystemC because you can represent those interfaces. With C you can not. If you just do one block, it is irrelevant. You do not see the difference between the two approaches. It’s a problem. It is one of the things we identified early on. We said we are going to use make this synthesizer product but if there is no SystemC code to synthesize, then we are not going to have any market, and we are not going to be able to sell any. So, actually in the early days of the company, we spent considerable effort creating this SystemC environment. It was not SystemC then, it was called Cynlib. We tried to create a design ecosystem so you could actually do design in SystemC. Fortunately, a lot of other people started doing that. That is why we stopped those efforts because you had CoWare and Synopsys and a whole bunch of smaller people coming out with products supporting modeling activities in SystemC. Now there is a lot of SystemC code that is used for architectural modeling, not so much for implementation, but these models can be turned into implementation models without too much difficulty. We sometimes see now, in fact fairly often, in evaluations that a company has a body of SystemC code and they can take some of that and use it as a test case.
Who do you see as Forte’s competition?
Mentor is our primary competition and has been for the last couple of years. They use C as the input language and we use SystemC. That is a big differentiating factor. We tend to be stronger in companies that are producing ASICs where as Mentor tends to be stronger with companies producing FPGAs. FPGAs often have a smaller number of blocks in the design. So the interactions are not so important, the interfaces are not so important. They have been the primary competitor the last two years. Cadence has announced a product CtoS which is much more aligned philosophically to us. They are taking the same approach. Their product is just now getting to market. It really has not been competition yet but we expect that it will be because they took the right approach.
How big a firm is Forte?
We are about 30 people. We’re kind of a geographically dispersed company. We have people in a lot of different places. Our engineering is done in three or four places. The bulk is in Pittsburg. Some of it is in Redmond, Washington. We have people in Texas and Massachusetts and also in France, Japan and Korea.
How about Forte’s revenue stream?
We do not divulge our revenue but we were up 155% in 2008 over 2007. We will be up a little bit more than that in 2009. We have survived the downturn pretty well.
Are your sales direct or through distributors?
Direct. We do not have distributors. We have sales offices in Shin-Yokohama and Seoul. We have a direct sales team in France. Our VP of Sales is in Boston.
Have there been any recent product announcements?
We had a new release in May, labeled 3.6. That had a significant new feature. It is called Interface Generation. It is a means of generating code that will do fairly sophisticated interfacing things like line buffers. If you need to take a stream of data and operate on it in some organized fashion like a 5x5 matrix where every cycle a new pixel comes to replace one of the pixels in the matrix, the algorithm written in C is really very straight forward, a double loop. But if you write in RTL, it is pretty complicated because you do not stick the whole frame in memory and operate on it. You have to stream it in. Getting that streaming right using a minimum amount of storage is a difficult one. It is a tedious problem. It is one we can automate. That is the feature we have added but overall the significance of new releases is really product maturity.
Over the next year to year and a half, do you see anything new on the horizon?
I think the big issue that we have heard a lot about from people like Gary Smith and a lot of people who comment in this area is the difference between doing control dominated design and data path dominated design. We have been handling control dominated design for a long time, at least a couple of years basically as a result of the demand from our customers. That has really come to fruition over the last year or so. You can do something that looks like traditional control dominated design with our Cynthesizer without any real difficulty. Over the next year to two years, there is really going to be more optimization of all of those capabilities. It is kind of like Design Complier. If you compare Design Compiler from 1992 to 1998, what did they add? They added thousands of little things but not one big thing. That is the way this has gone. One thing we might see but we do not have any specific plans to do this, is that if we get the opportunity we will develop IP at a higher level. At this point we have fixed point classes, floating point classes and some interface classes that are relatively robust and pretty useful. We will probably see more of that sort of thing. We have an AMBA bus interface. You will see more of these interfaces that we can provide to the customer in SystemC at a higher level that can be synthesized and that they can use in their designs. I would anticipate that.
Having worked for a Japanese company I am sympathetic that you have had difficulty getting Japanese customers to endorse the product.
If you go by our booth, you will see one wall with quotes from Japanese customers. We have gotten endorsement at least at the level when they say nice things about us. What really counts is an engineer writing a white paper or writing to Cooley that these are all the things I did. These are the characteristics of the design and this is how the tool works. For a lot of reasons Japanese engineers are not going to do that. Part of it is that they would be working in a second language. You can not expect a guy who speaks primarily Japanese to write a paper in English