Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Get email delivery of the Cadence blog featured here
An obvious criticism of my previous post
for the Skilled: Making Programs Clear and Concise is
that clarity is subjective. What is clear to one person may be
confusing to someone else, especially to someone who is accustomed to
doing things the hard way.
I'd also suggest the converse is also true. If you are
accustomed to using a programming language that encourages an
imperative style, you may become convinced that more confusing code
Several readers of this blog referred me back to an iconic author in
the field of computer science, Peter
Norvig. The book Paradigms
of Artificial Intelligence Programming is a good resource as a
survey of many different non-trivial but easy to understand
programming problems. The book is almost 1,000 pages and belongs on
every SKILL programmer's bookshelf. The name of the book is generally
agreed to be misleading as it turns out not to be much about
artificial intelligence, but rather about programming style.
Norvig also presents a nice test for clarity in his presentation
called a Tutorial on Good
Lisp Programming Style. The rule can be found on pages 53 and 54
of that set of slides.
From this description the implication seems to be that the smaller
the difference detected when comparing 1 and 3, the better job you have
done at writing a clear and concise program.
Let's use SKILL as an example rather than Common Lisp as Norvig does.
Suppose we want to write a SKILL program to do some analysis of the
instances in a layout cellView.
Start with an English description of the algorithm
Given a list of shapes and a layer name, find the subset of shapes on
First attempted implementation
The following implementation is an imperative approach. The reader
sees how the calculation occurs but has to think a while to figure out
exactly what is being calculated.
(defun shapes_on_layer (shapes layerName) (let (stack) (foreach shape shapes (when (shape~>layerName == layerName) (push shape stack))) stack))
Translate the code back into English
Given a list of shapes and a layer name, start by initializing an
empty stack, iterate over the shapes. If the shape is on the given
layer, push it onto a stack; when finished iterating return the
elements on the stack.
More clear and concise implementation
This implementation reads very easily, and it is clear to the reader
what is being calculated.
(defun shapes_on_layer (shapes layerName) (setof shape shapes (shape~>layerName == layerName)))
Translate the code back into English
We can see that when translated back to English, the second of the two
implementations looks much more like the original problem statement.
Of course there are exceptions to every rule (except perhaps this
one). Sometimes we must sacrifice clarity for efficiency--particularly
if the programming language is not as high level as SKILL. If you
find the programming language you are using tends to more often force
you to write code in the style of the first two examples, rather than
the second, you should conclude that the strength of your programming
language is NOT its clarity and expressiveness.
Incidentally, I tested the two implementations above on my Linux
laptop to see which one is actually faster. I tested both the
imperative and functional style implementations on a cellView
containing 32,768 shapes, 20,480 of which are on "Poly" layer. The more
concise functional style implementation found the "Poly" subset about
7% faster than the imperative style implementation. In this case
there was no run time performance penalty for clarity.
The SKILL programming language allows you to write very expressive
Hi Nazia, I'm glad you liked the article. There are plenty more to come.
nice article about the translation i really like this and i hope that every one will like this
thanks to share with us
Hi Kari, many thanks. I'm happy that you find the advise useful. I hope you're able to find the other references I mentioned. I'll try to include more examples from Norvig (and others) in upcoming articles.
Great article. I often start my programs with an English description, but have never thought of translating the code back to English to check the clarity. I like it!