August 31, 2009
Like Father Like Son
Please note that contributed articles, blog entries, and comments posted on are the views and opinion of the author and do not necessarily represent the views and opinions of the management and staff of Internet Business Systems and its subsidiary web-sites.
Jack Horgan - Contributing Editor

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

We brought along a couple of concepts from HDL, the idea that a single component with a direct pinout, pin accurate model, can have multiple models at different levels of abstraction. RHBD architecture, VHDL configurations is how you specify which models should use which architecture; mix and match, change accuracy, simulation speed and do it very simply through a single tool. Digital assertions are something that has been around for a while but we borrowed the concept and now have analog assertions. So we put these little pieces of code into the model graphically and observe analog behavior. The mode can react to a failure by stopping the simulation. So doing for example Monte Carlo, I
can stop a simulation because it failed. Assertions make the approach to modeling a lot faster.

Now there is a novel concept in the way that you create these models. That is the use of what we call effects. These effects are little pieces of code that are defined as graphical icons. This is the language of the analog engineer. I can drag an icon, a symbol, onto the surface and some code comes with it. The user does not see it but the user creates a recognizable circuit and interconnects it. Then, when it is time to generate the model, it takes care making the correct variable names and putting it in the correct order. This is how we connect the models together. The way it works, the tool has a number of navigators; library navigator and individual model navigator. It also has a
symbol editor and the topology canvas where I connect together these little snippets of code. It looks to an engineer like blocks they understand. But, of course, there is access to a hardware description language by writing code and having declaration tables. When the model is finally all done, I can choose a plug-in to a single simulator with a button and a very simple menu to generate the simulation results from any number of simulators.

I forgot to say (I always seem to forget this), we have an integrated modeling environment. We do not have a simulator. We do not provide a simulator. We rely on third party and partner simulators. Today, we support probably 10 different simulators from Cadence, Mentor Graphics, Synopsys, Ansoft … Even the display comes up in the target environment. This display was generated using Cadence Spector. So it came up as a wave scan. This is kind of an architecture picture of what we just saw. The database is an XML-based data base. The libraries themselves are written in the same language. Our users will be creating their own libraries. Many of the large companies have their own secret sauce which they want to put in. We believe that it is going to be design engineers that take the snippets that are written by their experts. So a company may have one or two experts, who today are frantically running around building models for people. They are very excited about these capabilities. Users can build their own libraries. The model has all the information in it. As I pointed out, when you decide to simulate, we export it to a particular dialect of one of these languages. The dialects are important because different simulators have different quirks, different bugs. We make sure that the libraries work around those bugs. When people have existing models, they can import
them into the system. The benefits for the individual, for the team, and ultimately for the customer include: ease of use, graphical editing language, ease of sharing simulation specifications. We can go all the way to executing the specification, where the customer and the manufacturer can interchange the data on what they want to have built.

Some of our original funding came from SBIR and BAA. One of the chips we built here using these tools and approaches is on the Space Station today. We provide rad hard services and technology services. We have automotive and semiconductor manufacturing customers. Now that the integrated modeling environment itself is stable, our future focus is going to be adding features. That is what happens in these environments. Our focus is on toolkits, additional libraries, simulator plug-ins and possibly language specific skins when we target the modeling environment to a particular language such as HDL.

Let me show a little bit of what it looks like. This is a demo of our Simulink emulation toolkit. As I mentioned earlier, the information exchanged around the interconnections are the signal flows. This looks just like a Simulink picture but the individual components have those little pieces of code behind them. When I finally export to one of the languages, I can have a VHDL model (fairly length ~65 pages of code), Verilog or MAST. I can drill down into one of these components. Some of them have code behind them while others have other models behind them. This particular one, a second order filter, has a couple of integration steps. This again is in Simulink

style diagram of a block. Using different architectures, we also have the same model in electrical components RLCs. Eventually, you can imagine replacing these components by active networks, op amps, all the way down to transistors. That is the depth of the decomposition process.

Back at the original level I now have a way to look at the results. If I provide stimulus to it, I can simulate this in one of many different simulators. We have three setups here: Verilog, VHDL and MAST. These are done as by what we call plug-ins that are external components to the system. They are written in the Python language. We can easily access simulators. Customers can add access to their own private simulators. Some of the larger customers do have that. In addition to that, the person designing the circuit who wants to share it with somebody can set up the simulation right in this environment and send to them. They can then go and look at the results. The simulation is one
button through a menu. When this happens, the circuit gets exported to the simulator. The results are brought up in the viewer. The idea behind the event driven mixed-signal toolkit, the one that is 1,000 times faster than an individual simulator, is the same concept. People will just compose their system from a different library.

Are there any other companies out there doing what Lynguent is doing?

I know of no other company that has anything like it in the modeling space.

Whether it is Lego blocks or Lincoln logs, the challenge to model builder is a function of the breath and variety of the individual components. If you need a certain widget for the model and you do not have that widget, you are stuck. Somebody has to go off and create the missing widget.

Yes! But at least it is possible to do that using the same tool.

How do you keep up with the pace of technology? If you had a totally comprehensive library today, it would have gaps six months from now.

Let’s look at Simulink. It has been at this level for years and is still very applicable. I side stepped the question. It is very valid you asked. I think that there will be two ways that this will work for us. One way is that the customers who are designing new things are likely to be the large companies who need to have modeling departments. They will be doing those blocks for themselves. That does not help us. But, there is the idea that we will be supporting and have already started supporting independent third parties that will develop these models. We have a person who does AMS modeling. He has written books on the subject and has his own little business. He will be
creating these libraries and publishing them; maybe selling them or maybe providing open source. You are entirely correct that there are a large number of components. The new toolkits we plan to write is our future direction.

This is a sigma-delta converter. Right now we have one sigma-delta converter written in the Simulink style. What we will be doing is creating toolkits so that I will have a sigma-delta converter that is going to be written in several different styles in our methodology but also in different architectures (different ways of doing these blocks). We will have several of these in toolkits. We do not expect people will use them directly but this will form the basis for modification. Almost all designs in the end are done by modifying what you have done before. The new toolkit will have for example 30 different ways of doing op amps. People will have the ability to
make small tweaks, changes to them.

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

You can find the full EDACafe event calendar here.

To read more news, click here.

-- Jack Horgan, Contributing Editor.

Review Article Be the first to review this article

Featured Video
Peggy AycinenaWhat Would Joe Do?
by Peggy Aycinena
Simon Davidmann: A re-energized Imperas Tutorial at DAC
More Editorial  
Senior Front-End RTL Design AE for EDA Careers at San Jose, CA
DDR 3-4-5 Developer with VIP for EDA Careers at San Jose, CA
LVS for PDK Design Engineer SILICON VALLEY for EDA Careers at San Jose, CA
Upcoming Events
11th International Conference on Verification and Evaluation of Computer and Communication Systems at 1455 DeMaisonneuve W. EV05.139 Montreal Quebec Canada - Aug 24 - 25, 2017
DVCon India 2017, Sept 14 - 15, 2017 at The Leela Palace Bengalore India - Sep 14 - 15, 2017
SMTA International 2017 at Rosemont IL - Sep 17 - 21, 2017
S2C: FPGA Base prototyping- Download white paper

Internet Business Systems © 2017 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy