Migration d'un design pour un nouveau processus, au niveau du tableau de bord

L

lagos.jl

Guest
Salut à tous!

Je voudrais vous demander votre avis sur la façon la plus simple de la migration d'un
toute la conception analogique d'une technologie à une autre
un, au niveau du tableau de bord (c'est-à-dire, pas de disposition en cause vues
que ce soit).La situation est la suivante.

J'ai développé une plus ou moins grande bibliothèque dont la conception analogique
contient des dizaines de cellules (environ 80), et qui comprend tout à fait
7-8 sur les niveaux de la hiérarchie (c'est-à-dire, des plus proches de atomical
le haut-niveau).À ce point nous ne sommes intéressés que sur le grand
comportement de l'architecture, et donc la conception a été achevée
seulement au niveau du tableau de bord.Heureusement, le dessin ou modèle est constitué
uniquement des transistors NMOS et PMOS (pas de résolution,
des casquettes, etc), qui appartiennent
à la vanille, saveur de transistors CMOS 0.35um processus.A côté
les MOSFET, les composants autres que les sources actuelles sont idéales,
utilisées pour la modélisation de la polarisation.De plus, toutes les instances de ces
transistors ont leur W et L valeurs définies comme des variables, et dans le
ensemble de la conception il
n'existe pas spécifié de valeurs de tout genre.Le montant total des
nombre de variables dans la hiérarchie finale est seulement d'environ 12 (y compris
variables de biais des tensions et des courants).

Jusqu'ici,
tout va bien.J'ai validé avec succès les performances de la
susmentionnées conception, et maintenant
j'ai besoin d'évaluer la performance
change lors de la migration de l'architecture à un procédé CMOS 180um.
De toute évidence, la meilleure façon d'accomplir ce qui serait
à faire une copie de l'ensemble de la bibliothèque, le joindre à la nouvelle
la technologie et ensuite de modifier manuellement la plupart des cellules pour remplacer atomique
tous les NMOS et PMOS de l'ancien processus de leur
homologues dans les nouvelles technologies.Cependant, j'avais essayé, et
faire des grandes piles, des résultats assez peu pratique et très tendance à
l'erreur humaine.Qui plus est, selon les résultats de la
migré conception, il est très probable que nous serons intéressés à
plus de la migration à d'autres technologies (par exemple CMOS 90nm), ainsi
l'augmentation du manuel de l'effort de façon exponentielle.Il est donc clair
que cette approche manuelle à la cellule édition
n'est pas une solution viable pour
migration de l'ensemble de l'architecture.

Prenant tout cela en considération, je suis désespérément à la recherche d'un
autre façon de traduire la conception dans un plus ou moins automatisée
mode.Je pense tout ce qui est nécessaire à faire est d'éditer le atomique
netlists
de la cellule pour faire le remplacement approprié pour chaque
transistor par exemple, une tâche qui pourrait être mis en œuvre par le code.
Cependant, je
n'ai jamais travaillé sérieusement sur le code en Cadence,
et je
n'ai aucune idée sur ce que d'éditer, de la langue à utiliser, ni où
pour commencer.

Je suis tout à fait positif que je peux accomplir ces objectifs, mais
j'ai besoin d'aide
pour commencer.S'il vous plaît laissez-moi savoir si vous avez une idée sur la manière de
approche de la solution à ce problème.Toute aide est appréciée!

Merci pour les idées, et désolé pour le long post!

<img src="http://www.edaboard.com/images/smiles/icon_smile.gif" alt="Sourire" border="0" />Observe,

 
Eh bien, je pense que je
vais avoir d'y voir clair par moi-même.Merci quand même, attendons pour écrire la solution ...si jamais je réussi à trouver un!

<img src="http://www.edaboard.com/images/smiles/icon_neutral.gif" alt="Neutre" border="0" />

Ajouté après 28 minutes:OK,
j'ai enfin trouvé un moyen de nature de le faire.Je suis en train d'utiliser les compétences de code pour analyser le cas le mois (copies) de l'original (l'ancien procédé) de cellules vues, et puis je les remplacer par le transistor de cellules appartenant à la nouvelle procédure.

Par exemple:

; Ouvrir la cellview
cv = dbOpenCellViewByType ( "MyLibrary" "Mycell" "schéma" néant "a")
, Marcher à travers tous les cas, de remplacer les transistors
foreach (inst cv ~> cas où ((inst ~> libname == "OldProcessLibrary" & & inst ~> cellName == "OldMosTransistorCellname") dbSetInstHeaderMasterName (inst ~> instHeader "NewProcessLibrary" "NewMosTransistorCellname" "symbol_compatible")))
; Enregistrer
et fermer
dbSave (cv)
dbClose (cv)

Le gros inconvénient de cette approche est
qu'elle ne fonctionne que si l'amende pour les symboles de transistors dans les deux processus sont pin-compatible avec le respect de la taille (sinon, le remplacer dans le cas des cellules transformées apparaissent mal placées et les terminaux mis-connectés).Dans la (très probable)
où ils ne sont pas compatible broche à broche (qui a effectivement été mon cas), on doit créer une seconde, compatible broche à broche symbole vue pour les transistors de la nouvelle procédure (que
j'ai appelé "symbol_compatible" sur le code ci-dessus) et le remplacement de l'utilisation de ce symbole de modification de vues.

Jusqu'à présent, il semble que la solution fonctionne et je réussi à simuler la transformation des schémas avec le nouveau processus de transistors et de leur modification "symbol_compatible" point de vue.Je
n'ai pas vérifié la conception de haut niveau encore, et je doute ne sais pas si cette astuce fonctionne
lorsqu'on fait des choses plus complexes, tels que LVS.

<img src="http://www.edaboard.com/images/smiles/icon_question.gif" alt="Question" border="0" />Eh bien, comme toujours, les idées
ou commentaires sur ce sujet sont plutôt les bienvenus!

<img src="http://www.edaboard.com/images/smiles/icon_biggrin.gif" alt="Very Happy" border="0" />Observe,

Jorge.

 

Welcome to EDABoard.com

Sponsor

Back
Top