Naviguer dans l’édition de schémas - partie 1

1.    Constat et objectifs

Pour avoir encadré en projet de grands débutants (étudiants mécaniciens n’ayant que des connaissances de base en électronique et en lecture de schéma), j’ai pu constater que dessiner correctement le schéma d’un circuit même simple est loin d’être intuitif. On peut citer dès cette première étape de conception les erreurs suivantes :

• placement maladroit des composants ;

• création de symboles basés directement sur le brochage des composants et non sur une décomposition fonctionnelle (en particulier entrées à gauche et sorties à droite) ;

• connexion systématique par des fils.

Tous ces réflexes concourent à rendre le schéma inutile ou tout du moins illisible, rendant sa vérification délicate avec les risques que cela implique au moment de la réalisation du circuit imprimé.

Or, un bon schéma doit :

• être agréable à lire (clarté des connexions) pour éviter les risques d’erreur ;

• permettre de distinguer les différentes fonctions d’un circuit imprimé (cf. notion de room pour le PCB) ;

• spécifier les contraintes à appliquer sur le routage de certaines équipotentielles (nets) ;

• être aussi détaillé que possible pour se suffire à lui-même (en synthétisant les informations utiles d’une datasheet d’un composant : rappel d’une formule relative aux composants passifs associés à un circuit intégré par exemple) ;

• ne pas lésiner sur les informations utiles au niveau du système (variantes possibles avec les composants non placés – not fitted, fourniture de chronogrammes pour le séquençage d’alimentations, etc.).

Remarque : Un schéma lisible doit non seulement aider à la réalisation d’un PCB immédiatement après sa création mais il doit pouvoir être exploité le plus facilement possible) plusieurs années après pour des mises à jour du produit ou pour une réutilisation de certains éléments dans de nouveaux projets.

Ce sujet étant relativement vaste, cet article se limitera à l’analyse des briques de base (section 2) ainsi qu’à la structuration (section 3) en plusieurs pages d’un circuit électronique complexe (flat vs hierarchical design) puis au référencement des liens entre pages de schéma (section 4). Les autres points évoqués tels que les spécifications de contraintes de routage seront quant à eux traités dans un prochain article.

2.    Outils disponibles

2.1.    Bases

En dehors des quelques difficultés initiales évoquées dans le paragraphe précédent (création de symboles non fonctionnels car orientés « footprint » et interconnexions utilisant de manière systématique des fils allant d’une broche à une autre), il convient de noter que les solutions les plus simples sont aussi les plus lisibles :

• limiter un schéma (que l’on pourra définir par un groupe de composants reliés par des fils) à une fonction simple (cf. figure 1) ;

• plusieurs fonctions liées peuvent être placées sur une page mais les interconnexions entre elles doivent se faire par « NetLabels » ou « ports » (cf. figure 2), les premiers étant nativement non typés tandis que les seconds permettent au choix de spécifier entrées, sorties, entrées/sorties ou signaux non typés ;

• les alimentations doivent systématiquement employer autant de symboles dédiés que nécessaires (cf. figure 3) ;

• éviter des connexions ambigües (cf. figure 4).

^{Figure 1 – Exemple d’une fonction simple}

^{Figure 2 – Interconnexion par ports (à gauche) ou par définition d’une équipotentielle (à droite)}

^{Figure 3 – Symboles disponibles de masses (à gauche) et de tensions d’alimentation (à droite)}

 

^{Figure 4 – Par prudence, éviter les connexions en croix…}

Un deuxième niveau de difficulté réside ensuite dans la clarté des interconnexion entre ces schémas (à l’aide des outils de la figure 3 mais aussi de ceux qui sont présentés à la sous-section suivante – 2.2). En effet, on constate qu’il existe différentes façons (valables et lisibles) d’aboutir au même résultat. Néanmoins, pour atteindre la meilleure efficacité, il est utile de comprendre la philosophie sous-jacente à chaque approche/outil afin d’identifier leur cadre d’application « optimal ».

2.2.    Interconnexions

Avant d’approfondir la méthodologie de création de schémas d’un système complexe (en tout cas réclamant plusieurs pages de schémas), il convient de définir deux notions très générales dans les logiciels de CAO électronique (fil et bus) ainsi qu’une spécificité d’Altium Designer (la notion de harness). Une tâche importante consiste ensuite à nommer ces connexions (cf. figure 5) :

• le fil (ou wire représenté par un trait fin) représente la forme la plus évidente de connexion électrique puisqu’il s’agit d’une connexion unique (entre deux broches de composants ou plus) : on peut lui donner un nom avec un NetLabel même si ce n’est pas obligatoire ;

• le bus (représenté par un trait épais) représente un groupe de fils que l’on a associé généralement pour des raisons fonctionnelles (bus d’adresse, bus de données, bus de contrôles) : on lui donne un nom avec un NetLabel (par exemple Bus[7..0] pour indiquer qu’il est constitué de 8 fils) et ce nom se répercute ensuite sur tous les fils constitutifs (Bus0, Bus1, Bus2, …) ;

• le harness (littéralement harnais en français), est quant à lui, un groupe de fils « hétérogènes » que l’on a choisi de regrouper pour des raisons pratiques (comme un bus) mais que l’on souhaite pouvoir nommer de manière indépendante.

^{Figure 5 – Nommage de fils, bus et harness}

Remarque : Un port peut être connecté à un fil, un bus ou un harness. Dans les deux premiers cas, il est de couleur jaune (par défaut) tandis que dans le dernier, il apparaît en bleu clair (couleur de fond standard du harness entry - cf. figure 6).

3.    Conception hiérarchique vs conception à plat

3.1.    Deux approches mais un objectif unique de lisibilité

Ce sujet, déjà traité dans différents articles tels que [1] ou encore sur ce site [2], concerne deux approches de structuration de schémas que sont :

• la conception à plat (flat design) pour laquelle un projet est constitué de plusieurs pages de schémas juxtaposés ;

• la conception hiérarchique (hierarchical design) pour laquelle les différents schémas constitutifs d’un projet peuvent être imbriqués les uns dans les autres et sont, de ce fait, hiérarchisés ;

L’avantage évident de cette deuxième approche (en plus de son adaptation au travail collaboratif évoqué dans [1] et [2]) est de présenter dans un document (page) maître la description globale (cf. figure 6) du système en faisant apparaître ses briques de base qui font ensuite l’objet de pages distinctes (cf. figure 8).

 

^{Figure 6 – Exemple de conception hiérarchique sous Altium Designer}

Toutefois, ceci peut aussi être mis en œuvre dans une conception à plat comme le montre la figure 7. Il suffit en effet d’inclure en début de projet une « pseudo-page » de schéma dans laquelle une analyse fonctionnelle est effectuée en renvoyant bloc par bloc à une page de schéma. Néanmoins, il faut alors admettre que la mise en évidence des signaux à chaque interface d’un bloc à un autre n’est pas aussi naturellement obtenue et qu’une part du travail doit être dupliquée pour obtenir un résultat exploitable : chaque modification (ajout ou suppression d’un signal entre deux blocs) doit non seulement être répercutée sur les schémas décrivant lesdites fonctions mais elle doit aussi être transcrite dans l’analyse fonctionnelle proposée en début de projet : cette double tâche n’est alors pas automatisable car cette description est purement visuelle et n’a aucune signification pour le logiciel de CAO (Altium Designer en l’occurrence mais cela reste vrai pour tout autre logiciel – tout du moins à ma connaissance).

^{Figure 7 – Analyse fonctionnelle en introduction d’une conception à plat}

Cette réticence à utiliser pleinement les blocs hiérarchiques (avec leurs ports d’E/S dénommés Sheet entries”) réside dans la problématique des références croisées (abordées à la sous-section 4.2.) qui, dès lors que le projet est imprimé sur feuille ou tout du moins transcrit en PDF, sont les seuls outils permettant de “suivre une connexion entre pages”. Or, les références indiquées dans le cas d’une représentation hiérarchique s’avèrent gênantes par rapport à une approche à plat, limitant l’approche hiérarchique à des cas d’applications spécifiques tels que celui présenté à la sous-section suivante.

3.2.    Un apport incontestable de l’approche hiérarchique

Un bénéfice clair de la conception hiérarchisée réside dans la possibilité de dupliquer une fonction (typiquement pour créer un système multi-voies comme par exemple l’acquisition de signaux analogiques dans un système audio stéréo ou même un oscilloscope). On peut voir à la figure 8 un exemple de mise en œuvre. Il s’articule autour :

• d’une appellation « REPEAT(…) » du bloc permettant de spécifier un nombre de voies identiques à créer ;

• d’un bus dont on extrait un fil unique pour une entrée (on procède de même pour une sortie).

^{Figure 8 – Illustration d’une conception multi-voies par bloc hiérarchique}

Là encore, une façon d’obtenir le même résultat avec une conception à plat consiste simplement à effectuer un copier-coller de la page de schéma associée à une voie mais il faut reconnaître que cette manière de procéder s’avère moins « élégante » et n’offre pas tout à fait les mêmes avantages au moment du placement et du routage dans la partie « Layout ». On notera d’ailleurs que ce « copier-coller » est aussi possible avec les blocs hiérarchiques comme le montre le schéma de la figure 9.

^{Figure 9 – Illustration du « copier-coller » avec les blocs hiérarchiques}

Le point important à noter ici est qu’un bloc hiérarchique est caractérisé par deux paramètres qui sont :

• son désignateur (Designator – ici IOx où x prend les valeurs A, B, C…) ;

• le nom de fichier associé (fichier du schéma au format .SchDoc – ici PortIO.SchDoc).

Il suffit alors de créer autant de blocs avec des désignateurs différents ayant attaché au même fichier (et donc au même schéma) pour créer autant de copies de la fonction décrite que nécessaire.

4.    Référencement et numérotation des pages

4.1. Interconnexions et portées des références

De manière générale, toutes les connexions vues à la figure 2 ainsi que les symboles d’alimentations de la figure 3 peuvent être vues comme des variables dans un programme informatique : il est alors important d’identifier leur portée (locale ou globale) pour connaître avec précision les interactions/interférences possibles entre schémas.

Dans le cas des alimentations, il est souhaitable que ces symboles et leurs noms aient une portée globale car cela évitera d’avoir à dispatcher des alimentations entre différents blocs hiérarchiques : il suffit d’utiliser un même symbole dans chacune des pages d’un projet pour qu’elles y soient toutes connectées.

Dans le cas des ports (et cela est valable aussi pour les symboles “Offsheet”), la portée est locale : on pourrait assimiler ces “variables” aux arguments (entrées) ainsi qu’aux valeurs de retour (sorties) d’une fonction dans un langage de programmation évolué (comme le C, le Java, etc.).

En ce qui concerne les NetLabel, il est prudent de les définir localement dans le contexte d’un projet collaboratif voire même avec un concepteur unique afin d’éviter des interconnexions non désirées entre deux équipotentielles distinctes si celles-ci avaient été malencontreusement nommées de la même manière dans deux pages différentes

Bien évidemment, ces recommandations ne sont que le fruit d’une expérience personnelle. En tout état de cause, l’utilisateur devra effectuer un choix suivant les options définies dans la commande Project > Project Options… et plus précisément dans l’onglet Option (rubrique “Net Identifier Scope”) présenté à la figure 11.

^{Figure 11 – Configuration des portées associées à chaque type d’interconnexion}

Remarque : Comme cela est expliqué dans la documentation du logiciel (Project Options - Options), dans le cas “Automatic (Based on project contents)” :

• si des blocs hiérarchiques sont présents dans la page principale (Top sheet), le mode Hierachical est appliqué (connexions entre blocs par ports uniquement exceptées les alimentations définies globalement) ;

• Si des ports (sans blocs hiérarchiques) sont présents; le mode Flat est appliqué (ports globaux uniquement) ;

• Sinon, le mode Global est appliqué (ports et netlabels globaux).

4.2.    Références croisées des ports

Pour pouvoir attribuer des références de ports exploitables, il faut que le projet soit d’abord compilé (Project > Compile PCB Project [Nom_projet]) et ensuite, on peut ajouter (ou supprimer) les références de pages associées aux ports avec les commandes Reports > Port Cross Reference > Add to / Remove From… (qui peuvent s’appliquer au choix sur le projet entier - Project - ou sur une seule page - Sheet). Le résultat par défaut est alors celui de la figure 12 où l’on peut voir non seulement le nom de la page mais aussi une référence de localisation au sein de la page.

 

^{Figure 12 – Référence croisée par défaut}

Remarque : Dans le cas d’un conception hiérarchique, les références associées aux ports présents dans les pages “filles” conduisent invariablement vers la page “mère” (top sheet). La lecture en PDF ou sur papier est alors gênée par cette étape intermédiaire et conduit souvent à une utilisation limitée des blocs hiérarchiques dans les projets complexes.

5.    Conclusion et perspectives

Dans cet article, nous avons vu tout d’abord les éléments de base constitutifs d’un schéma (connexions entre circuits par fils ou groupes de fils – bus et harness) ainsi que l’organisation générale d’un ensemble de pages rassemblant l’ensemble des schémas d’un circuit complexe. Il ressort de ces éléments quelques règles et choix à adopter pour produire efficacement des schémas qui sont lisibles (donc vérifiables, exploitables et maintenables). Dans le prochain article, nous traiterons des contraintes de routage (DRC, paires différentielles, contraintes de largeurs de pistes, etc.) ainsi que des informations utiles à incorporer dans les schémas déjà été évoquées en introduction (formules de choix des composants, caractéristiques de filtres analogiques, puissance des alimentations, timing de mise en marche et d’extinctions de ces alimentations, etc.).

Lire la partie 2: 

Références

[1]    Flat versus hierarchical PCB design – which is best?, Designlines, Automotive designline, EETimes, https://www.eetimes.com/author.asp?section_id=36&doc_id=1285266# 

[2]    En quoi la conception hiérarchique de schémas peut-elle vous aider à créer vos futurs schémas de circuits imprimés ?, Rachel Chiem, Ressources Altium, https://resources.altium.com/fr/capture-de-sch%C3%A9mas/en-quoi-la-conception-hi%C3%A9rarchique-de-sch%C3%A9mas-peut-elle-vous-aider-%C3%A0-cr%C3%A9er-vos-futurs-sch%C3%A9mas-de-circuits-imprim%C3%A9s