PDK QA

S

SS

Guest
I working on creating a PDK QA

What is the best way to test the following

1. CDF Parameter Callbacks
2. Netlisting

-Sriram
 
On Jul 24, 7:37 am, SS <ssrirami...@gmail.com> wrote:
I working on creating a PDK QA

What is the best way to test the following

1. CDF Parameter Callbacks
2. Netlisting

-Sriram

Hi Sriram,

That's a hard question your asking, this is my attempt

1. It is really hard to check the CDF Parameter Callbacks by an
automatic routine. Mainly because changing the value of an instance
property by skill does not trigger any callback. You can somehow
emulate this behaviour by explicitly invoking the callbacks but then
you need to have something clever since the order of running the
callbacks could have a real impact on the overall results. The best
advice I could give you is to go through the 'Dangers of CDF
Calbacks'. It is an AN written by Andrew. This could give you some
ideas about your stuff.

2. What if you query the cds schematic dabtabase and dump it in a kind
of ASCII table and then compare it versus the spectre netlist you've
created from this database ? You can even add an extra layer where you
check your netlist against what expected by your models cards. You
eventually need to treat some special cases where the one-to-one
mapping is not applicable. bits of perl and skill would be good enough
for this.

These are the few ideas that sprang to my head this evening ;-)

The PDK QA and validation is one of the hardest task to do for a
development team. I've never ever any tool or any magic program/
machine that runs the QA in a fully 100 automated way. The human
intelligence is happily still needed in this area ...

Hope this little helps you :-[

Cheers,
Riad.
 
Thanks Riad,
I agree with you that it can't be 100% automated. Regarding the
netlisting check I planned to so the same. WIll read Andrew's document
on dangers of CDB callback.

-Sriram
 
SS wrote, on 07/25/08 05:36:
Thanks Riad,
I agree with you that it can't be 100% automated. Regarding the
netlisting check I planned to so the same. WIll read Andrew's document
on dangers of CDB callback.

-Sriram
What I usually do is test the callbacks by calling them procedurally (there's a
link to this in my "Dangers of CDF Callbacks" solution on sourcelink).

I can then have SKILL code which places an instances, tries various possible
parameter values, calls the callbacks, and tests that the results are what I
expected.

Cadence also have a package called "STEP" (may not be the correct
capitalization) which can be used for automated PDK testing.

Regards,

Andrew.
 
Thanks Andrew,

-Sriram


On Jul 30, 2:38 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
SS wrote, on 07/25/08 05:36:

Thanks Riad,
       I agree with you that it can't be 100% automated. Regarding the
netlisting check I planned to so the same. WIll read Andrew's document
on dangers of CDB callback.

-Sriram

What I usually do is test the callbacks by calling them procedurally (there's a
link to this in my "Dangers of CDF Callbacks" solution on sourcelink).

I can then have SKILL code which places an instances, tries various possible
parameter values, calls the callbacks, and tests that the results are what I
expected.

Cadence also have a package called "STEP" (may not be the correct
capitalization) which can be used for automated PDK testing.

Regards,

Andrew.
 

Welcome to EDABoard.com

Sponsor

Back
Top