[Eda-dev] TimberWolf and Magic

Tim Edwards tim at opencircuitdesign.com
Sat Dec 5 09:45:33 EST 2015

Hello Jody,

> This is the first time I am contacting you. So, let me introduce myself. My
> name is Jody Maick Matos. Currently, I am a PhD Candidate at PPGC
> <http://ppgc.inf.ufrgs.br/en/> / UFRGS <http://www.ufrgs.br/english/home>,
> Brazil. My R&D field is related with EDA tools and algorithms, specially
> concerning logic synthesis.
> First, congratulations! You are doing a really good job at Open Circuit
> Design. I really appreciate your effort on having a complete digital
> synthesis design flow using open-source software and open-source standard
> cell libraries. Thank you for that!

Thank you very much.  It's my goal to put the open source back into VLSI,
but I have plenty of help from others like Clifford Wolf (yosys), Alan
Mischenko (ABC), etc.

> I have just started a research on an emerging non-ASIC technology and the
> challenges I am facing now have already been handled before by the ASIC
> tools (two routing layers only, non-over-the-cells channel-based routing,
> ...). Specifically, I need P&R tools and algorithms based on variable-die
> methodologies. In this sense, I am trying to adapt TimberWolf's placement
> and global routing to our purpose, detail routing with QRouter and
> finishing the layout with Magic. By the way, I am using TimberWolf 6.3
> (downloaded from OCD <http://opencircuitdesign.com/verilog/>), QRouter 1.2
> without interpreter, and Magic 8.0 (revision 210, with Tcl8.6.1 / Tk8.6.1).

I would strongly suggest switching to graywolf (from github), qflow-1.1,
and qrouter-1.3, since together they have some critically important fixes
relative to the versions you are using.  In particular, qrouter is now
easily (although not quickly) routing microprocessor-sized designs.

> I am sending you this message because I am facing two issues when running
> the backend design flow using TimberWolf and Magic:
>  1. What motivates me to use TimberWolf is the fact that (in theory) it is
>     able to deal with row-based standard cell placement and global routing
>     in a variable-die methodology. Thus, I am trying to have a placed
>     design with routing channels so that each channel's height be minimized
>     (having different heights, possibly) based on congestion estimations
>     obtained from global routing.
>     However, even running a number of different strategies, TimberWolfSC is
>     always producing a placement in which every channel has the same height
>     (independently if I am using a "rowSep" parameter as 1.0 or 5.0, for
>     example). Probably, I am doing something wrong when running the tool.
>     I am sending you attached the input files I am using with TimberWolf. I
>     would really appreciate if you could point me out what I am doing wrong.

Unfortunately I've found a number of things that TimberWolf is supposed to
be able to do "in theory" but which I cannot manage to get it to do in
practice.  I feel that the independent routing channel height must have
something to do with the TWMC parameters, e.g.,

	TWMC*do.channel.graph  : on
	TWMC*do.global.route  : on
	TWMC*do.compaction : 3

and possibly the other TWMC parameters "default.tracks.per.channel",
"gridX", "gridY", "gridOffsetX", and "gridOffsetY".  However, I cannot make
TimberWolf/graywolf produce output with anything other than regularly-
spaced channels.

I am seriously short on time before Christmas, but I can probably take a
look at it over the holiday.  I think it is key to routing in, for example,
the 3-metal stack defined in the OSU050 standard cells.  There are severe
restrictions on metal3 routing, which means that most routing comes down to
metal1 and metal2, and that looks much more like a channel router.

I should point out that Magic has an internal channel router, but I'm sure
there's a way to make TimberWolf produce the right output.  Just need to
figure it out (but I checked---the TimberWolf documentation isn't much
help here).

>  2. I am having a couple of problems when running Magic associated with
>     "-dnull" and "-noconsole" options:
>     /$ magic  //without options
>     /everything is great and the tool runs normally, with graphics and
>     everything
>     /$ magic -dnull
>     /everything is great and the tool runs normally, without graphics of course
>     /$ magic -noconsole
>     /Magic segfaults. You will find the complete error message in the file
>     "magic-noconsole-error.log" (attached)
>     /$ magic -dnull -noconsole
>     /            Magic do not open, presenting the following message:
>     "/couldn't load file "/usr/local/lib/magic/tcl/tclmagic.so":
>     /usr/local/lib/magic/tcl/tclmagic.so: undefined symbol:
>     Tk_GetCursorFromData/"
> I am sorry for bothering you with such things. I hope you could help me on
> solving these issues.

Not a problem at all.  The whole point of open-source is that it works
better that closed-source because people give immediate feedback when
something goes wrong (and in the best case, the developer generates an
immediate fix, although right now, I may be a few weeks delayed).

 From your log file:

	catch {source /usr/local/lib/magic/sys/site.def}
	: 1

"catch" returns 1 when it has encountered an error.  So there is
something in your "site.def" file it doesn't like.  On my end, though,
I need to figure out why magic is being so poorly behaved about
handling the error status returned from sourcing site.def.  Can you
please send me your site.def file so I can see why it's failing?

Because of my heavy current work schedule, it is very likely that I will
forget about this by late December, so please feel free to send me a
reminder about it.

| R. Timothy Edwards (Tim)       | email: tim at opencircuitdesign.com    |
| Open Circuit Design            | web:   http://opencircuitdesign.com |
| 19412 Cissel Manor Drive       | phone: (301) 528-5030               |
| Poolesville, MD 20837          | cell:  (408) 828-8212               |

More information about the Eda-dev mailing list