cell libraries and place and route

Hi,

CDF is the _c_omponent _d_escription _f_ormat
and it is a database which holds parameters for your
components.
See 'Component Description Format User Guide' of
cdsdoc the Cadence documentation.

Symbols can be generated form text via the
_t_ext to _s_ymbol _g_enerator TSG.
See 'Virtuoso Schematic Editor User Guide,
Appendix B Text-to-Symbol Generator'.

Hope this references will help you.

Bernd

KemperR@ee.nec.de wrote:
Hi All,

I have a big library (XML based data) and want to create
basic symbols for schematic entry out of it.

My target is cadence CDF.

1) Where can I get CDF spec ?

2) Is there any approach known yet ?

Thanks for your feedback

Rolf
Click to expand...
 
Rolf,

I can imagine two approaches how to get a netlist
out of XML and into Cadence DFII.
Unfoutunatly I don't know XML good enough.

1. Convert you XML to a text based netlist
in CDL format, it's Spice like .
Then read in CDL into DFII.
This could be done with the GUI or also in a
batch process.
2. Use SKILL to generate your Schematics.
With SKILL you can read in text files and postprocess
them e.g to draw Schematics.

For both approches you nedd to have a Symbol library
with CDF for you components first.

So the flow has to look like
- Create Symbols + CDF out of XML
- Create Netlis/Schematic out of XML


Bernd

KemperR@ee.nec.de wrote:
Bernd,

thank you very much for the quick reply. Your hint is of big help
already.

In consequence, would it mean that there is also a way to create a
complete netlist which holds all the instanciated symbols and the wires
?
I could imagine that I craete a kind of initial netlist out of my xml
too.

Thanks a lot

Rolf
Click to expand...
 
Bernd Fischer > wrote:
So the flow has to look like
- Create Symbols + CDF out of XML
- Create Netlis/Schematic out of XML
Click to expand...
I did some work on generating schematics from spice netlist at my
previous company. In order to get a feeling for how you can do things,
check out the cdfDump() and the dbWriteSkill() functions.

The fist one will write out the CDF of a cell you choose to file and the
second one will convert a schematic view into SKILL code needed to
restore that cellview. You will see that there is quite a lot of
bookkeeping do do when you want to create a schematic via SKILL, but it
is manageable. I needed a couple of days to have a working script, but I
don't have access to it any longer.

I would guess that you would write your converter in some scripting
language with a module for XML like perl, tcl or python. I used Tcl
because I could use the tcllib struct to do most of the bookkeeping.

--
Svenn
 
On 29 Jun 2005 20:29:34 -0700, cadrjr@hotmail.com wrote:

I'm using PSD 15.0 on an Concept/Allegro "Reference Design" ,which
obviously SHOULD work but doesn't ...

When I try to Export Physical to Allegro, Netrev gives me the following
error (many times) ...

It looks as if my configuration is constrained to a Part Name of 31
characters ? I have set Part Type Length to 50 in Setup.

Anybody got any ideas ?

RJR.
Click to expand...
Part Type isn't the same as Part Name.
I think you're fooked. Living with such limitations since the days of
ValidGED, you learn to be frugal with characters and inventive with
abbreviations.

For your example, I'd go with TP_PTH_51-0184-001 or similar...

Cheers


------ Oversights/Warnings/Errors ------


#1 ERROR(302) Device library error detected.

Problems with the name of device 'TE
ST_POINT_THRU_HOLE-51-0184-001': 'name too long'.

Device 'TEST_POINT_THRU_HOLE-51-0184-00' has library errors. Unable to
transfer to
Allegro.

....... etc.
Click to expand...
 
There is a 'storeDefault' attribute in the CDF that
defines wether a properties with default values are stored on an
instance's CDF initially. If not, then these properties do not exist
initially - only after they get a value will they exist.

to find out, use

value = cdfFindParamByName(cdfGetInstCDF( inst ) "MYPROP" )~>value

if you know the parameter is a cdf parameter.

stéphane


Sefano Zanella wrote:
Hi,

I am using dbFindProp to figure out whether a certain property exists
in an instance of a cell. If the property exists, and it contains the
default value, dpFindProp will not find it. Example: Capacitor C3,
property c. In my case, 1p (the default in the CDF form) will make
dbFindProp return nil, but 1.000p will not. I can not find any reference
of this in the documentation.

Is there something I am missing? I am sorry that I can not provide a
test case.

Any comments?
Thanks,
Stefano
Click to expand...
 
dbFindProp will only ever return instance properties. If the instance property
has the same value as the CDF default, and that CDF property has the
storeDefault not set to yes, then it may get removed from the instance.The
reason for the "may" is that if there is a slight difference it won't, and
also it depends on what is doing the modification. If it is an edit properties
form, then it would normally get removed, but SKILL code may not.

Fundamentally, instance CDF is formed by the overlay of the cell CDF with
instance properties.

There is no bug/feature in dbFindProp - it works exactly as it is supposed to.

Regards,

Andrew.

On Tue, 05 Jul 2005 00:00:10 -0700, Sefano Zanella <stefanoDOTzanella@pdf.com>
wrote:

Hi Stephane,

Thanks a lot for your answer. I thought it could be something like
this. However, this is inconsistent with the following case (which shows
the same behaviour):
1) change the default value of a property to something else -
dbFindProp returns the property
2) change the property value to the default -> dbFindProp returns nil

Please note that you have to use the default "string" value. For
instance, for a resistor from the analog lib, the default is "1K Ohms".
The value "1.000K Ohms" will not show the problem. Turning it back to
"1K Ohms" will show the problem again.

Regards,
Stefano

S. Badel wrote:
There is a 'storeDefault' attribute in the CDF that
defines wether a properties with default values are stored on an
instance's CDF initially. If not, then these properties do not exist
initially - only after they get a value will they exist.

to find out, use

value = cdfFindParamByName(cdfGetInstCDF( inst ) "MYPROP" )~>value

if you know the parameter is a cdf parameter.

stéphane


Sefano Zanella wrote:

Hi,

I am using dbFindProp to figure out whether a certain property exists
in an instance of a cell. If the property exists, and it contains the
default value, dpFindProp will not find it. Example: Capacitor C3,
property c. In my case, 1p (the default in the CDF form) will make
dbFindProp return nil, but 1.000p will not. I can not find any
reference of this in the documentation.

Is there something I am missing? I am sorry that I can not provide a
test case.

Any comments?
Thanks,
Stefano
Click to expand...
 
Hi,

Now I understand. Thanks a lot! So it is a feature.
Then I have a follow up question: how do I figure out the list of
properties that exist in the CDF form but contain the default "value"
(i.e. a value that is really identical to the default)?

Thanks a lot,
Stefano


Andrew Beckett wrote:
dbFindProp will only ever return instance properties. If the instance property
has the same value as the CDF default, and that CDF property has the
storeDefault not set to yes, then it may get removed from the instance.The
reason for the "may" is that if there is a slight difference it won't, and
also it depends on what is doing the modification. If it is an edit properties
form, then it would normally get removed, but SKILL code may not.

Fundamentally, instance CDF is formed by the overlay of the cell CDF with
instance properties.

There is no bug/feature in dbFindProp - it works exactly as it is supposed to.

Regards,

Andrew.

On Tue, 05 Jul 2005 00:00:10 -0700, Sefano Zanella <stefanoDOTzanella@pdf.com
wrote:


Hi Stephane,

Thanks a lot for your answer. I thought it could be something like
this. However, this is inconsistent with the following case (which shows
the same behaviour):
1) change the default value of a property to something else -
dbFindProp returns the property
2) change the property value to the default -> dbFindProp returns nil

Please note that you have to use the default "string" value. For
instance, for a resistor from the analog lib, the default is "1K Ohms".
The value "1.000K Ohms" will not show the problem. Turning it back to
"1K Ohms" will show the problem again.

Regards,
Stefano

S. Badel wrote:

There is a 'storeDefault' attribute in the CDF that
defines wether a properties with default values are stored on an
instance's CDF initially. If not, then these properties do not exist
initially - only after they get a value will they exist.

to find out, use

value = cdfFindParamByName(cdfGetInstCDF( inst ) "MYPROP" )~>value

if you know the parameter is a cdf parameter.

stéphane


Sefano Zanella wrote:


Hi,

I am using dbFindProp to figure out whether a certain property exists
in an instance of a cell. If the property exists, and it contains the
default value, dpFindProp will not find it. Example: Capacitor C3,
property c. In my case, 1p (the default in the CDF form) will make
dbFindProp return nil, but 1.000p will not. I can not find any
reference of this in the documentation.

Is there something I am missing? I am sorry that I can not provide a
test case.

Any comments?
Thanks,
Stefano
Click to expand...
 
Then I have a follow up question: how do I figure out the list of
properties that exist in the CDF form but contain the default "value"
(i.e. a value that is really identical to the default)?
Click to expand...
here's a suggestion

defProps = setof(
cdfParam
cdfGetInstCDF( inst )~>parameters
!dbFindPropByName( inst cdfParam~>name
)

cheers,

stéphane
 
Hi Stephane,

Do you think that dbGet would work in this case? I see solution
1844658 on sourcelink that says that it shouldn't work (using 5033) but
it seems to work for me regardless of the settings of the environment
variable. Am I missing something or does it really work?

Thanks a lot!
Stefano

PS: I am using both 5033 and 5141

S. Badel wrote:
Then I have a follow up question: how do I figure out the list of
properties that exist in the CDF form but contain the default "value"
(i.e. a value that is really identical to the default)?


here's a suggestion

defProps = setof(
cdfParam
cdfGetInstCDF( inst )~>parameters
!dbFindPropByName( inst cdfParam~>name
)

cheers,

stéphane
Click to expand...
 
What should happen is that with Analog and compatibility CDS_Netlisting_Mode
settings, then doing:

inst~>paramName

should get the instance property value if defined, or the CDF parameter
default if not defined. This is equivalent to:

dbGetq(inst paramName)

which in turn is equivalent to:

dbGet(inst 'paramName)

In Digital CDS_Netlisting_Mode (or if CDS_Netlisting_Mode is not set), then it
should never get the CDF parameter default. You can check the netlisting mode
by using the SKILL function:

cdsGetNetlistMode()

Regards,

Andrew.

On Wed, 06 Jul 2005 07:10:02 -0700, Sefano Zanella <stefanoDOTzanella@pdf.com>
wrote:

I have tried with digital and Digital. They both work. Or I screwed up
my test cases :)
Stefano

Sefano Zanella wrote:
Let me check: I am unfamiliar with digital :) lowercase or uppercase?
Thanks,
Stefano
S. Badel wrote:

Hum... Apparently Analog and Compatibility modes are equal with
respect to
CDF. Does it work when set to Digital?

stéphane


Sefano Zanella wrote:

Hi Stephane,

Do you think that dbGet would work in this case? I see solution
1844658 on sourcelink that says that it shouldn't work (using 5033)
but it seems to work for me regardless of the settings of the
environment variable. Am I missing something or does it really work?

Thanks a lot!
Stefano

PS: I am using both 5033 and 5141

S. Badel wrote:

Then I have a follow up question: how do I figure out the list of
properties that exist in the CDF form but contain the default
"value" (i.e. a value that is really identical to the default)?





here's a suggestion

defProps = setof(
cdfParam
cdfGetInstCDF( inst )~>parameters
!dbFindPropByName( inst cdfParam~>name
)

cheers,

stéphane
Click to expand...
 
Hi Andrew,

Thanks a lot. Got it!

Regards,
Stefano

Andrew Beckett wrote:
What should happen is that with Analog and compatibility CDS_Netlisting_Mode
settings, then doing:

inst~>paramName

should get the instance property value if defined, or the CDF parameter
default if not defined. This is equivalent to:

dbGetq(inst paramName)

which in turn is equivalent to:

dbGet(inst 'paramName)

In Digital CDS_Netlisting_Mode (or if CDS_Netlisting_Mode is not set), then it
should never get the CDF parameter default. You can check the netlisting mode
by using the SKILL function:

cdsGetNetlistMode()

Regards,

Andrew.

On Wed, 06 Jul 2005 07:10:02 -0700, Sefano Zanella <stefanoDOTzanella@pdf.com
wrote:


I have tried with digital and Digital. They both work. Or I screwed up
my test cases :)
Stefano

Sefano Zanella wrote:

Let me check: I am unfamiliar with digital :) lowercase or uppercase?
Thanks,
Stefano
S. Badel wrote:


Hum... Apparently Analog and Compatibility modes are equal with
respect to
CDF. Does it work when set to Digital?

stéphane


Sefano Zanella wrote:


Hi Stephane,

Do you think that dbGet would work in this case? I see solution
1844658 on sourcelink that says that it shouldn't work (using 5033)
but it seems to work for me regardless of the settings of the
environment variable. Am I missing something or does it really work?

Thanks a lot!
Stefano

PS: I am using both 5033 and 5141

S. Badel wrote:


Then I have a follow up question: how do I figure out the list of
properties that exist in the CDF form but contain the default
"value" (i.e. a value that is really identical to the default)?





here's a suggestion

defProps = setof(
cdfParam
cdfGetInstCDF( inst )~>parameters
!dbFindPropByName( inst cdfParam~>name
)

cheers,

stéphane
Click to expand...
 
Hum... Apparently Analog and Compatibility modes are equal with respect to
CDF. Does it work when set to Digital?

stéphane


Sefano Zanella wrote:
Hi Stephane,

Do you think that dbGet would work in this case? I see solution 1844658
on sourcelink that says that it shouldn't work (using 5033) but it seems
to work for me regardless of the settings of the environment variable.
Am I missing something or does it really work?

Thanks a lot!
Stefano

PS: I am using both 5033 and 5141

S. Badel wrote:

Then I have a follow up question: how do I figure out the list of
properties that exist in the CDF form but contain the default "value"
(i.e. a value that is really identical to the default)?



here's a suggestion

defProps = setof(
cdfParam
cdfGetInstCDF( inst )~>parameters
!dbFindPropByName( inst cdfParam~>name
)

cheers,

stéphane
Click to expand...
 
On 8 Jul 2005 13:41:27 -0700, roddyalan@gmail.com wrote:

Hi,

I understand that Procedures use only local variables. How do I
return a variable back to the program.

Regards
Alan Rodricks
Click to expand...
You could read the manual. Start with the SKILL User Guide.

procedures do _not_ only use local variables, and the return value of a
procedure is the last thing it computes in the body of the procedure. Commonly
a procedure is of this form:

procedure(RTMbeforeAsking(a b c)
let((d)
d=a+b+c
MYglobal=d-10
printf("Sum is %n\n" d)
d*3
) ; let
) ; procedure

In this case, d is a local variable, MYglobal is a global variable, and the
return value of the function is the result of d*3 - since it is the return
value of the let (as the last thing computed) and consequently the return
value of the procedure.

Apologies for the function name; I couldn't resist ;-)

Andrew.
 
Should be possible with,

outfile( S_fileName [t_mode] )
=> p_outport/nil

Opens an output port ready to write to a file.

fileSeek(
p_port
x_offset
x_whence
)
=> t | nil

Sets the position for the next operation to be performed on the file opened on a
port. The position is specified in bytes.

fprintf(
p_port
t_formatString
[ g_arg1 ... ]
)
=> t

Writes formatted output to a port.

fileTell(
p_port
)
=> x_offset

Returns the current offset in bytes for the file opened on a port.

kirscher_jerome@yahoo.fr wrote:
Hello,
I would like to simplify the realisation of a documentation. The idea
is to create windows in the cadence tool, with different fields inside
(using Skill). That´s not a problem. But the next step would be to
fill a Frame Maker template with the informations that will be written
in these fields. Has anyone a hint to do that? Thanks!
Click to expand...
 
:) Read The Manual B4 Asking...

acturally, it's a hard job to completed all manual ... sigh, at least, i
didnt finished yet.
 
Hi,


Dracula comes to Cadence with the merger form ECAD in 88 I guess,
so it is the dinosaur of the verification tools.
Dracula is a standalone product and there is also a UI for the Cadence
Design Framework available.

Diva is integrated in Cadence Design Framework and can only
operate on that database not on GDSII.
It's suitable for cell level verification or greater 0.35u processes.

Vampire was the experiment to combine Dracula and Diva, but it was
not accepted by the customers.

And finally Assura is the successor of Vamipre, can operate on both
Cadence Design Framework and GDSII databases.
Can run standalone as well there is an integration into Cadence
Design Framework. It's suitable for new submicron processes.

So if you have the free decision to use any of this tools
I'd suggest Assura.

Bernd

camelot wrote:
Sorry if I annoy you with this strange questions but someone could
explain to me what are the real differences among this verification
Cadence tools: Dracula, Vampire, Diva and Assura.
I took a look at the Cadence site and even on Vampire, I'm was not able
to find any useful information.
A little of history is always useful to better understand what rules
this environment.

Thank,

Camelot
Click to expand...
 
In article <1121355761.189970.91600@g47g2000cwa.googlegroups.com> "Collin Weiss" <collin.weiss@silabs.com> writes:
A let() does not return a value but can modify a global variable.
Click to expand...
It surely does. All Skill forms evaluate to some value unless an error occurs
during evaluation or execution. For example:

x = let( () 3 + 4 )

will result in x having a value of 7.

A prog() allows you to do a "return(some_value)" and the end of the
prog().

procedure(someFxn(arg1 arg2)
prog( (var1 var2 var3)
;;body of fxn
return(some_value)
);;end prog
);;end procedure
Click to expand...
prog() is much more heavyweight and not necessary unless you need to return()
out of the middle of a routine.

The following:

procedure(someFxn(arg1 arg2)
let( (var1 var2 var3)
;;body of fxn
some_value
);;end let
);;end procedure

will have the same result without the overhead required for prog().

-Pete Zakel
(phz@seeheader.nospam)

Murphy's Seventh Collary: Every solution breeds new problems.
 
On 14 Jul 2005 08:42:41 -0700, "Collin Weiss" <collin.weiss@silabs.com> wrote:


A let() does not return a value but can modify a global variable.

A prog() allows you to do a "return(some_value)" and the end of the
prog().

i.e.

procedure(someFxn(arg1 arg2)
prog( (var1 var2 var3)
;;body of fxn
return(some_value)
);;end prog
);;end procedure
Click to expand...
I'm sorry, but this is wrong. A let() DOES return a value. It returns the
value of the last thing computed.

Everything in SKILL returns a value. It's a functional language - everything
is function, and everything has a return value.

prog() just allows you to use spaghetti programming by returning early from a
function.

Your function could have been just as easily implemented as:

procedure(someFxn(arg1 arg2)
let((var1 var2 var3)
;; body of let
some_value
) ; let
) ; procedure

In older versions, prog() used to be a lot less efficient than let(). Since
the byte-code compiler (4.3 - aka 9301, I think) the difference is now
negligible. So now the main reason for using prog() would be because you
either want to return early from the body of the prog(), or because you want
to (horror!) use goto.

Regards,

Andrew.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top