Getting the Tech file

Guest
Hello,

I am trying to get the manufacturing grid upon set up. I can get it
by hard coding with the two lines below, but at work we use at least
10 different PDKs.

techid=techGetTechFile(ddGetObj("c05ha"))
minGRID=techGetMfgGridResolution( techid )

This returns the manufacturing grid for c05ha process, is there some
kind of variable that is set in Cadence(or wherever) I can use?

Any other solution would be great as well!

Thank you in advance for any help,
Eric
 
eric.d.fitzsimmons@gmail.com wrote, on 02/26/09 14:42:
Hello,

I am trying to get the manufacturing grid upon set up. I can get it
by hard coding with the two lines below, but at work we use at least
10 different PDKs.

techid=techGetTechFile(ddGetObj("c05ha"))
minGRID=techGetMfgGridResolution( techid )

This returns the manufacturing grid for c05ha process, is there some
kind of variable that is set in Cadence(or wherever) I can use?

Any other solution would be great as well!

Thank you in advance for any help,
Eric
Click to expand...
Eric,

techGetTechFile can also be passed a cellView Id.

; get the techid from the cellView in the current window
techid=techGetTechFile(geGetEditCellView())

Does that give what you want?

Andrew.
 
Riad KACED wrote, on 02/26/09 18:17:
Emmm, Andrew was quicker ... as usual :)
Click to expand...
I only beat you by 5 minutes... so it was close!

Andrew.
 
Hi Eric,

You are pretty much doing the right thing, I mean the skill function
that returns te techFileId is 'techGetTechFile'. This function returns
the database identifier of the technology file attached to the
specified DFII library or
cellview. In other words, you don't need to give the name of the
techLib itself
There is an example where I extract the manufacturing grid from the
current cellView. It does work regardless the PDK:

cv = geGetEditCellView()
mfgGrid = techGetMfgGridResolution(techGetTechFile(cv))

Hope this helps,
Riad.
 
On Feb 26, 12:39 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Riad KACED wrote, on 02/26/09 18:17:

Emmm, Andrew was quicker ... as usual :)

I only beat you by 5 minutes... so it was close!

Andrew.
Click to expand...
Riad one by a nose :)

Yes, that works beautifully and finishes a script I was working on.

It must be good Thursday for me at least.

Thank all of you,
Eric
 
On Feb 26, 12:39 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Riad KACED wrote, on 02/26/09 18:17:

Emmm, Andrew was quicker ... as usual :)

I only beat you by 5 minutes... so it was close!

Andrew.
Hello,
Click to expand...

That doesn't seem to work. I am using in a skill script that is in
my .cdsinit file, so there isn't a cell opened.
I am not sure that is a clear way of explaining it. Code is below.

Thank you both for answering!
Eric



techid=techGetTechFile(geGetEditCellView())
minGRID=techGetMfgGridResolution( techid )

procedure( OneManGridMoveRelativeUP();use users y, zero out x with var
ZeroX
let((i)
foreach(i geGetSelectedSet()
if( geIsFigPartiallySelected(i) then ;( i ~>
shape || i ~> path ) then
leStretchShape( i list( ZeroX
OneManGridY ) geGetSelSetFigPoint( i ) t )
else
dbMoveFig( i nil list( list( ZeroX
OneManGridY ) "R0" ) )
printf("You have moved objects up %L" OneManGridY)
)
)
)
)


procedure( OneManGridMoveRelativeDOWN(); use users y with a minus,
zero out x with var ZeroX
let((i)
foreach(i geGetSelectedSet()
if( geIsFigPartiallySelected(i) then ;( i ~>
shape || i ~> path ) then
leStretchShape( i list( ZeroX -
OneManGridY ) geGetSelSetFigPoint( i ) t )
else
dbMoveFig( i nil list( list( ZeroX -
OneManGridY ) "R0" ) )
printf("You have moved objects down %L" OneManGridY)
)
)
)
)

procedure( OneManGridMoveRelativeRIGHT()
let((i)
foreach(i geGetSelectedSet()
if( geIsFigPartiallySelected(i) then ;( i ~>
shape || i ~> path ) then
leStretchShape( i list( OneManGridX
ZeroY ) geGetSelSetFigPoint( i ) t )
else
dbMoveFig( i nil list( list
( OneManGridX ZeroY ) "R0" ) )
printf("You have moved objects right %L" OneManGridX)
)
)
)
)

procedure( OneManGridMoveRelativeLEFT()
let((i)
foreach(i geGetSelectedSet()
if( geIsFigPartiallySelected(i) then ;( i ~>
shape || i ~> path ) then
leStretchShape( i list( -OneManGridX
ZeroY ) geGetSelSetFigPoint( i ) t )
else
dbMoveFig( i nil list( list( -
OneManGridX ZeroY ) "R0" ) )
printf("You have moved objects left %L" OneManGridX)
)
)
)
)



hiSetBindKeys( "Layout" list(
list("Shift<Key>Up" "OneManGridMoveRelativeUP()")
list("Shift<Key>Down" "OneManGridMoveRelativeDOWN()")
list("Shift<Key>Right" "OneManGridMoveRelativeRIGHT()")
list("Shift<Key>Left" "OneManGridMoveRelativeLEFT()")
))
 
Riad KACED wrote, on 02/27/09 10:21:
Hi Eric,

Yes, this does not work because the geGetEditCellView() command
returns ‘nil’ as no cell is being edited.
The only way I could see to make your skill code PDK-independent is to
define a variable that holds the techLib (or any other lib attached to
that techLib). This could be either a Skill or a Unix variable defined
in your initialisation scripts.
Andrew (if he has not already replied by the time I’m typing) may have
better ideas 时

Cheers,
Riad.
Click to expand...
Sorry, bit slow this morning (was busy over on Designer's Guide, and doing the
day job...).

The other thing is to look up the minGRID inside your OneManGridMoveRelativeUP
function, rather than putting it in a global variable. That way your code will
work even if you're working on multiple technologies (with different grids) at
the same time...

Global variables are a bad thing...

Regards,

Andrew.
 
Hi Eric,

Yes, this does not work because the geGetEditCellView() command
returns ĄĽnilĄŚ as no cell is being edited.
The only way I could see to make your skill code PDK-independent is to
define a variable that holds the techLib (or any other lib attached to
that techLib). This could be either a Skill or a Unix variable defined
in your initialisation scripts.
Andrew (if he has not already replied by the time IĄŚm typing) may have
better ideas ƒş

Cheers,
Riad.
 
Eric,

hiSetBindKeys( "Layout" list(
list("Shift<Key>Up" "OneManGridMoveRelativeUP()")
list("Shift<Key>Down" "OneManGridMoveRelativeDOWN()")
list("Shift<Key>Right" "OneManGridMoveRelativeRIGHT()")
list("Shift<Key>Left" "OneManGridMoveRelativeLEFT()")
))
Click to expand...

When these functions are called, it's impossible to know beforehand what technology data the current
cell is using.

Making a global setting would work, but it's not a generic solution. Sometimes, you can have
multiple technologies in a same session... (and why look into the techfile if it's hard-coded, you
can as well define the manufacturing grid by hand...)

The correct way to do it is (according to myself) to use geGetCellViewWindow() only when the
function is invoked.

The most flexible way is to parameterize the functions:
procedure( XXX( @optional (cv geGetCellViewWindow()) )
when( dbIsId(cv)
tf = techGetTechFile(cv)
;;; .... etc ....
) ; when
); procedure


PS: be careful with geGetEditCellView() ; the behavior can be somewhat unexpected when working on a
read-only cellview. That would refer to the cellview of another window (the edited one, I suppose).


Stéphane
 
S. Badel wrote, on 02/27/09 11:22:
Eric,


hiSetBindKeys( "Layout" list(
list("Shift<Key>Up" "OneManGridMoveRelativeUP()")
list("Shift<Key>Down" "OneManGridMoveRelativeDOWN()")
list("Shift<Key>Right" "OneManGridMoveRelativeRIGHT()")
list("Shift<Key>Left" "OneManGridMoveRelativeLEFT()")
))



When these functions are called, it's impossible to know beforehand what
technology data the current cell is using.

Making a global setting would work, but it's not a generic solution.
Sometimes, you can have multiple technologies in a same session... (and
why look into the techfile if it's hard-coded, you can as well define
the manufacturing grid by hand...)

The correct way to do it is (according to myself) to use
geGetCellViewWindow() only when the function is invoked.

The most flexible way is to parameterize the functions:
procedure( XXX( @optional (cv geGetCellViewWindow()) )
when( dbIsId(cv)
tf = techGetTechFile(cv)
;;; .... etc ....
) ; when
); procedure


PS: be careful with geGetEditCellView() ; the behavior can be somewhat
unexpected when working on a read-only cellview. That would refer to the
cellview of another window (the edited one, I suppose).


Stéphane
Click to expand...
Hi Stephane,

That's not quite right...

The two functions are:

geGetWindowCellView() (not geGetCellViewWindow())
geGetEditCellView()

geGetCellViewWindow() returns the windowId for a given cellView, rather than the
cellView for a given windowId...

The difference between the "Window" and "Edit" is nothing to do with it being
read only. geGetWindowCellView() gives you the cvId of the cellView displayed in
the current (or specified) window, whereas geGetEditCellView() gives you the
cvId of the cellView being edited/read in the current (or specified) window.

Normally they return the same thing, but the exception comes when you're using
edit in place. If using edit-in-place, geGetEditCellView() returns what you're
editing, whereas geGetWindowCellView() returns the context cellView (i.e. the
outer cellView which the edited cellView is placed in).

So nearly always you want geGetEditCellView().

If the cellView is open readonly, geGetEditCellView() still returns it, because
it's the one that the "editor" is working on.

Regards.

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)
 
Andrew, thanks for the details.

geGetWindowCellView() (not geGetCellViewWindow())
Click to expand...
This was definitely a mistake, due to my writing on-the-fly. I intended to write geGetWindowCellView().

If the cellView is open readonly, geGetEditCellView() still returns it,
because it's the one that the "editor" is working on.
Click to expand...
That's good to know. I had spotted some strange behavior and my guess was that it was due to the
cell view not being "edited". It was probably due to an edit in place.


Stéphane
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top