Que consomme la génération d'un signal d'horloge?

[invite2fa5ac65]

Bonjour,

Je viens à la recherche d'information car je cherche à comprendre (voir quantifier) la part de consommation de la création d'une horloge dans un microcontrolleur ou un FPGA. Après quelques recherches sur la génération d'horloge externe, j'ai relevé la consommation d'un simple générateur de signal d'horloge comme le CDCS502 de chez TI. Il consomme 26.4mW pour générer une horloge à 20 MHz. Les PLLs faible consommation semblent aussi naviguer dans ces eaux là (e.g. XC25BS3 qui consomme 18 mW pour générer un signal d'horloge à 20 MHz).

Je cherche ce type d'information car je travail sur le développement d'un système faiblement consommant (alimenter en permanence (pas de batterie)). Et je me demande quel est la meilleur façon de générer un signal d'horloge à 30 MHz en réduisant au maximum la consommation. Ce signal d'horloge servira à une lire un signal RZ et demandera donc d'être synchronisé avec l'horloge qui a envoyé le signal (je ne peux pas envoyer ce signal d'horloge!!).

J'envisage donc deux possibilités:

-Régénération du signal d'horloge à partir des données avec un système de "clock recovery".
-Générer un signal d'horloge sur place avec une synchronisation (phase) sur les données.

Je pense utiliser un Igloo nano pour effectuer les fonctions précédentes et gérer la données reçu.

Pourriez-vous m'apporter des informations sur se que consomme la génération d'un signal d'horloge interne(à un µC ou FPGA) ou externe?

J'aimerais bien qu'on parle de la génération d'un signal d'horloge en général (quartz, pll etc..), techniques, consommation.

Merci d'avance.
-----

[bobflux]

Il faut aussi s'intéresser à ce que consomme le circuit qui reçoit cette horloge, même si il ne fait rien. La distribution de l'horloge consomme (il faut charger et décharger les capacités parasites à chaque front) et tout circuit qui reçoit l'horloge va avoir une consommation dynamique. Pour baisser la consommation, si on garde l'horloge, en général on coupe sa distribution dans tout ce qui ne sert pas. Ou bien on utilise une horloge à fréquence plus basse.

Le signal RZ arrive par quel moyen ? câble ?

[invite2fa5ac65]

Merci des précisions, Le signal RZ arrive par fibre optique de 10Km.

Je porte aussi un regard sur la consommation du circuit qui reçoit l'horloge. Cependant, dans un premier temps, je souhaiterais comprendre les technologies utilisées pour générer et distribuer l'horloge. Pourriez vous préciser quels types de composants englobe la fonction de distribution de l'horloge?

Par exemple, dans le cas d'un FPGA (voyons l'igloo de actel), Kit de dévellopement, il y un oscillateur à 20MHz faiblement consommant. Considérez vous que cette oscillateur a la fonction de distribution de l'horloge?

A propos de l'oscillateur, auriez-vous une idée de la consommation de se type de composant? J'ai beau chercher dans la datasheet, je n'ai encore rien trouvé .

Bonne appétit.

[bobflux]

Ton bidule se trouve où ?
Il fait quoi ?
Il est alimenté comment ?
Il passe quelle proportion de temps dans quels états (veille, action, etc) et quelle est la consommation de ces états ? quelles sont les parties qui sont actives selon les états ?

[A voir en vidéo sur Futura]

[invite936c567e]

Bonjour

Connaître la consommation d'un oscillateur, tout seul pris dans son coin et sans indication sur son usage, ça n'a pas vraiment de sens.

On sait assez facilement réaliser des oscillateur à quartz de 30 MHz qui consomment moins de 10 µW (une petite recherche sur Google t'apporterait moult exemples et notes de conception à ce sujet). Mais rien ne dit qu'ils soient adaptés aux circuits qu'ils alimentent ni aux conditions extérieures d'utilisation.

En effet, leur consommation est intimement liée à la technologie des circuits pilotés (consommation dynamique), et dépend également de la précision, de la stabilité et de l'immunité au bruit exigés pour un fonctionnement correct du système.


Bref, on ne peut pas rester dans le vague. Les interrogations de bobfuck sont parfaitement justifiées si l'on veut pouvoir discuter de cette question...

[invitef9ccb542]

Par exemple, dans le cas d'un FPGA (voyons l'igloo de actel), Kit de dévellopement, il y un oscillateur à 20MHz faiblement consommant. Considérez vous que cette oscillateur a la fonction de distribution de l'horloge?

L'oscillateur rentre dans le FPGA certainement par une broche dédiée pour faire du "Global clock" ou de la PLL. C'est le FPGA qui route et donc distribue l'horloge.
Sur le site d'actel il y a un document qui relate les problèmes de consommation vis à vis de l'horloge.
Apparemment actel est assez fort dans ce domaine.

[invite2fa5ac65]

Ton bidule se trouve où ?

A 10 km du second bidule avec lequel il communique.

Il fait quoi ?

Il récupère des données d'un CAN et les envoie vers le deuxième bidule par voie optique

Il est alimenté comment ?

Il est opto-alimenté en permanence. La tension est régulé par un DC-DC.

Il passe quelle proportion de temps dans quels états (veille, action, etc) et quelle est la consommation de ces états ? quelles sont les parties qui sont actives selon les états ?

Il passe tout son temps en action. Pour l'instant, la consommation n'est pas définie car je suis au stade expérimentale (sur papier) et simulation.

En effet, leur consommation est intimement liée à la technologie des circuits pilotés (consommation dynamique), et dépend également de la précision, de la stabilité et de l'immunité au bruit exigés pour un fonctionnement correct du système.

Merci, je vois mieux. Si je comprends bien, l'oscillateur va plus ou moins consommés en fonction du nombre de circuit utilisant cette horloge.

En fonction de ce que dit jlcms et PA5CAL, l'oscillateur de 20MHz ne consomme rien, c'est la PLL et la distribution "global clock" qui vont consommer (en fonction du nombre de circuit qui utilise l'horloge). Est-ce exact?

[bobflux]

Ça sent le capteur sous-marin.

> Il récupère des données d'un CAN et les envoie vers le deuxième bidule par voie optique

La présence d'une FPGA m'incite à penser qu'il va y avoir un ou des ADC rapides, du gros calcul, et un transmetteur optique rapide.
Ce qui m'incite à penser que la puissance consommée par l'oscillateur pourrait être minuscule vis à vis du reste.

Ce qui m'incite à penser que tu n'as pas fait ton budget de puissances...

> Il passe tout son temps en action.

Ce qui m'incite à penser que tu n'as pas étudié quelles parties de ton bidule pouvaient être mises en veille...

> Pour l'instant, la consommation n'est pas définie car je suis au stade expérimentale (sur papier) et simulation.

Alors, tu devrais étudier la consommation de chaque sous-bidule dans ton bidule précisément.
Et connaître la puissance disponible pour alimenter le tout.
Ensuite, fais ton budget de puissances, et regarde si ça va. Si ça va pas, il faut chasser le glouton.

Tu perds ton temps à t'intéresser à la consommation de l'horloge au lieu de faire un bilan global.

> Si je comprends bien, l'oscillateur va plus ou moins
> consommés en fonction du nombre de circuit utilisant cette horloge.

L'oscillateur consomme.
Il drive une trace de circuit imprimé qui est une capacité parasite, à chaque front ça consomme.
Il y a N circuits qui reçoivent l'horloge. Chaque entrée est une capacité parasite.
Chacun de ces circuits fait plus ou moins de trucs à chaque front d'horloge, même si il ne produit aucun travail utile, ça consomme aussi.

Quand on dit "distribution d'horloge" dans un FPGA c'est la même chose que sur un circuit imprimé. Il y a :
- le fait que toutes les traces d'horloge dans la FPGA qui sont drivées sont des capacités parasites qui consomment à chaque front
- le fait que tous les flops et autres bidules dans le FPGA qui reçoivent une horloge consomment beaucoup plus que si ils n'en recevaient pas

[invite2fa5ac65]

Oui, vous voyez juste pour le capteur sous-marin.

La présence d'une FPGA m'incite à penser qu'il va y avoir un ou des ADC rapides, du gros calcul, et un transmetteur optique rapide.
Ce qui m'incite à penser que la puissance consommée par l'oscillateur pourrait être minuscule vis à vis du reste.
Ce qui m'incite à penser que tu n'as pas fait ton budget de puissances...


Ce qui m'incite à penser que tu n'as pas étudié quelles parties de ton bidule pouvaient être mises en veille...

J'ai oublié de préciser que j'ai déjà développé un système qui fonctionne. Il émet des données à 5MHz à base de MSP430(16MHz). La consommation total est 3 fois inférieur au budget disponible .
J'ai donc étudier la consommation de chaque partie. Si tu es intéressé, je devrais sortir un papier d'ici peu et je pourrais te le signaler.

Maintenant, en vue de la marge de puissance restante, je souhaite augmenter le débit d'où l'utilisation du FPGA Igloo. Dans la première version, l'horloge utilisé est celle du µC. Dans la nouvelle version, je souhaite remplacer le MSP430 par le FPGA. D'où l'étude de la consommation de l'horloge et les deux possibilités évoqué avant :

J'envisage donc deux possibilités:

-Régénération du signal d'horloge à partir des données avec un système de "clock recovery".
-Générer un signal d'horloge sur place avec une synchronisation (phase) sur les données.

- le fait que tous les flops et autres bidules dans le FPGA qui reçoivent une horloge consomment beaucoup plus que si ils n'en recevaient pas
Je comprends donc qu'il est important d'isoler de l'horloge les parties du FPGA ainsi que les composants du circuit qui n'en ont pas besoin. Aurez-vous des chiffres pouvant quantifier la consommation (par cm de piste, par valeur de capacité parasite)? Je comprends bien le principe, mais j'ai du mal à quantifier.

[bobflux]

> J'ai oublié de préciser que j'ai déjà développé un système qui fonctionne. Il émet des
> données à 5MHz à base de MSP430(16MHz). La consommation total est 3 fois
> inférieur au budget disponible .

Ouais, mais ça il fallait le dire dans le premier post... ici on est sur un forum, des fois un type arrive pour demander dans quel sens on branche une résistance, donc on peut pas savoir à qui on a affaire ou si c'est du flan ! Donc si tu veux te faire prendre au sérieux il faut envoyer le max d'infos dès le 1er post.

> J'ai donc étudier la consommation de chaque partie.

OK

> Si tu es intéressé, je devrais sortir un papier d'ici peu et je pourrais te le signaler.

Ouais c'est intéressant !

> je souhaite augmenter le débit d'où l'utilisation du FPGA Igloo

Pourquoi une FPGA ? As-tu considéré divers uC low-power mais puissants (divers PIC, Cortex-M, etc) ? Je ne te suggère pas de changer de solution à l'arrache, je mentionne juste qu'il faut considérer toutes les options.

> Régénération du signal d'horloge à partir des données avec un système de "clock recovery".

Normalement tu dois le faire de toutes façons pour pouvoir recevoir les données, il doit y avoir une PLL ou autre dans le récepteur, donc cette horloge est "gratuite" en quelque sorte.
Dans ton 1er post tu dis :

"Ce signal d'horloge servira à une lire un signal RZ et demandera donc d'être synchronisé avec l'horloge qui a envoyé le signal"

Tu as l'horloge qui est extraite du signal entrant (et indispensable à son décodage) mais tu peux aussi avoir une horloge locale. Cependant si l'horloge locale est un oscillateur, elle ne sera pas synchronisée avec le signal entrant (à moins que ce soit un oscillateur contrôlé par une PLL élaborée). Donc tu dois faire le choix : utiliser une seule horloge dérivée du signal entrant (et donc synchronisée) mais cela complique les choses si le décodage du signal entrant est interrompu pour une raison quelconque, ou bien utiliser une horloge locale (oscillateur stable) en plus.

> Aurez-vous des chiffres pouvant quantifier la consommation (par cm de piste, par valeur de capacité parasite)?

Pour ça c'est simple. Pour charger une capacité C de 0 à 3.3V il faut une charge Q=CV, si tu le fais F fois par seconde tu as F*Q coulombs/s, qui sont en fait des ampères...
Les pistes, c'est pas le principal (surtout à 20 MHz). Sur les datasheets des diverses chips on trouve généralement la consommation dynamique en mA/MHz ou bien en équivalent de capacité à charger à chaque front.

Pour ce qui est de ta FPGA, je n'ai jamais utilisé celle-là mais Xilinx fournit un soft pour analyser la consommation en fonction de tout un tas de paramètres, je présume que tu dois en avoir un aussi. tu peux t'en servir pour déjà vérifier si le projet est faisable ou pas avec cette FPGA.

[invite2fa5ac65]

Ouais, mais ça il fallait le dire dans le premier post...

Oups, Désolé.

As-tu considéré divers uC low-power mais puissants (divers PIC, Cortex-M, etc)

Je ne connais que très mal les familles des µCs. Mais je vais étudier cela de plus près. Je lis le sujet intéressant sur ce forum (et l'évocation de débordement ).
Cependant le FPGA Igloo nano propose une consommation très intéressantes et semble défié toute concurrence.

Normalement tu dois le faire de toutes façons pour pouvoir recevoir les données, il doit y avoir une PLL ou autre dans le récepteur, donc cette horloge est "gratuite" en quelque sorte

Qu'entendez vous par gratuite?

Donc tu dois faire le choix : utiliser une seule horloge dérivée du signal entrant (et donc synchronisée) mais cela complique les choses si le décodage du signal entrant est interrompu pour une raison quelconque, ou bien utiliser une horloge locale (oscillateur stable) en plus.


Merci, vous confirmez les conclusions sur lesquelles j'étais arrivées. Je prévois de faire le "clock recovery" avec mon signal de donnée et un FPGA, sans avoir d'oscillateur local. J'ai programmé un code synthétisable sur cyclone II pour vérifier l'idée (Quartus). Cela fonctionne (temps de propagation compris). Je reçois ma donnée, je régénère une horloge synchronisé et je lis ma donnée . Maintenant, la régénération de cette horloge dois surement consommer, mais consomme tels plus que d'utiliser une horloge local seule avec sa synchronisation à la donnée... Une petite idée ?

Le code VHDL synthétisé prend 68 cellules logiques et 25 registres logiques, soit pas grand chose. Il me reste à le vérifier(après l'avoir commandé) sur un Igloo et évaluer sa consommation. La donnée reçu arrive à 30 MHz.

Merci encore pour votre aide précieuse qui m'a permis de m'orienter et de préciser mes choix.

[bobflux]

> Le code VHDL synthétisé prend 68 cellules logiques et 25 registres logiques, soit pas grand chose.

C'est le code complet de toute l'appli ? Effectivement c'est très peu (ça pourrait probablement tenir dans un CPLD)...

J'ai cherché des info sur la conso des Igloo, mais y'a pas grand chose à part ce type là qui donne la conso d'un compteur 32 bits :
http://static.usenix.org/event/hotpo...tml/node9.html

> Qu'entendez vous par gratuite?

Disons, "Gratuite" au sens socialiste, comme l'éducation nationale
Ton récepteur va de toutes façons générer cette horloge, tu es forcé de payer son coût (en énergie, prix du chip...) mais si tu la réutilises, c'est du bonus !

Note que si ton bidule existe en plusieurs exemplaires et qu'ils doivent être synchronisés entre eux, alors utiliser l'horloge venant par la fibre optique résoud le problème.

Par contre si tu as des ADC précis, attention au jitter et bruit de phase sur l'horloge qui peut dégrader la qualité de la conversion.

> Une petite idée ?

Non, aucune idée, ça dépend totalement de ton hardware...

[invite2fa5ac65]

C'est le code complet de toute l'appli ?

Je confirme .

J'ai cherché des info sur la conso des Igloo,

Merci. Pour ce qui passe après il y a cela aussi : Comparaison de la consommation de puissance FPGA Igloo.

(ça pourrait probablement tenir dans un CPLD)

Le Igloo nano de référence AGLN010 est très petit et me fait penser à la capacité d'un CPLD. J'ai hâte de pouvoir vérifier tout ces hypothèses.

C'était un plaisir de parler avec vous.

Bonne continuation.