cell libraries and place and route

[Pete nospam Zakel]

In article <cq61g0$16p$1@home.itg.ti.com> Rajeswaran M <m_rajeswaran@DELETETHISyahoo.com> writes:

When particular object is queried the property window is small and we
need to resize every alternative time. Also during that time the icfb
hangs for few seconds. we started facing the problem since our recent
linux migration. The problem exists both in KDE and Gnome environments.
Any help?

This bug has been reported against KDE. I have never seen it with Gnome.

What window manager are you using with Gnome?

-Pete Zakel
(phz@seeheader.nospam)

"Under capitalism, man exploits man. Under Communism, it's just the opposite."

-J. K. Galbraith

 

[Rajeswaran M]

Hi Pete,

We use sawfish as window manager in Gnome. We do have the same problem
in this too.

Thanks
Rajeswaran

Pete nospam Zakel wrote:

In article <cq61g0$16p$1@home.itg.ti.com> Rajeswaran M <m_rajeswaran@DELETETHISyahoo.com> writes:

When particular object is queried the property window is small and we
need to resize every alternative time. Also during that time the icfb
hangs for few seconds. we started facing the problem since our recent
linux migration. The problem exists both in KDE and Gnome environments.
Any help?


This bug has been reported against KDE. I have never seen it with Gnome.

What window manager are you using with Gnome?

-Pete Zakel
(phz@seeheader.nospam)

"Under capitalism, man exploits man. Under Communism, it's just the opposite."

-J. K. Galbraith

 

Ralf Geiger wrote:

Or just the plain fvwm ... it works great.
All this fancy overload of kde/gnome is not
needed for EDA work ...

fvwm and fvwm95 do not have the "click-to-raise-
anywhere-in-the-window" bug, so that's nice.

However, they both exhibit the "false-mouse-warp" bug,
just the same as KDE.

RHEL3, ic5033, fvwm95-2.0.43e, fvwm-2.2.3.

Mind you, I don't know whether the warping problem is a
Cadence bug, an XFree86 bug, a window manager bug,
or ???. Guess I should get off my ass and submit
a service request to Cadence.

-Jay-

 

[Barry Margolin]

In article <cqktra$85l$1@newsreader2.netcologne.de>,
Pascal Costanza <costanza@web.de> wrote:

Barry Margolin wrote:
In article <cqklo3$of1$1@newsreader2.netcologne.de>,
Pascal Costanza <costanza@web.de> wrote:

I'd be surprised if the fact that someone "suddenly" writes a book about
these ideas would result in noone being allowed anymore to reuse them in
other contexts.

The book in question contains significant amounts of code -- an entire
CLOS implementation, in fact. The OP was asking about copying code
directly (or translating it directly into another programming language,
which would probably be considered a derivative work), not about using
the ideas.

Oh, I see. But the Closette code is also available from
ftp://ftp.parc.xerox.com/pub/pcl/mop/ and explicitly allows derivative
works.

And as other posters in this thread have already pointed out, the book
itself gives permission to copy the code. The OP obviously didn't see
that.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 

[Jim Newton]

Well the book's copyright first forbids copying of any part.
Then before chapter 5, an exception is stated allowing
copying of chapters 5 and 6. And then again appendix D
has a copyright notice in the code which allows copying.

So yes you are right, "the book itself gives permission
to copy the code", but it takes a lot of work to find
the notice.

-jim

Barry Margolin wrote:

And as other posters in this thread have already pointed out, the book
itself gives permission to copy the code. The OP obviously didn't see
that.

 

[Ralf Geiger]

jayl-news@accelerant.net schrieb:

Ralf Geiger wrote:
Or just the plain fvwm ... it works great.
All this fancy overload of kde/gnome is not
needed for EDA work ...

fvwm and fvwm95 do not have the "click-to-raise-
anywhere-in-the-window" bug, so that's nice.

However, they both exhibit the "false-mouse-warp" bug,
just the same as KDE.

I don't know what you mean with "false-mouse-warp", but
I have just good experience using fvwm and cadence DFII Tools ...
And keep in mind, that it is possible to configure fvwm a lot,
maybe your .fvwmrc is "wrong" at this place ...

Cheers
Ralf
--
no signature

 

[Pete nospam Zakel]

In article <1103832249.419761.111740@z14g2000cwz.googlegroups.com> jayl-news@accelerant.net writes:

However, they both exhibit the "false-mouse-warp" bug,
just the same as KDE.

What do you mean by "false-mouse-warp"? Note that DFII has an option to warp
the cursor. That can be turned off by adding the line:

hiGetCIWindow()->warpPointer = nil

to your .cdsinit file. Personally, I think warping the cursor is evil...

-Pete Zakel
(phz@seeheader.nospam)

"The marvels of today's modern technology include the development of a
soda can, when discarded will last forever...and a $7,000 car which
when properly cared for will rust out in two or three years."

 

[haneu]

Ralf Geiger wrote:

Suresh Jeevanandam schrieb:
Hi,
Check out fvwm95.
http://fvwm95.sourceforge.net/

Or just the plain fvwm ... it works great.
All this fancy overload of kde/gnome is not
needed for EDA work ...

cheers
Ralf

I'd recommend the olvwm. Works great with cadence and doesn't has this
fvwm95 overhead. There are still some people used to it (it is the old
"Sun" window manager). Get the lib olgx and olvwm (Still available)
It runs fine fine on RH 7.2, 8.0 and RHEL 3.0 (rpms available)
Some colleagues had the kde, but now some are going for the olvwm. It
runs stable forever without slowing down or grabbing memory. If one
needs just a window-manager, this is still one of the best.
Regards, Harald

 

Ralf Geiger wrote:

I don't know what you mean with "false-mouse-warp",

As I said earlier in the thread:

An additional related Linux/Virtuoso annoyance is warning
popups; these normally warp the mouse to themselves (and
then warp the mouse back when OK'ed or canceled. On CDE,
this works great. On KDE, the mouse *looks* warped, but
when you click, the click lands on the original location,

-Jay-

 

[Pete nospam Zakel]

In article <1104955236.647952.253060@z14g2000cwz.googlegroups.com> jayl-news@accelerant.net writes:

Pete nospam Zakel wrote:

What do you mean by "false-mouse-warp"?

As I said earlier...

An additional related Linux/Virtuoso annoyance is warning
popups; these normally warp the mouse to themselves (and
then warp the mouse back when OK'ed or canceled. On CDE,
this works great. On KDE, the mouse *looks* warped, but
when you click, the click lands on the original location,

This happens with icfb/assura on every Linux/window manager
combination I've tried.

Thanks, I must have missed it the first time.

I've seen that problem before, but since I normally don't work on Linux I
don't know how prevalent it is (and since I turn off mouse warping whenever
I can, I'm unlikely to see it).

-Pete Zakel
(phz@seeheader.nospam)

"I'd love to go out with you, but I'm doing door-to-door collecting for
static cling."

 

[Rajeswaran M]

This problem exists only during edit mode!

Rajeswaran M wrote:

Problem during descending in layout. After the edit in place command,
the layout editing area is being reduced horizontally, however there is
no resize of layout window. After resizing the window the editing are a
becomes normal. This problem comes 5033 onwards.

 

[Rajeswaran M]

This problem exists only during edit mode!

Rajeswaran M wrote:

Problem during descending in layout. After the edit in place command,
the layout editing area is being reduced horizontally, however there is
no resize of layout window. After resizing the window the editing are a
becomes normal. This problem comes 5033 onwards.

 

[Cdon]

also you can import verilog to dfII using Import->Verilog. If you
import
a gate-level netlist, you will need to have at least symbols defined
for
all the cells that are within your design, and specify the library
where
they are as reference library.

if you have symbols for you standard cells, that's fine. otherwise,
you
can first import the stubs file from your standard cells library
(hope
you have one) to generate a library of symbols for the cells. once
this
is done, you can import your verilog with the reference library you
just
created and you will end up with a schematic that you can use to
produce
a spectre netlist which you can simulate together with the
spectre
netlists from your cells.

before being able to netlist properly, you'll need to create stopping

views for your cells, and their CDF, so that they get netlisted as
primitives, otherwise the netlister tries to push into and complains.
I know it sound complicated, but it works and you have to do it once

only. We did this already, so you can email me for more info and some

skill code if you want to do it.

cheers,
stephane

This approach by Stephane sounds reasonable.
Seems to me what you need to simulate are basically:
- transistor-level netlist
- top-level netlist
- simulation test bench
- simulation models

You don't really even need DFII to simulate this, but, I'll assume
you want to use DFII for the sake of this discussion.
It's nice to have a schematic & symbols (although it's not required).

Almost all processes should have a DFII techfile to point to.
This contains primitive symbols and pcells among other things.
If you have the process technology file, point to it in DFII.
If not, create one by reading in the LEF from the digital sc library.
Again, you don't need this to simulate, but it's nice to have.

Then, bring the symbols over from the digital world to DFII
- Most standard-cell libraries contain Cadence CDB symbols
- DFII can read those CDB symbols directly, one for each macro
- If not, most standard-cell libs contain EDIF text symbols
- Read the EDIF 2 0 0 text symbols into DFII
- Again, it's optional to have symbols & schematics; but it's nice.

Bring the sc transistor level netlists over into DFII (if desired)
- Most standard-cell libraries contain CDL netlists for each macro
- Some sc libs even contain the Cadence CDB or OA schematic cell view
- Note: All the Cadence-owned design kits contain sc schematics &
layout
- If the sc lib contains CDB or OA cell views, just point to it in DFII
- If not, read the text CDL netlist to create a CDB schematic
- Note: DFII nowadays creates an editable schematic from CDL.
- The CDB schematic will be ugly, but it will be electrically correct

Now that you have the technology in DFII on CDB or OA, the primitives,
and the symbols - it's time to bring in the top-level netlist into
DFII.

- Read the Verilog gate-level netlist into DFII

Now you should have the entire digital schematic down to the last
transistor (not including parasitics) in DFII on CDB or OA.

Write a test bench and point to the simulation models which came
with the technology file from the library vendor.

I wrote this off the top of my head so you are welcome to dispute
or argue any point.

 

[Richard Griffith]

EDA wannabe wrote:

Some colleagues and I were discussing the situation with the high tech
industry, with jobs moving out of North America. This has hit circuit
designers hard, especially those in digital. Can EDA tool development
be expected to follow suit, is has it already happened? If not, what
are the factors that differentiate it from design work to make it less
exportable? Comments are also welcome for automatation of methodologies
for programmable system-on-chip e.g. reconfigurable processor arrays.

I would say it is time for the EDA industry to flip to open source code.
All the fabless startups are just killed by the tool expenditures they
need to make.

1. OpenSource simulator:
analog -> spice
digital->?
mixed->?
2. Schematic capture
3. Netlister/code capture. I don't think even the professional EDA tools
have this right. Why does multiplier.sch or multipler.c have only 1
view. Why not version control/views built into the editor where the
netlister can be set to grab different versions or the editor highlight
the delta's. A configuration view that sees all views from system level
to extracted with all their associated versions and tags.
4. Layout editor/GDS viewer. How many polygons does a video game push?
5. Schematic/Layout/System viewers that allow properties to attach.
Wires colored by current, sized by voltage. Visualization tools.

I think the industry needs open source tools.

 

[semigy]

StreamVista-Plot is a GDSII viewer that can produce high quality printer
output. A demo version for Windows is available at www.semigy.com.

The software can also export large bitmaps to JPG, PNG, TIFF, BMP, GIF
formats.


--
semigywww.totallychips.com - VHDL, Verilog & General Hardware Design discussion Forum

 

With the :residentfonts: option text is preserved as text, but each
letter
as a separate object, so you cannot change the size or shape of text
afterwards.

If you use our ps2vector software to batch convert such PS output to
EPS or another vector format (e.g. SVG, WMF, CGM, MIF), it will
automatically merge individual characters into words and words into
one-line text strings in the output - so you can more easily edit the
text and its attributes, while saving filesize. Users of Cadence and
other CAD/EDA systems have used it since 1995 to bring graphics output
into their documentation and publishing systems in scalable and
editable vector formats. Available on Windows, Linux and UNIX
platforms.

You're welcome to send me a sample (E)PS file to give it a try.

Jeroen Dekker
--
Square One - The Graphics Connection
Visit http://www.square1.nl/index.htm
jeroen@square1.nl

 

I want vector graphics output OR high resolution bitmap. The problem
with Cadence is that their printing service produces a horrible
mixture of both.

We also have a ps2bitmap module to render the PS file to a TIFF, GIF or
JPEG raster image file at any dpi resolution or color depth.
Jeroen Dekker

 

[Andrew Beckett]

Set these variables in your .simrc file:

lvsSchematicViewList = '( "auLvs" "schematic" "cmos_sch" )
lvsLayoutViewList = '( "auLvs" "extracted" "schematic" "cmos_sch")
;lvsLayoutStopList = '( "auLvs" )
;lvsSchematicStopList = '( "auLvs" )

The 3rd and 4th above don't really need to be set (hence being commented out)
since the default values are already OK.

In other words you need to tell auLvs netlisting which views it is allowed to
swtich into, and in which order it should try them.

Andrew.

On Tue, 18 Jan 2005 20:01:16 -0500, Kuan Zhou <koy2@cisunix.unh.edu> wrote:

Hi,

I have a Cadence "schematic" view of an A/D converter (called "my_ADC")
that has std-cells supplied by a std-cell vendor instanciated (as
"symbols") in it and wired together. The std-cell vendor choose to name
his "schematic" views as "cmos_sch". Hence, the std-cell library has the
following views for each std-cell component supplied:

"cmos_sch" (i.e. actually the "schematic view", but called "cmos_sch")
"symbol" "layout" "extracted"

For my A/D converter, I have the following views:

"schematic" (that has "symbols" of the std-cells instantiated in it)
"layout" "extracted"

Now, when I do an LVS for my A/D converter (called "my_ADC") and try to
compare the "schematic" and the "extracted" of "my_ADC" it seems to
complain that it cannot find the "schematic" views for the std-cells
(since they only have a "cmos_sch" view!) during schematic netlisting.
During LVS, Cadence tries to netlist both the "extracted" view and the
"schematic" view of "my_ADC". The "extracted" view netlisting of "my_ADC"
succeeds (since the std-cells DO have an "extracted" view) but the
schematic netlisting of "my_ADC" fails (since the std-cells instanciated
inside it only have a "cmos_sch" view, and NO "schematic" view). The LVS
error messages I get from si.log are pasted at the end of this email.

There should be some way of telling LVS to look for the "cmos_sch" view
also while netlisting the "schematic" view of "my_ADC". I would imagine
this could be set in the .cdsenv or the .cdsinit files, but I am not sure
how I would do that. Could someone PLEASE help? Any inputs would be
greatly appreciated.

Thanks,
Sid

Siddharth Devarajan,
Graduate Student - ECSE Dept.,
Rensselaer Polytechnic Institute (RPI), NY,
Tel: (518)-248-7619.


I get the error shown below while running LVS for "my_ADC":
-----------------------------------------------------------

Running simulation in directory: "/home/analogkid/6hp/LVS".

Begin netlist: Jan 18 18:08:27 2005
view name list = ("auLvs" "extracted" "schematic")
stop name list = ("auLvs")
library name = "sid_test"
cell name = "my_ADC"
view name = "extracted"
globals lib = "basic"
Running Artist Flat Netlisting ...
End netlist: Jan 18 18:08:29 2005

Moving original netlist to extNetlist
Removing parasitic components from netlist
presistors removed: 0
pcapacitors removed: 0
pinductors removed: 0
pdiodes removed: 0
trans lines removed: 0
239 nodes merged into 239 nodes


Begin netlist: Jan 18 18:08:29 2005
view name list = ("auLvs" "schematic")
stop name list = ("auLvs")
library name = "sid_test"
cell name = "my_ADC"
view name = "schematic"
globals lib = "basic"
Running Artist Flat Netlisting ...
*WARNING* invalid cell view -- 0(unknown)
*WARNING* invalid cell view -- 0(unknown)
global error:
Cannot find switch master cell for instance I8 in cellView (my_ADC
schematic) from viewlist 'auLvs schematic ' in library 'sid_test'.
*WARNING* invalid cell view -- 0(unknown)
*WARNING* invalid cell view -- 0(unknown)
*WARNING* invalid cell view -- 0(unknown)
global error:
Cannot find switch master cell for instance I5 in cellView (my_ADC
schematic) from viewlist 'auLvs schematic ' in library 'sid_test'.
*WARNING* invalid cell view -- 0(unknown)
*WARNING* invalid cell view -- 0(unknown)
*WARNING* invalid cell view -- 0(unknown)
global error:
Cannot find switch master cell for instance I6 in cellView (my_ADC
schematic) from viewlist 'auLvs schematic ' in library 'sid_test'.
si: Netlist did not complete successfully.
End netlist: Jan 18 18:08:29 2005

Comparison program did not complete.
-------------------------------------------------------------------------

 

[anandganesan@gmail.com]

Does anyone have a code for this already? Please email it to me.
Thanks.

Anand

 

[Graeme Bunyan]

jayl-news@accelerant.net wrote:

This is all with focus-follows-mouse (doesn't matter
if it's sloppy or strict) and click-to-raise.

1) In CDE, click-to-raise means CLICK ON THE
TITLEBAR/FRAME, PERIOD. You can type in
lowered-but-active window and click on buttons
and menus, and it does not raise. This is
correct behavior.

2) In KDE, click-to-raise means CLICK ANYWHERE IN
THE DAMN WINDOW. This is wrong and bad behavior.
Very nasty when you're reading cellnames or
property values off the top window and trying
to open a new cell in a partially-buried library
browser, or paste values in a partially buried
property window. Gag.

Jay,

Sorry to jump into the thread so late, I haven't checked the newsgroup for a
little while.

I'm using KDE3.3.0, and the behaviour you are looking for does exist. The KDE
control centre is almost certainly different on the version you're using (it's
different every time I see it, especially on different distros), but I'll try
to explain how to set this up:

Desktop/Window Behaviour/Focus

This is the tab which sets up the focus policy, such as focus-follows-mouse.
There *is* an option here called "click raise active window", but this is NOT
what you are looking for, since this means that a click anywhere will raise the
window. Make sure that's unchecked.

Desktop/Window Behaviour/Actions

This defines what happens when you click on a window (either the titlebar and
frame, or the window contents). To have it behave as you describe, make sure
that in the "Titlebar & Frame" groupbox, the left button in active window
binding is set to "Raise". Also make sure that, in the "Inactive inner window"
groupbox, the left button binding is set to "Activate and Pass Click".

Hopefully, if these options exist in the version of KDE you're using, this
should give you the behaviour you're looking for...

Regards,
Graeme.