Mosaic consisting of pcells. Parameters of pcell cannot be c

[paul]

This code works fine for cds v5.10.41 but not for cds v6.1.0EA
This code creates a pcell and builds a mosaic consisiting of this pcell
and inserts it into an cellview.
The parameters (w/h) of the pcell can be changed using the property
form (q) in both cds-versions. In cds 6.1 its not possible to change
the parameters of the pcell using this SKILL code. How can this be
done?

pcDefinePCell(
list( ddGetObj("demo") "ask" "layout")
(
(layer "met1")
(width 3.0)
(length 6.0)

) ; end or pcell parameters
let(
() ; no local variables in this example
rodCreateRect(
?name "minMetal"
?width width
?layer layer
?length length
) ; end of rodCreateRect
) ; end of let
) ; end pcDefineP

cv = geGetEditCellView()
master = dbOpenCellViewByType("eltic" "ask" "layout")
mosaic = dbCreateSimpleMosaic(cv master nil 0:0 "R0" 3 2 6 6)
; read
printf("before %L\n" car(mosaic->instanceList)->length )
printf("before %L\n" car(mosaic->instanceList)->width )
; default params evaluate to nil - this is ok.

; change prop using two different methods:
car(mosaic->instanceList)->length = 1.54
widthProp = dbCreateProp(car(mosaic->instanceList) "width" "float"
2.21)

; read again using two different methods:
printf("after %L\n" car(mosaic->instanceList)->length )
printf("after %L\n" dbSearchPropByName(car(mosaic->instanceList)
"width")->value )

/*
expected output: (works properly in cds 5.10.41)
before nil
before nil
after 1.54
after 2.21

output with cds 6.1.0EA (doenst work):
before 6.0
before 3.0
after 6.0
after 3.0

default values are read, but cannot be changed using SKILL
*/

 

[John Gianni]

paul wrote:

This code creates a pcell and builds a mosaic consisting of this pcell
and inserts it into a cellview.

According to my sources, how to handle this situation is well
documented in the 6.1 migration documentation; please obtain the
necessary documentation from your Customer Support representative (they
can ship you limited hard copies if desired).

If necessary, ask your support rep to contact me (not at the spam trap
used for this posting though) to show them how to get you those hard
copies, printed and bound by a private printer I've long ago set up for
a variety of Cadence documents (e.g., the IC51, IC52, and IC61 SKILL
Quick Reference is printed, bound, and shipped by the same publisher as
are the Eaglet RF/AMS/Digital/Memory Test Chip and other complete flow
documents under my control).

Some other comments:

a) Props and parameters are now strongly typed in Virtuoso 61.

b) There is no direct oa equivalent of a mosaicInst in IC61. Instead of
traversing from mosaic to mosaicInst and then updating params, update
the mosaic params directly.

c) In OpenAccess, there are scalar and array insts. In CDB, there are
inst, mosaics and mosaicInsts.

Note:
Your pcell is going in "demo" but you're opening the master from
"eltic".
Virtuoso 6.1 addresses parameters by
car(mosiac~>instanceList)~>master~>parameters~>length = 1.54

John Gianni
--
Absolutely nothing I state here is prior reviewed nor sanctioned by
anyone!

 

[paul]

Thanks John for your reply and trying to help me. I'll find and read
the migration documentation next.

b) There is no direct oa equivalent of a mosaicInst in IC61. Instead of
traversing from mosaic to mosaicInst and then updating params, update
the mosaic params directly.

I tried your proposal to update the parameters directly:

mosaic->length
6.0
mosaic->length = 3.0
mosaic->length
6.0
This doesnt work, the value is not accepted by the system

Virtuoso 6.1 addresses parameters by
car(mosaic~>instanceList)~>master~>parameters~>length = 1.54

Reading the value works fine:

car(mosaic~>instanceList)~>master~>parameters~>length
6.0
car(mosaic~>instanceList)~>master~>parameters~>length = 3.0
car(mosaic~>instanceList)~>master~>parameters~>length
6.0

Setting the value is not accepted using this method either.
Thx and Regards, paul.

 

[Andrew Beckett]

On 18 Oct 2006 16:17:18 -0700, "John Gianni" <dmsflow@yahoo.com> wrote:

paul wrote:
This code creates a pcell and builds a mosaic consisting of this pcell
and inserts it into a cellview.

According to my sources, how to handle this situation is well
documented in the 6.1 migration documentation; please obtain the
necessary documentation from your Customer Support representative (they
can ship you limited hard copies if desired).

If necessary, ask your support rep to contact me (not at the spam trap
used for this posting though) to show them how to get you those hard
copies, printed and bound by a private printer I've long ago set up for
a variety of Cadence documents (e.g., the IC51, IC52, and IC61 SKILL
Quick Reference is printed, bound, and shipped by the same publisher as
are the Eaglet RF/AMS/Digital/Memory Test Chip and other complete flow
documents under my control).

Some other comments:

a) Props and parameters are now strongly typed in Virtuoso 61.

b) There is no direct oa equivalent of a mosaicInst in IC61. Instead of
traversing from mosaic to mosaicInst and then updating params, update
the mosaic params directly.

c) In OpenAccess, there are scalar and array insts. In CDB, there are
inst, mosaics and mosaicInsts.

Note:
Your pcell is going in "demo" but you're opening the master from
"eltic".
Virtuoso 6.1 addresses parameters by
car(mosiac~>instanceList)~>master~>parameters~>length = 1.54

John Gianni

Useful information from John, but I should point out that it is not terribly
sensible asking an open forum like this about pre-release software. As an Early
Adopter customer for IC610, you should follow the agreed support process -
usually with designated AEs in your account team, but could also be via the
usual customer support process.

It's important for Cadence to be able to track adoption issues. This particular
issue should have been covered during the migration training for the beta/early
adopter program, by the way - which perhaps you didn't attend, but somebody in
your company will have done.

Regards,

Andrew.
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.

 

[Bernd Fischer]

And I was wondering were to hell this guy
was receiving 6.1 from!

By the way Andrew is there any official release date so far?

Bernd

 

[Svenn Are Bjerkem]

Andrew Beckett wrote:

It's important for Cadence to be able to track adoption issues. This particular
issue should have been covered during the migration training for the beta/early
adopter program, by the way - which perhaps you didn't attend, but somebody in
your company will have done.

What is so wrong about early adopters asking questions here on those
early versions that probably the whole user community is waiting for
like a child is waiting for Santa? I would not call this anything else
but an alpha or beta trial period. "Everybody" knows that you don't use
alpha versions for production stuff or at least know that he/she is
going to see a lot of trouble.

On the other side, those wondering if they are going to sit down and
invest a lot of time into writing some tool in skill to solve a problem
would probably be more than happy to hear if that problem is solved in
the upcoming release, like I was when I discovered that there is
something called spiceIn in 6.1. Saved me a lot of work.

And that thing about going via AE is something you don't believe
yourself. I solved my problem on how to user spiceIn myself while
feeding a Cadence AE with whatever I did. NO documentation available,
just pure experience and guessing. You can check my service request. It
is in German, but the AE never asked me to write in English for the R&D
to be able to understand what problem I have. It was actually a
time-critical job for me so I didn't even have time to escalate the
problem (Which wouldn't have helped because I would have had to explain
my problem to a thousand interface people). In many other cases I get
solving leads here quicker than from support.

My support chain looks like this:
1. Search on groups.google.com
2. Search on sourcelink
3. Experiment a bit and post a question on groups.google.com
4. When no answer from Groups, send a service request to support
5. Experiment untill I get contact with support (mostly 1 to 2 days)
6. Experiment while I try to explain support what I want to do. (they
love email, I love the phone)
7. While not solved goto 6.
8. When problem solved spend a lot of time grading the support from
cadence in such a way that I get support next time I want support.
(Seems that AE is getting their salary based on those answers.)
9. Store my solution as an answer to myself on groups.google.com so
that it will be available _forever_, and save some other engineers from
going through the same.

--
Svenn

 

[Andrew Beckett]

Svenn,

A quick response here.

On 19 Oct 2006 14:00:59 -0700, "Svenn Are Bjerkem" <svenn.are@bjerkem.de> wrote:

Andrew Beckett wrote:
It's important for Cadence to be able to track adoption issues. This particular
issue should have been covered during the migration training for the beta/early
adopter program, by the way - which perhaps you didn't attend, but somebody in
your company will have done.

What is so wrong about early adopters asking questions here on those
early versions that probably the whole user community is waiting for
like a child is waiting for Santa? I would not call this anything else
but an alpha or beta trial period. "Everybody" knows that you don't use
alpha versions for production stuff or at least know that he/she is
going to see a lot of trouble.

Well, for a start, the point of beta and early adopter phases is to iron out
problems before the whole community sees them. Posting to a forum like this will
not make sure that happens, because it is nothing to do with Cadence. Sure, a
number of us monitor the forum, but this is not an official Cadence support
forum. I am not tasked with doing this as part of my job - I do it because I
feel it is the right thing to do.

Also, I suspect you may be breaking the beta software license agreement (I
don't know for certain) which has various non-disclosure clauses in it, etc.
I don't want to get to prissy about this, but just something ot bear in mind.

On the other side, those wondering if they are going to sit down and
invest a lot of time into writing some tool in skill to solve a problem
would probably be more than happy to hear if that problem is solved in
the upcoming release, like I was when I discovered that there is
something called spiceIn in 6.1. Saved me a lot of work.

We do need to be careful not to announce things too early. There's always a
chance during beta programs that something might get pulled out because it
doesn't work properly, or doesn't have the right use model, etc, etc.
Again, that non-disclosure thing may be important here ;-)

And that thing about going via AE is something you don't believe
yourself.

Huh? I'm an AE. I certainly believe that is the right process. I have been
responsible for CIC customer support in Europe for some time.

I solved my problem on how to user spiceIn myself while
feeding a Cadence AE with whatever I did. NO documentation available,
just pure experience and guessing. You can check my service request. It
is in German, but the AE never asked me to write in English for the R&D
to be able to understand what problem I have. It was actually a
time-critical job for me so I didn't even have time to escalate the
problem (Which wouldn't have helped because I would have had to explain
my problem to a thousand interface people). In many other cases I get
solving leads here quicker than from support.

In beta/early adopter stages, the documentation may not be ready yet. So this
is quite understandable. Also, R&D don't read service requests. If we need to
get R&D involved, a PCR would be filed. And the AE can then write that in
English.

Of course, new software is new to us as AEs too, so we're having to
learn too, and come up to speed with the new features. We have a big
training programme going on now - only selected AEs had limited training
earlier, since there's no point getting material ready too early, when
the software is changing.

And I'm sorry that the support was not as good as you'd have expected.
I will look into the particular case you mention.

I don't want to be too heavy handed about this - I just was advising what
is the _correct_ process.

Regards,

Andrew.

--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.

 

[paul]

Thanks Svenn for your answer.

Btw:
The problem also exists in Cadence version IC OA 5.2.51.500.21 so the
whole discussion about beeing a 'Early Adopter' or a
Santa-waiting-child is useless.

We also reported this problem through the official customer support.
Ill keep you informed when a solution is found.

I want to direct the discussion back to the original problem.
Kind regards, paul.

 

[Svenn Are Bjerkem]

On Oct 20, 10:29 am, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:

And I'm sorry that the support was not as good as you'd have expected.
I will look into the particular case you mention.

I don't want to be too heavy handed about this - I just was advising what
is the _correct_ process.

No need, I have solved the problem for myself, and as soon as 6.1 is no
longer early adopter and somebody is asking about it I will check if it
still applies and then post it, just in case something improves on
spiceIn from now until then.

I was searching on sourcelink today on montecarlo simulation and the
first hit I got was documentation for IC61. How would you as normal
user in a large corporation interpret that? Maybe just like me, that it
is a widely used, new version, and hence a question or two on
comp.cad.cadence cannot harm. Now, I know since a couple of weeks that
IC61 is for early-adopters until end of october or something like that.
I will be a lot more careful in the future.

Regarding the monitoring of this group by Cadence people, I think it is
enough with the few who does. If I get it right from your position
within Cadence and your skills it seems that you are very well suited
to channel important feedback from comp.cad.cadence into the R&D todo
list. When I look back on the few years that I have worked with cadence
software as an end-end-user, I have always had a serious lag on
effective support. You have the ability to "read" a selected user base
opinion and plenty of newbe problems here. The ordinary Cadence user
newer care, he find a workaround and sticks to that for the rest of his
life, never complaining, always focused on getting his job done, and
thus not taking the hassle to go to support with their things.

--
Svenn

 

[Andrew Beckett]

On 20 Oct 2006 04:13:34 -0700, "Svenn Are Bjerkem" <svenn.are@bjerkem.de> wrote:

I was searching on sourcelink today on montecarlo simulation and the
first hit I got was documentation for IC61. How would you as normal
user in a large corporation interpret that? Maybe just like me, that it
is a widely used, new version, and hence a question or two on
comp.cad.cadence cannot harm. Now, I know since a couple of weeks that
IC61 is for early-adopters until end of october or something like that.
I will be a lot more careful in the future.

Actually IC610 was released yesterday (a few days early), so this was probably
a matter of getting the information on sourcelink in readiness.

Regards,

Andrew.
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.

 

[John Gianni]

A good friend of SKILL, Hank, tested the problem and thinks this might
be a bug when working with mosaics (Hank provided the suggestion to
use:
car(mosiac~>instanceList)~>master~>parameters~>length = 1.54

Hank found that it read, but, didn't SET in some cases so he filed a
product change request which I'll forward to the OP via email
separately.

Since this may be a bug, we should let the regular support channels
handle the communications with the Customer from here on in ... I just
wanted folks to know there has been progress behind the scenes as we
take any anomoly seriously.

John Gianni
--
Nohing said here is prior sanctioned by anyone, including my employer!

 

[John Gianni]

John Gianni wrote:

Since this may be a bug, we should let the regular support channels
handle the communications with the Customer from here on in

The PCR is 933682
--
Nohing said here is prior sanctioned by anyone, including my employer!

 

[John Gianni]

John Gianni wrote:

I just wanted folks to know there has been progress behind the scenes
as Cadence takes any anomaly seriously...

The aforementioned Product Change Request (PCR 933682) has been fixed
as of this morning.
10-30-2006 05:34:37 Integration request #150691 has been updated
to status "integrated" for release 6.1.1 buildnum: IC6.1.1.15

For those who wish to test the results, I believe the first IC61
Incremental Software Rollup (ISR) will be on or about November 15th.
Meanwhile, the fix is being tested internally at Cadence.

Thanks for being proactive and for working with Customer Support.
John Gianni
--
Nothing said here is prior reviewed nor sanctioned by anyone but myself!

 

[John Gianni]

paul wrote:

We also reported this problem through the official customer support.
Ill keep you informed when a solution is found.

Hi Paul,

I tried to look up your Customer Support request but could not find it
for some reason.

I had wished to update your support request by email to let Cadence
Customer Support know that the problem you reported was verified by
Hank using the Cadence CDK090 (complete design kit, 90nm) that I build
years ago (partly for this purpose)!

For efficiency, I wanted to update the SR with the PCR that was filed
by Hank on Tuesday the 24th; fixed last Friday the 27th. by R&D; and
integrated today, Monday the 30th by the CM team (and now in the
product validation test phase prior to release in an incremental
software rollup (ISR).

Since I didn't find your service request, would you kindly reply to
your support representative with the information provided here so they
can update the SR and PCR?

Thanks,
John Gianni
--
Nothing I say is prior sanctioned nor reviewed by anyone but myself!