This article describes how to set up Japanese text input with Fedora 12.  I’ve used Japanese text input since RHEL 3, and now multilingual text input even easier. An earlier, similar article describes Japanese text input on Fedora 11.

Japanese test display works by default. The new fonts in Fedora 12 are beautiful. If a Japanese language web site does not display properly in Firefox, try adjusting the encoding with View > Character Encoding > Japanese(EUC-JP) or View > Character Encoding > More Encodings > East Asian > Japanese (Shift-JIS) .

For information on how to install Japanese language input on other Linux distributions and other Fedora versions, see Scott Robbins’ authoritative guide, Inputting Japanese text in Linux and some BSDs. I have invited Scott to add this text to his guide when he gets the chance.

Installing the Input Method

Start by installing Japanese input method packages:

yum install scim-lang-japanese

Then, set up your preferences with System > Preferences > Input Method. This will bring up the IM Chooser dialog:

• Select Use IBus
• Click on Input Method Preferences, and choose the Input Method tab. From the Select an input method list, choose Japanese > Anthy, and click Add.
• Similarly choose and Add the other languages you want to input.  I added Chinese-Pinyin, and it works great.
• Use the Up and Down buttons to arrange the order in which the languages appear when you hit the Alt+Shift_L hot key.  You will want to place the language you use most at the top of the list.
• If you are the first user on the machine to enable IBus,
  • Save your unsaved work in other applications and select Log Out
  • Log in again
• If another user has previously enabled IBus on this machine, you will not need to log out.  Just select Close.

Now give it a try:

• Put your cursor in a text entry window that handles international input.  A text entry field on a web page or an OpenOffice document can do this.
• Hit Ctrl+Space to switch from English to the first input method (Japanese in my case).  A small window will appear in the lower right corner of your display. You use this to control the input method.
• Type something in Japanese
• If you added another input method, hit the Alt+Shift_L hot key. Now you can type in the second language (Chinese-Pinyin for me).
• Return to English input with Ctrl+Space

At last I can directly express in Chinese how good IBus is, 非常好, instead of entering how much I like it in Japanese, 非常に好きです, and then editing it into Chinese.

Changing Your User Language

If you really want to go native, add the following to the .bash_profile file in your home directory:

export LANG=ja_JP.UTF-8   # Read the warning below first


Log out and log in again, and everything is in Japanese.

Don’t try this at home unless you can actually read Japanese. In particular, you will be asked if you want to change your file names to Japanese. Give the wrong answer, and your Desktop/ directory will be renamed デスクトップ/. Are you already staring at the dialog that is threatening to do this? Select 古い名前のままにする(K) to keep your current file names.

Changing the Locale

The locale is a big subject, but the most useful setting I have found is the LC_CTYPE environment variable, because it changes the formatting of dates and currency values in OpenOffice. This may be useful if you live in Japan, but prefer to use Linux in English. In the .bash_profile file in your home directory, add the following :

export LC_CTYPE=ja_JP.UTF-8

Log out and log in again, and everything is in English, assuming LANG is no longer set to ja_JP.UTF-8. Open a spreadsheet with Applications > Office > OpenOffice.org Calc. Choose Format > Cells, choose the Numbers tab, and you can see that the Language has changed to Japanese, and the choices for date and currency formats are those customary in Japan.

gwaei Japanese-English Dictionary

Now that you can type both Japanese and English, you will want a dictionary. The gwaei Japanese-English dictionary for Linux works great with Fedora 12.

Note that the gwaei i386 RPM will not work with x86_64 Fedora 12. If you installed the x86_64 version of Fedora 12, just compile gwaei as explained in the installation instructions.

This post also appears as a guest blog on Cadence’s Digital Implementation Community.

In an earlier series of posts, I described techniques that will make your chip design flow easy to use. I subsequently had the pleasure of using a flow that employed most of my favorite techniques—the Cadence Encounter Foundation Flow version 8.1.

The focus of this flow is to get you up and running immediately. Plug in your libraries, netlist, timing constraints, do some floorplanning, create a clock tree specification file, type make, and something comes out the other end. Not a usable chip of course, but something, so you can see what’s next. A flow is executable documentation, and this is your Quick Start Guide.

The Encounter Foundation Flow does not try to be everything to everybody, but rather the portion of the design flow that is common to everybody. It can be difficult to decide how far to go with such a flow, but Cadence engineers Rob Lipsey and Glenn Gullikson knew where to stop. I found the Encounter Foundation Flow to be a good balance between completeness, extensibility, and usability. It contains no confusing, useless features like GUIs, wrappers, and “under the covers” sleight of hand. The best ASIC designers I know use flows architected like this one.

An additional advantage of any standard flow is that it gets all users to operate the tools in the same way. With versatile tools like place and route, there are many ways to accomplish the same thing. Yet such tools are a minefield of bugs and quirks. When every user chooses a different approach, something bad always happens. A standard flow defines a single safe path for users. It frees the tool developers from having to support a needless variety of ways to accomplish one task.

The make/ Semaphore File Directory

Physical designers who are accustomed to using GNU Make will be at home with the Encounter Foundation Flow. The one thing that you need to be aware of is the location of the target semaphore files in the make/ directory. This is specified in the Makefile with the VPATH variable.

While a separate directory for semaphore files initially seems like a good idea, putting them in the make/ directory causes subtle problems.  You can eliminate this make/ directory by changing,

VPATH=./make

in the Makefile to:

VPATH=.

If you prefer to keep the make/ semaphore file directory, be careful of the following points:

• With the Encounter Foundation Flow, you reset the design flow so that the init target is the most up to date using,

  touch make/init

  but if you forget the directory name and mistakenly type,

  touch init     # wrong

  the flow forever thinks that only the init target is up to date; every time you run, the flow starts over. I burned up a lot of CPU time until I discovered that the culprit was the ./init file hiding in my working directory.

• Similarly, do not forget the directory name when you use the make -t option to update the design flow:
  

  make -t make/place

  This can be difficult to remember after becoming accustomed to typing make place.

Suggestions for Improvement

I found several things in Encounter Foundation Flow 8.1.RTM that I think Cadence should consider improving.  As noted below, many are in fact already fixed in later versions of the flow.

• The Makefile clean target deletes the Subversion version control directory .svn:
  

  clean: rm -rf .??*   # ...

  Wildcards in the clean target can easily make a mess. This is fixed in the version 8.1.USR2 cleanup target.

• The Makefile does not make use of the .PHONY target. This is especially useful for the administrative targets like clean and all:
  

  .PHONY: all clean # ...

• The Encounter Foundation Flow puts reports in its own RPT/ directory rather than the tool default. For example, I would prefer that Encounter timing reports go in the Encounter default, timingReports/.
• Lower case is easier to type, so I would prefer lower case names for the LOG/, RPT/, and DBS/ directories. Users can customize these paths using the vars(log_dir), vars(rpt_dir) and vars(dbs_dir) variables in the setup.tcl file.
• In file SCRIPTS/FLOW/run_route.tcl, line 68, the variable setFillerMode is missing for the non-power domain case, but this is fixed in version 8.1.USR2.

Future Direction

In addition to the fixes mentioned above, Rob and Glenn are still enhancing the flow.

Currently the flow executes Tcl scripts that contain procs and variables. In a future version, the flow can first generate linear scripts with all variable values evaluated and all procs expanded into Encounter commands. Then it executes these scripts with Encounter.

In my flows I avoid generating scripts, because it allows the configuration variables and the scripts to become desynchronized. But Glenn and Rob had some good arguments for doing it this way:

• The script stands alone as a record of exactly which commands were executed. To reproduce the step, you (or your AE) need only the starting database and one script file, not the entire flow.
• The flow can be easily tested by merely comparing the scripts against golden scripts, without running Encounter. Testability is a key feature of every software project.

To solve the synchronization problem, I encouraged Rob and Glenn to generate each script within the Make target, immediately before it is used. I’m interested to see how this works out. Make sure to send them your feedback, too.

This post is also published as a guest blog on Paul McLellan’s excellent blog, EDA Grafitti.

I was in my third year of Japanese classes. I dreamed of applying the language at work in Japan, but I had no way to actually make this happen. The American Electronics Association Japan Research Fellowship was the opportunity of a lifetime to realize my goal. I applied, and was accepted. Had the program never found me, my dream would have just quietly faded away.

The fellowship was a full ride: airfare, room and board, tuition at Cornell, and a job as a chip designer at Intel Japan. All of this was a tremendous gift for which I am eternally grateful. Only the power of a major industry association could make something like this happen.

I too was going to pay. This episode of my life was like a card game in which I held a great hand, but nonetheless discarded graduate school, my girlfriend, job, friends and Santa Barbara, retaining only my electronic engineering card. Then I was dealt new cards I could not even recognize. How would I assemble them into a winning hand?

The program started with the Cornell University FALCON Japanese language summer session. This was superb. I was very serious and studied hard. When I started, I had an understanding of Japanese grammar, writing and vocabulary, but I could not really hold a conversation. Just nine weeks later, I could carry on relationships with people entirely in Japanese. I have never learned so much so quickly.

I vividly remember seeing Japan for the first time from the air. All this preparation, and I had never even been there. I hired a taxi and chatted with the driver in Japanese along the way to my destination. Using a new language in country for the first time is the most exhilarating of experiences.

I arrived in Tsukuba, where a tiny apartment awaited me. It had a murphy bed, a basic kitchen, a bathroom and a television, which was to be my language teacher and only friend for quite a while. Still, my private apartment was a palace compared to the barracks provided to the other AEA Japan Research Fellowship participants. Intel even gave me a new Toyota Corona to drive.

My job at Intel Japan was verification and circuit simulation for the 8253 counter/timer portion of a microprocessor. As you might expect, many signals described a count. Engineers and programmers usually abbreviate this common word as “cnt”, but the Japanese designer chose to delete only the “o” in “count”. It made for the most profane RTL and netlist I have ever seen.

Intel Japan is based in Tsukuba, a “Silicon Valley” created artificially by the government. These are the same people who brought you Narita Airport, located an hour away from the city it serves. Tsukuba is in Ibaragi-ken, which is famous for backwardness. The nearest train station was 30 minutes away by car. In Japan, a city without a train station is nowhere. I hated living there, and so did many others. All the foreigners at Intel Japan were plotting their escape to Tokyo. Some Tsukuba residents escaped in a more tragic way. The suicide rate was so high that Tsukuba had its own trademark method of suicide–Tsukuba diving, throwing oneself off Tsukuba Tower.

Instead, I threw myself into improving my language skills, the goal for which I had sacrificed so much. This meant using exclusively Japanese. It also meant extreme isolation, as I was not a particularly engaging conversationalist. Still, I was good enough to carry out my duties at Intel in Japanese, speaking English only to my boss (a wise compromise). In an EE Times interview I declared, “I’m known as hardcore about not speaking English in the office. I am definitely looking at getting very good at Japanese.” Ah, such youthful bravado. Hardcore indeed.

My colleagues at Intel were more sophisticated than the locals, and they were kind to me. In the winter, we went skiing almost every weekend. I made some good friends at Intel Japan. After about six months, the loneliness and culture shock started to subside.

Originally my internship was six months, but I was just starting to get the hang of things, so I extended to one year. Intel Japan was good to me, but they only had engineering work in Tsukuba. As the end of my year came to a close, I conducted a job search, and landed a position in Tokyo. After a few years, I returned to finish graduate school at UCSB, then set out for Japan again. The AEA Japan Research Fellowship had succeeded in its goal of turning me into an engineer who could navigate Japan.

Software applications are supposed to release Acresso FLEXnet (formerly Macrovision FLEXlm) licenses when they exit. On rare occasion they forget.

The simplest solution is to stop and restart the lmgrd server (lmreread is insufficient). If you cannot do this, use the lmremove command to release licenses so you can use them again.

For example, Cadence SoC Encounter on Linux once failed to release its license. The next time I tried to start it, I got the message,

> velocity
Checking out Encounter license …
License checkout failed: ERROR (LMF-02018): License call failed for feature NanoRoute_Ultra, version 8.100 and quantity 1. The license server search path is defined as 5280@poser. The FLEXnet error message is as follows,
FLEXnet ERROR(-18, 0, 0): License server system does not support this feature.

This was particularly vexing because we did not even have a NanoRoute_Ultra license. Yet earlier, SoC Encounter had been working fine without it.

To release the stuck license, find the license you want to release:

> lmstat -A

License server status: 5280@poser
License file(s) on poser: /usr/local/flexlm/licenses/license.cadence:
…
Users of Encounter_Digital_Impl_Sys_XL: (Total of 1 license issued; Total of 1 license in use)

“Encounter_Digital_Impl_Sys_XL” v8.1, vendor: cdslmd
floating license

john poser.voom.net poser.voom.net:1.0 (v8.100) (poser/5280 574), start Sun 10/04 20:24
…

So, it turns out that the Encounter_Digital_Impl_Sys_XL feature is the problem, not NanoRoute_Ultra. Go figure.

Release this license using the information provided by the lmstat command (the following is a single command):

> lmremove -c /usr/local/flexlm/licenses/license.cadence Encounter_Digital_Impl_Sys_XL john poser.voom.net poser.voom.net:1.0

The FLEXnet End User Licensing Guide is very useful. Strangely, the Acresso web site is the only place you cannot get this manual. So just search the Internet for “FLEXnet End User Licensing Guide”, and take your pick.

If you speak a foreign language, you would naturally like your children to learn it, too. However, look around you, and you will find that only a few children actually become fluent in their parents’ language, and fewer still can read or write it.

We reared a Japanese/English bilingual daughter in the United States. To help you formulate a plan for your own family, I will describe the strategy we used.

Generally, language proficiency depends on the language environment,

1. At home
2. At school
3. In the surrounding social environment

If your child is not exposed to a language in at least two of these environments, it is unlikely that the language will stick.

Our Situation

Early on, my wife and I decided that our children would speak Japanese. Since the two of us already spoke to each other in Japanese, all we had to do was include the rest of the family, and our child could learn Japanese for free. Not quite. As every parent who has attempted this knows, getting your child to learn your language is not free. A sustained, time-consuming effort is required.

We seemed to have succeeded. Our 14 year old daughter speaks both Japanese and English without an accent. She translates manga for her friends at school and on the internet. She just finished reading the Japanese translation of Harry Potter and the Chamber of Secrets. At last she is in flight, applying Japanese for her own purposes and building new skills according to her own priorities.

Insert Your Language Here

Our experience was with Japanese, one of the most complex languages in the world. The written language is fiendishly difficult. Mastering Japanese requires a level of dedication and sacrifice that may not be required with other languages. We Japanese speakers relish our maniacal intensity and stoic suffering.

Still, I believe that most of what we did applies to any foreign language. For the sake of convenience I use “Japanese” and “Japan” in the following text, merely because it is awkward to repeatedly write “your language” and “the region where your language is spoken”. Please just replace “Japanese” and “Japan” with the name of your language and region.

Set a Clear and Worthwhile Goal

You are embarking on a project, and every project needs a clear, measurable goal. Based on my own experience, I propose a goal like this: the child should be able to apply the language for his own purposes, thereby enabling him to build new skills on his own. This is in fact the goal of all education.

In order to be motivated, all participants must see the goal as worthwhile. This is especially true of your child, who holds veto power over the project. You must sell the language to your child. “You will learn 3000 Chinese characters” will not motivate your young child. Going fishing on Uncle’s boat and understanding a favorite TV show will get much more attention. Many of the recommendations that follow are in fact oriented toward convincing your child to embrace Japanese as an obvious and integral part of his life.

The Most Important Factor

The entire family must be dedicated to helping the child learn. The parents must put forth a strong effort. You and your child will have to sacrifice other valuable experiences for the sake of language study, but that’s the way it goes. Tradeoffs are a part of life.

My original casual attitude, “Hey, it’s free so why not teach the kids Japanese?” was entirely optimistic. In reality, the fact that we parents spoke Japanese provided the foundation for success, but only if we resolved to make the effort.

The Preschool Years

The years from birth to kindergarten are very important for language learning. Further, your child’s schedule is simple, so you have the flexibility to provide experiences that would not fit into a busy student’s life.

• Even before the child is born, you and your spouse should carry on your relationship entirely in Japanese. Unfortunately this means that if both parents do not speak fluent Japanese, success is much less likely.
• Speak Japanese to your baby from birth. One day old is too late. Not for the baby, but for you. You must establish an unbroken pattern of speaking only Japanese to your child.
• Take your child to Japan annually to visit family. Cousins are instant friends, grandparents are delightful, and the key to all this fun is the Japanese language. During the preschool years, you are not restricted by a school schedule so you can go when the weather is good and the airfare is cheap.
• In many languages it is common to drop, say, the subject of a sentence. Avoid abbreviations and speak in full sentences.
• Show your child Japanese videos. Even television commercials are instructive. This will expose your child to a variety of speakers with different accents, plus it gives your child something in common with children in Japan.
• Join a play group where the children speak Japanese. When our daughter was young, Japanese mothers and their young children met at a park every day. This was fabulous for everyone.
• Get dual citizenship for your child. I have known several people who do not have the privilege of living where they feel most comfortable because their parents did not bother to just file some forms. Don’t do this to your kid.

The School Years

Once school starts, your son or daughter will have other things to learn. Having conversed mostly in Japanese, your child’s English may not be very good. Our daughter attended an English as a Second Language (ESL) class, and she had an accent in English until about fifth grade.

It will be difficult for you to watch your U.S.born child struggle with English if you are self-conscious about your own English.  Do not worry. Remember how I thought that learning Japanese would be free for my child?  I got it backwards–the English is free.  In an English speaking country, nothing can stop your child from speaking English like a native. The danger is that he will lose his Japanese. You maintain your focus on Japanese.

• To the extent that school schedule and your child’s changing tastes allow, continue the preschool activities listed above
• Be prepared to sacrifice other activities for language study. For example, Japanese study plus team sports can easily be too much.
• Even on brief trips to Japan, Japanese citizens who live in a foreign country are allowed to attend public school (体験入学). This is a wonderful opportunity to make Japanese friends and learn bad words. Many other countries have similar programs.
• Stay calm
• School officials may suggest that you speak English at home. Don’t do it. Teaching English is their job. Your job is to teach Japanese.
• Your child should study some Japanese, even just a little, every day
• Send your child to language school. Be ready for the financial burden. Language school is more important if you want your child to read and write Chinese or Japanese. Learning kanji (漢字) is a huge burden that not every child can bear. You may have to back off on this goal.
• Feel free to discuss English homework in English

Your Child Responds in English

Often the parent-child conversation style devolves into the parent speaking Japanese, and the child responding in English. A couple years of this, and the child merely understands Japanese, but cannot speak it. From what I have seen, it is almost impossible to recover from this situation.

Both my wife and I resolved that this would never be permitted, but to our surprise, it never happened. Since it never happened, I can only guess what we did to avoid it:

• Never accept English sentences in a Japanese conversation. Like anything else in childrearing, consistency is paramount. You get only one chance to refuse: the first time. Exceptions are quotes from English speakers or texts, and the occasional English word.
• The trips to Japan linked Japanese language to pleasant experiences, and exposed our child to a place where Japanese is a natural and obvious part of everyone’s life
• Our daughter is an only child, so we parents control the language spoken at home
• Or it might be something else listed above

Conclusion

Like anything worthwhile, rearing a bilingual child is not easy, nor is it cheap. Success is not assured. Still, if you have the desire to try, by all means do. The worst you can do is give your child a head start on learning your language. Go for it!

This post is dedicated to my wife Miki and daughter Julie, who actually did all the work.

Chip design is an iterative process. The design flow is run repeatedly as it extended and refined into a program that can automatically build the chip. Your flow needs software to make sure that only the necessary steps are executed, in the correct order, on the correct data. Different hierarchical blocks must be constructed similarly yet differently.

This is one of a series of articles on simple, specific techniques that will make your chip design flow easy to use. In this installment, I will explain how to control your chip design flow, and rules to keep it organized. Other articles include,

• Apply the Scientific Method to IC Design Flow
• Write Effective Error Messages
• Properly Name Log Files for EDA Tools
• Give Files in Your IC Design Flow Useful Names

The Power of Names

First, I want to tell you the most effective way to make your flow easy to use and understand: whenever you name something, choose a consistent, informative name. How can something this simple be so important? Look at the value proposition:

• The name will often be the only documentation
• At the very outset, you need to choose a huge number of names. A naming convention will make this easier.
• Names are hard to change. Once chosen, you’re usually stuck with them.
• Good names cost almost nothing. Just pay attention.

File names and step names are closely related, and are explained in another article.

Good variable names for your design flow are the same as good variable names in ordinary software. This means that there is a wealth of information about variable naming conventions on the Internet and in programming books. I like Code Complete, Chapter 11, The Power of Variable Names for its straightforward suggestions. And for how it agrees with me.

I have one additional variable naming convention unique to IC design flow: use names that are legal Verilog identifiers. For variable names, the rules are not at all restrictive:

• Use only letters, numbers, and _
• The first character must be a letter

Yet Verilog is the most restrictive name space in chip design. Except for reserved words (like foreach in TCL), a legal Verilog identifier can be used as a variable name in every computer language and file format.

Your design flow will run a wide variety of tools. Use exactly the same variable name everywhere. Resist the temptation to change names to respect the naming convention of a particular tool. For example, I once used designName for the name of the top design in TCL scripts, and DESIGN_NAME in Makefiles. This was extremely inconvenient until I changed to designName everywhere, in violation of the usual Makefile custom of using capitals and underscores for variable names.

Flow Steps

You might be tempted to create giant scripts to run EDA tools from start to finish. It is better to separate the flow into shorter steps that perform individual tasks.

• Each step must be reentrant. This means that you can safely restart the flow at any step. The most basic requirement for reentrance is that the step reads data from one database at the beginning, and saves the result in a database with a different name at the end.
• Give each step a short, yet descriptive name. You will type it a lot, and many file names will be based on the step name.
• Where reasonable and efficient, the inputs and outputs of a step should be in a vendor independent format like OpenAccess, LEF, DEF or Verilog. Still, many steps are best saved as a proprietary database, particularly in place and route. For example, a global routing database will only be read by the tool that wrote it, so go ahead and save it as an Encounter, Volcano or Milkyway database.
• End steps at points where you have a meaningful, stable result that will allow you to make an informed decision about what to do next. For example, produce a legal placement, create a timing report, and then end the step.
• The more iterations required to get a step right, the shorter the step should be. An example of this is power routing, where you often tweak your power routing script, run, and observe the results several times before it works correctly.
• However, starting and stopping CAD tools, reading and writing databases takes time and space. For the sake of economy, you want fewer steps.

When designing your flow steps and your flow in general, learn from others. Refer to existing flows like the TSMC Reference Flow, Cadence Encounter Foundation Flow, Synopsys Lynx Design System or the Voom Flow.

Chip Design Flow Control Architecture

The following diagram shows the main components that make up an IC design flow:

• The flow controller is the boss. Based on instructions from the user, it determines,
  • The steps to be executed based on the state of the design and the goal requested by the user
  • Variable values. It passes these values to the other tools and scripts.
• The flow controller starts the correct EDA tool, which may be anything from an awk script to a place and route tool
• If appropriate, the flow controller specifies a script to be executed by the EDA tool
• If you have a server farm, you will need a job scheduler to distribute the computing load among the servers
• Larger projects use design management software to manage data versions

Now let’s look at each one of these applications in the tool hierarchy.

Flow Controller

The flow controller manages the execution of flow steps like placement or timing analysis. It determines,

• The steps that must be executed to bring the design from its current state to the state requested by the user
• The EDA tool version to use
• Variable values. The flow controller passes these values to the other tools and scripts.

Avoid controlling your flow with user-defined shell environment variables, such as in .bashrc. The UNIX module utility can be used to control versions of EDA tools and other executables through the environment.

There are several common flow controllers that vary in sophistication. As with most things, there is a trade off between automation and the effort needed to manage the solution. The more engineers who run the flow, the more automatic your flow controller must be.

Simple Shell Script

Many chip designers manually maintain a shell script that executes every step in the flow. After a step completes successfully, the designer comments it out so that re-running the script executes only the remaining incomplete steps. For example, a script might look like this after data preparation is complete, and it is time to do placement:

#! /bin/sh
# Perform physical synthesis with Synopsys IC Compiler
# John McGehee, Voom, Inc. 8/1/09

export flowPath=../../flow

# icc_shell -f ${flowPath}/icc/scr/netlistIn.tcl | tee netlistIn.log
# icc_shell -f ${flowPath}/icc/scr/floorplan.tcl | tee floorplan.log
# icc_shell -f ${flowPath}/icc/scr/pgRoute.tcl | tee pgRoute.log
# icc_shell -f ${flowPath}/icc/scr/setupTiming.tcl | tee setupTiming.log
icc_shell -f ${flowPath}/icc/scr/placement.tcl | tee placement.log
icc_shell -f ${flowPath}/icc/scr/cts.tcl | tee cts.log
# and so on...

When it is time to re-run the entire design flow, the designer simply removes all the comments and runs the script again.

The shell script has the advantage of simplicity—these scripts rarely contain even a single if statement. However, because the state of the design is stored in the user’s head, this flow controller cannot be recommended for multiple users.

GNU Make

Make has been my favorite flow controller since I first applied it to a design data converter. Originally developed to help programmers compile and link programs, Make can control any process where a sequence of shell commands must be performed in an arbitrarily complex order. GNU Make is free, open software that is already installed on virtually every computer used for designing chips.

Make syntax is somewhat arcane, but the GNU Make documentation is excellent. Most programmers (and many chip designers) are familiar with Make, so there is almost certainly someone at your company who can answer your questions. Finally, the ability to use Make is a useful, portable skill that you should have.

Example Makefile for IC Design

Make is controlled by a Makefile that describes the relationships among files and the commands for updating each file. When the data are source files like C++ and Verilog, you can use the actual input and output file names. When the data are design databases, the file names are unpredictable, so it is best to use a semaphore file instead of the actual database files. For example, the shell script flow represented above is described in the Makefile like this:

ICC_SHELL=/path/to/icc_shell
GREPERR=egrep -i '(error|warning|fail)'
flowPath=../../flow

designName=blockHead
netlistFileName=../../data/netlist/$(designName).vg
sdcFileName=../../data/timing/$(designName).sdc
floorplanScript=local/floorplan.tcl
pgRouteScript=local/pgRoute.tcl

.PHONY: all tidy clean realclean

# The first target is the default.
# Therefore, streamOut will be done when you type 'make' or 'make all'.
all: streamOut

# Note how the comments are inside the target, so they will be printed
# as the flow runs.
netlistIn: $(netlistFileName)
        ####################################
        # Read the netlist
        # Input file $(netlistFileName), output cell netlistIn.CEL
        $(ICC_SHELL) -f $(flowPath)/icc/scr/netlistIn.tcl | tee netlistIn.log
        -$(GREPERR) netlistIn.log > netlistIn
        touch netlistIn

floorplan: netlistIn $(floorplanScript)
        ####################################
        # Run the commands in $(floorplanScript) to floorplan the block
        # Input cell netlistIn.CEL, output cell floorplan.CEL
        $(ICC_SHELL) -f $(flowPath)/icc/scr/floorplan.tcl | tee floorplan.log
        -$(GREPERR) floorplan.log > floorplan
        touch floorplan

pgRoute: floorplan $(pgRouteScript)
        ####################################
        # Run the commands in $(pgRouteScript) to route power, ground, and other special nets
        # Input cell pgRoute.CEL, output cell floorplan.CEL
        $(ICC_SHELL) -f $(flowPath)/icc/scr/pgRoute.tcl | tee pgRoute.log
        -$(GREPERR) pgRoute.log > pgRoute
        touch pgRoute

setupTiming: floorplan $(sdcFileName)
        ####################################
        # Read timing constraints
        # Input cell floorplan.CEL, output cell setupTiming.CEL
        $(ICC_SHELL) -f $(flowPath)/icc/scr/setupTiming.tcl | tee setupTiming.log
        -$(GREPERR) setupTiming.log > setupTiming
        touch setupTiming

placement: setupTiming
        ####################################
        # Perform automatic placement
        # Input cell setupTiming.CEL, output cell placement.CEL
        $(ICC_SHELL) -f $(flowPath)/icc/scr/placement.tcl | tee placement.log
        -$(LOGSUMMARY) placement.log placement.tim | $(MAILER) -s "$(designName) Placement Done" $(USER_EMAIL)
        -$(GREPERR) placement.log > placement
        touch placement

cts: placement
        ####################################
        # Perform clock tree synthesis
        # Input cell placement.CEL, output cell cts.CEL
        $(ICC_SHELL) -f $(flowPath)/icc/scr/cts.tcl | tee cts.log
        -$(GREPERR) cts.log > cts
        touch cts

# And so on, for the complete flow ending with the streamOut target
# that creates Milkyway cell $(designName).CEL, $(designName).FRAM,
# and streams out GDSII file $(designName).gds2 

# Finally, some administrative targets

tidy:
        ####################################
        # Remove annoying junk files, but never any useful files, not even *.log
        rm -f  *.log.??_??_??_?? *.cmd.??_??_??_?? *.TXT core dbSwap* vfPage* vlog*

clean: tidy
        ####################################
        # Remove all the semaphore files to reset the flow in preparation
        # to re-run.  Delete no data, so you can recover if you change
        # your mind.
        rm -f netlistIn floorplan pgRoute setupTiming placement cts # ...

realclean: clean tidy
        ####################################
        # Remove all data created by this flow
        # $(designName) is the library containing all the cells
        rm -rf $(designName)
        rm  -f *.tim *.spf *.SDF *.log *.drc *.lvs \
            *.dump.* *.prsum *.gds2 *.text *.prv \
            *.skew* *.dc *.sdf

With this Makefile in your working directory, you can type,

make floorplan

and Make will execute the commands within the netlistIn and floorplan targets, updating the modification date of the netlistIn and floorplan semaphore files along the way. Then, if you give the command,

make placement

Make will see that the file floorplan exists and is newer than netlistIn, which is newer than $(netlistFileName), so those steps are up-to-date and need not be rerun. The pgRoute, setupTiming and placement targets will be executed and the modification time of the respective semaphore files updated.

Refer to the GNU Make documentation for a thorough explanation of Make and its theory of operation.

Make Automatic Variables

In the above example Makefile, you will notice that the same strings appear repeatedly. I wrote it this way for the sake of clarity, but it is better to use automatic variables. For example, while the commands in the placement target are running, automatic variable $@ is set to placement, and $< is set to setupTiming, Therefore, this target can be rewritten,

placement: setupTiming
        ####################################
        # Perform automatic placement
        # Input cell $<.CEL, output cell $@.CEL
        $(ICC_SHELL) -f $(flowPath)/icc/scr/$@.tcl | tee $@.log
        -$(LOGSUMMARY) $@.log $@.tim | $(MAILER) -s "$(designName) $@ Done" $(USER_EMAIL)
        -$(GREPERR) $@.log > $@
        touch $@

Now, when you make a new target by copying an existing one, there is less to change, and therefore fewer opportunities to make a mistake. It also enforces the rule that the target, script, log file, output cell, output file should all share the same name.

Tips for Using GNU Make as an IC Design Flow Controller

Finally, let me share a few GNU Make tricks that I find useful:

• Use touch and rm to restart the flow at an intermediate step. Which one you use depends on your situation:
  • To invalidate a step, remove the target (semaphore file) for it. For example, if you do not like your power/ground routing, fix the power routing script and then do,
    

    rm pgRoute
    make pgRoute

    to rerun the pgRoute step.

  • If you update the results of a step, touch its target to update its modification time to the present time. For example, suppose that you fix the placement by moving some cell instances. Save the placement database, and declare that this result is the most up-to-date using,
    

    touch placement

• Like many UNIX commands, Make has a -n option that prints the commands that it would do, without actually doing them. Use this to check what will happen before you commit to starting a run.
• Another handy GNU Make option is -t, which updates all dependencies of the target you specify, without executing the commands within the targets. For example, suppose you are using the Makefile shown above, and floorplan is up-to-date. The command,
  

  make -t placement

  will update the modification time of files pgRoute, setupTiming, and placement, so that the placement target is up-to-date. make -t can be tricky, so after you use it, check that the flow really is in the expected state using make -n.

• Make variables are exported to the environment of the shell in which the command is run. This means that you can define your design parameters once in the Makefile, and use these values in your scripts. For example, netlistIn.tcl can and should get the netlist file name using the Tcl command $env(netlistFileName).
• The article Debugging Makefiles explains an advanced technique that allows you to see more clearly what will be executed and inspect the value of Makefile variables.
• You may have noticed the LOGSUMMARY command in the placement target. This is a Perl program that keeps me informed by extracting a summary of the placement result from the log file and emailing it to my mobile phone. Tuscany Design Automation sells a similar application.

Other Flow Controllers

If you want commercial software, check out Runtime Design Automation. Their FlowTracer flow controller allows you to easily reorder your steps to optimize your flow. Make is less flexible in this respect because it was designed for a work flow that needs no rearrangement—programmers never want to try linking before compiling.

Some companies build their own proprietary flow controllers. With the solid free and commercial offerings that are available, a custom flow controller sounds like an expensive luxury to me. People have tried to add GUIs to flows, but that does not seem worth the effort, either.

Job Scheduler

Workload management software is used to balance the computing workload across multiple servers. Platform Computing LSF is the industry standard.

Runtime Design Automation offesr a unique combination of flow controller and job scheduler that helps you to get the most out of your computing hardware and software licenses.

If you like, start out by submitting jobs interactively, and add job scheduling software later when you have a server farm big enough to take advantage of it. The change will cause little disruption.

EDA Tool

This is the software that actually processes the data to construct or verify the chip. This may include simple scripts as well as traditional CAD tools. It is not for me to recommend EDA tools to you, as you probably have your own ideas.

It is the responsibility of the flow controller to launch the correct version of the tool. The UNIX module utility can help control versions of EDA tools and other executables.

Tool Scripts

Many EDA tools are controlled using a Tcl or Python language script. Specify the script on the command line when you launch the tool, as shown in the Flow Controller examples.

The tool hierarchy is getting pretty deep here: the user starts the flow controller, which launches the EDA tool, which executes the tool script. That’s enough. Adding more will only confuse the user. For example, do not do this:

• In the flow controller, execute a Perl program
• The Perl program creates an input file and launches an EDA tool

This is much easier to understand:

• In the flow controller, execute a Perl program to create an input file
• In the flow controller, launch the EDA tool

Similarly, avoid calling sub-scripts within scripts. Get the same effect without nesting scripts by performing initialization in the startup file. Organize your base routines into reusable packages or modules.

Any software works best when you use it in the plainest, most ordinary way. Whenever possible, do things the tool’s way rather than your way. User manuals tell you about individual commands, but proven flows like the TSMC Reference Flow, Cadence Encounter Foundation Flow, Synopsys Lynx Design System or the Voom Flow provide the most accurate documentation on how to assemble a working design system.

Perform operations related to a tool in that tool’s native scripting language, on the tool’s native database. Most scripting interfaces give you excellent access to the EDA tool database (beware of tools that do not). Use this powerful feature to,

• Shorten your script because the EDA tool will help you. If you want to move a cell, do it and then run placement legalization. This sure beats munging DEF with a Perl program.
• Increase your immunity to changes in new EDA tool versions. Database access APIs are remarkably stable.

However, do not write extensive software that depends on a proprietary format, database or language. This ties your software to a specific tool or vendor that may become unavailable or unreliable. Develop sophisticated CAD applications on the OpenAccess design database or public formats like LEF, DEF, or Verilog so your application will work with any tool.

Keep your scripts and configuration files in a source code version control system like Subversion or CVS. You may find it advantageous to use the same design management system for scripts as well as data.

Acknowledgements

Thanks to David Chinnery, author of Closing the Power Gap between ASIC & Custom: Tools and Techniques for Low Power Design and Closing the Gap Between ASIC & Custom: Tools and Techniques for High-Performance ASIC Design for reviewing this manuscript and offering invaluable suggestions.

* 日立FBSLやHUSLデータ変換 プログラムでした。その当時に日立武蔵工場で一緒に立ち上げた方々、なつかしいですね。是非連絡下さい！(search terms fishing for friends from that project)

I’ve used Japanese text input since RHEL 3, and Fedora 11 makes multilingual text input even easier. This article describes how to set up Japanese text input with the latest Fedora.

Japanese test display works by default. The new fonts in Fedora 11 are beautiful. If a Japanese language web site does not display properly in Firefox, try adjusting the encoding with View > Character Encoding > Japanese(Shift_JIS) or View > Character Encoding > Japanese(EUC-JP).

For information on how to install Japanese language input on other Linux distributions and other Fedora versions, see Scott Robbins’ authoritative guide, Inputting Japanese text in Linux and some BSDs. I have invited Scott to add this text to his guide when he gets the chance.

Installing the Input Method

Start by installing Japanese input method packages:

yum install scim-lang-japanese

Then, set up your preferences with System > Preferences > Input Method. This will bring up the IM Chooser dialog. You can use either the IBus or SCIM input methods:

• If you Use IBus, click on Input Method Preferences, and choose the Input Methods tab. From the Select an input method list, choose Japanese, and any other languages you want to input. Use the Up and Down buttons to arrange the order in which they appear when you hit the Alt+Shift_L hot key. I also added Chinese-Pinyin, and it works great. At last I can directly express in Chinese how good IBus is, 非常好, instead of entering how much I like it in Japanese, 非常に好きです, and then editing it into Chinese.
• If you Use SCIM, The Input Method Preferences are already set up for Japanese

You may need to log out and log in to see the changes. Now, whenever you hit Ctrl+Space, a small window will appear in the lower right corner of your display. Type something in Japanese. Hit Ctrl+Space once more, and you are typing in English again.

Changing Your User Language

If you really want to go native, add the following to the .bash_profile file in your home directory:

export LANG=ja_JP.UTF-8

Log out and log in again, and everything is in Japanese.

Don’t try this at home unless you can actually read Japanese. In particular, you will be asked if you want to change your file names to Japanese. Give the wrong answer, and your Desktop/ directory will be renamed デスクトップ/. Are you already staring at the dialog that is threatening to do this? Select 古い名前のままにする(K) to keep your current file names.

Changing the Locale

The locale is a big subject, but the most useful setting I have found is the LC_CTYPE environment variable, because it changes the formatting of dates and currency values in OpenOffice. This may be useful if you live in Japan, but prefer to use Linux in English. In the .bash_profile file in your home directory, add the following :

export LC_CTYPE=ja_JP.UTF-8

Log out and log in again, and everything is in English, assuming LANG is no longer set to ja_JP.UTF-8. Open a spreadsheet with Applications > Office > OpenOffice.org Calc. Choose Format > Cells, choose the Numbers tab, and you can see that the Language has changed to Japanese, and the choices for date and currency formats are those customary in Japan.

gwaei Japanese-English Dictionary

Now that you can type both Japanese and English, you will want a dictionary. The gwaei Japanese-English dictionary for Linux works great with Fedora 11.

Note that the gwaei i386 RPM will not work with x86_64 Fedora 11. If you installed the x86_64 version of Fedora 11, just compile gwaei as explained in the installation instructions.

The Cadence ITK C API and the OpenAccess C++ API can be used simultaneously in the same program.

Cadence ITK (Integrator’s Tool Kit) enables C programs to directly manipulate the database for Virtuoso IC layout software. ITK is a decades old product that originally supported the CDB (CDBA) database. Like the rest of Virtuoso, ITK now supports OpenAccess. This allows your legacy ITK programs to work with both CDB and OpenAccess design databases. If you need it, that’s an awesome (yet fading) advantage.

For new code, you will want to use the more modern OpenAccess C++ API. Therefore you may find that you need to link both APIs into the same program. This works great if you obey a few simple rules:

1. Use the same OpenAccess version that ITK uses
2. Initialize ITK with dbInit() first, and initialize OpenAccess with oaDesignInit() second
3. ITK functions get library access automatically as needed, while OpenAccess clients are expected to explicitly get library read or write access using oaLib::getAccess(). If you fail to get proper access, OpenAccess throws an exception.
4. ITK handles names in the CDBA namespace. Therefore, use the oaCdbaNS namespace in the OpenAccess API when passing name strings to or from ITK.

I did not try casting between OpenAccess pointers and ITK database IDs. If you succeed at this, let me know how it goes.

When a user wants chip design data, a script or a log file,how do they find it? They use file and directory names. As an IC design flow architect, proper file naming is the most important thing you can do to guide your users to the files they need. By just looking at the path and name of any file, a user should be able to determine:

• Design name
• File format
• Step that created it, and therefore the tool that created it
• operating conditions if pertinent

This is one of a series of articles on simple, specific techniques that will make your chip design flow easy to use. In this installment, I will explain how to give helpful names to files and directories. Other articles include,

• Apply the Scientific Method to IC Design Flow
• Write Effective Error Messages
• Properly Name Log Files for EDA Tools
• Control Your IC Design Flow
  

Choose a Step Name and Use It for Everything

Choose a descriptive name for every step of your flow. Users will type this name a lot, so keep it short, use lower case letters, and maybe one capital letter. Generally a step name will be a verb. Use this name for everything related to the step:

• Script
• Log file
• Output database and reports
• Makefile target
• Variable names
• Name used in project management software, such as Bugzilla

When the step name alone is insufficient, append more information, for example, placeMin.rpt, placeTyp.rpt, placeMax.rpt. This way, all files related to step place appear together when listed alphabetically.

See also the related topic of chip design flow variable naming conventions.

One Design Per Directory

Many flow designers start out thinking that it might be useful to allow multiple physical hierarchical designs to share a working directory. It is not useful, so each design in the physical hierarchy should have its own directory.

There is no need to organize the working directories into a hierarchy of directories that match the chip hierarchy. Put the working directories wherever they make sense in your work flow.

Since there is only one design, use the design name for the:

• Design directory name
• Database library name
• Output files containing the completed design:
  • Design name in the database. Use the most ordinary view name. For example, the completed layout for design blockHead should be saved to OpenAccess as blockHead/blockHead/layout, or in Milkyway as blockHead.CEL.in library blockHead.
  • GDSII file, like blockHead.gds
  • Text format files, like blockHead.v, blockHead.def, and blockHead.lef

Otherwise, use the design name sparingly. The design directory is named after the design, so every file path already contains the design name.

A Working Directory for Each Tool

Within the directory for a design, create a directory for each EDA tool used. When using a tool, cd to its directory and then start the tool. While running the tool, do not change the working directory.

I have seen flows organized with the tool directory above and the design directory within (toolName/designName). It’s possible, but it does not work as crisply as designName/toolName.

Use Relative Paths, Avoid Symbolic Links

Relative paths allow your run directory to be moved or copied freely. Relative paths are shorter, and therefore easy to read.

Absolute path names do have their place. It is reasonable to use a fully qualified path to things that are separate from the current design:

• Libraries, technology files, and other input data
• Software applications and the design flow

Even so, it may be best to avoid directly specifying the path to these things, and take a more sophisticated approach to managing your design environment, such as using the modules package.

Do not use symbolic links as a part of your flow. Symbolic links are a sneaky way to make files appear to be somewhere they are not. In a design flow, you want straightforward, not sneaky. Use a variable instead of a symbolic link.

Use Names Compatible with Verilog

You will use design names as file and directory names, and vice versa. The most restrictive name space used in IC design is Verilog, so obey Verilog naming rules when choosing directory names and file base names. It’s simple:

• Use only alphanumeric characters and _
• The first character must be a letter

This way, file names can match the names of design objects without complicated escape sequences. These rules apply to the base name (as in baseName.ext), not the file extension name.

Name for Alphabetization

Users will list the files with ls countless times. Help them see the relationships between the files by naming them so that related files appear together when listed in alphabetical order. Begin the file name with the most important word (like setup or hold), followed by the next important (like operating conditions) and so on.

Use leading zeros for numerical values so that alphabetical order is also numerical order, like the temperature values in,

setup.typ_1p2_000.rpt
setup.typ_1p2_025.rpt
setup.typ_1p2_100.rpt

Use Standard File Extension Names

Always use the standard file extension names for,

• Source code files, so that your text editor can do proper syntax highlighting. For example, .cpp, .py, .tcl, .v.
• Industry standard formats: .def, .lef, .lib, .sdc, .spef and so on
• Graphics files, so that they are correctly displayed: .jpg, .png, .gif.
• Files that you expect Microsoft Windows to recognize: .txt, .csv. Don’t forget to do unix2dos before trying to read Linux files with Windows.

Many files have no official file extension. Still, your flow will be much easier to understand if you use the most recognizable one:

• Log files use .log
• Report files use .rpt (although I do see a lot of Synopsys PrimeTime reports with .pt)
• For binary data with no other customary name, use something like .dat. Reserve .db for Synopsys database files.
• GDSII stream files use .gds (best), .gdsii or .gds2
• It is common to use a variety of file extensions for Verilog such as .v for RTL, and .vg for gate level, At least start with .v.

Whatever file extensions you choose, be consistent and use the same ones throughout your flow.

Use Directories Sparingly

You already have a tool working directory within a design directory. There is not much to be gained by partitioning your files into even more sub-directories. It often only serves to hide files and increase the amount of typing required. Certainly there is no need for any more than one level of sub-directory below the tool working directory.

Instead of distinguishing a file using a directory, consider simply lengthening the file name. For example, use setup.typ_1p2_100.rpt instead of setup/typ_1p2_100.rpt.

When you create a sub-directory within the tool working directory, use a short name. Reuse the same name wherever possible.

Still, some kinds of sub-directories make sense:

• A physical verification tool working directory is a special case. It generally contains separate working directories for LVS and DRC. For example, Mentor Calibre LVS is generally run in working directory designName/calibre/lvs, and DRC is run in designName/calibre/drc.
• A directory that contains input data, or data that retained for use in subsequent iterations of the design flow. Pin placement files and floorplan files are examples of this. Keeping input files in a separate directory sets them apart and protects them from accidental deletion.
• Many flow designers like to add directories like log/ and rpt/. Myself, I get along fine without either one. Directories like these are a matter of taste.

I have seen a few kinds of sub-directories that should be avoided:

• A sub-directory for databases that are organized as libraries, like Milkyway, CDB and OpenAccess. Such a sub-directory usually ends up containing just a single library, so it is completely redundant. Put libraries in the working directory.
• Sub-directories that attempt to artificially partition the design process for a tool into phases like design/ and analysis/. As your flow evolves, the boundary between the phases will drift, and you will end up storing almost everything in, say, design/, with a just a few orphan files left in analysis/.

Avoid Hidden Files

Hidden files (UNIX files that start with “.”) are a mean trick. Avoid them. Still, the initialization file for some design tools is a hidden file, like .cdsinit, .avantrc or .synopsys_pt.setup. Changing the initialization file name is an even meaner trick, so use the standard initialization file name regardless of whether it is hidden.

Name the Library Path the Same as the Library Name

OpenAccess and Cadence Virtuoso CDB allow you to specify a library path that is unrelated to the library name. For example, you might use the lib.defs or cds.lib file to specify that the library named blockHead is in directory /path/to/BH2.7. Without the lib.defs or cds.lib file, there is no way to know the name of the library in /path/to/BH2.7. This path should be rearranged so that it ends with the library name, for example /path/to/2.7/blockhead.

With Synopsys Milkyway, this is not an issue. The directory in which the library is stored is always the same as the library name. This is the right way to do it.

File Completion in Two Characters

Chris verBerg has a fun rule. He tries to name source files such that the first two characters are unique, so he need only type two characters, and file name completion will finish the name. Full file name completion might be too much to ask for design data files, but it is an excellent goal for sections of file names. For example, you could quickly find setup.typ_1p2_100.rpt
by typing “se” <Tab> “ty” <Tab>, and so on.

In particular, do not use names with similar prefixes, like place.log and placement.rpt. Choose either “place” or “placement”.

I constantly find old junk buried in my yard. Steel beer cans that were opened with a church key. A fifth of Jack Daniels. Two full sheets of corrugated aluminum roofing. Golf balls continuously stream in.

Look what I found today. Just two more to complete my DMV golf ball collection.