J'ai bosser chez freescale (puis motorola). Et déjà, ton ARM c'est un magnifique IP, fourni par ARM. C'est justement le boulot d'un Freescale ou d'un TI que de prendre un assemblage d'IP et de les fondre. Après les autres IP... bah y en a des tonnes, beaucoup viennent de la maison, d'autres vienne de l'extérieur. Ca dépend du marché. On prend l'IP d'un controleur UART qui vient d'une boite externe parce qu'elle coute pas cher et que ca couterait plus cher à développer, on prend le controleur DMA maison,... Et on concoit un nouveau processeur. En gros, c'est comme ça que ça marche (le plus long c'est l'étape de placement).
Les boites qui viendent de l'IP, eux, sont chargés de concevoir la boite de A à Z, regarde les IO, optimiser le path en nombre de transistor, gérer l'autonomie.
C'est schématique, mais en gros, il faut savoir qu'un fondeur comme TI ou Freescale reçoi un IP de la part de ARM, par exemple, et se débrouille pour le placer sur son Soc. IP qui peut etre sous forme de code source, ou de chip synthétisé (selon le contrat). Faire causer tout ce petit monde est un énorme boulot, évidement. Et gérer le power consumption de tout le monde est encore plus ENORME.
Concernant les routines d'accélérations dont l'on discute, je n'ai pas le "source" des processeurs en questions, et savoir s'il y en a ou pas pour une DCT par exemple, excusez moi, mais on s'en contre fous. Ce qui importe c'est ce que nous fourni le toolkit du DSP.
Car IP ou pas, la plupart du temps le fondeur (TI, Freescale,...) fourni un ensemble de librairie optimisées pour certains traitements. Dont tu n'as pas les sources, évidement. En ce moment, ne pas mettre de routines d'accélération H.264 est suicidaire sur le marché. Routine qui tourne principalement sur le DSP et qui peut, en interne, utiliser un IP d'accélération de DCT par exemple (c'est tout a fait envisageable, même si peu probable).
Si tu n'utilises leur lib optimisé, tu dois redévelopper en code DSP, ce qui n'est pas une mince à faire. C'est ça qui est important. Qu'il y ait un IP dédié H.264 ou potentiellement réutilisable pour un autre codec, s'il n'est pas accessible car caché derriere des miriades de registres non documenté, bah je n'en vois pas l'intéret.
Quant à motorola (de bons souvenirs d'ailleurs), effectivement on cause à un DSP ou à un ARM sans voir ce qu'il y a derriere. Et ce n'est pas à eux de fondre des IP.
[^] # Re: ...
Posté par Stibb . En réponse au journal Dear Google,. Évalué à 4.
J'ai bosser chez freescale (puis motorola). Et déjà, ton ARM c'est un magnifique IP, fourni par ARM. C'est justement le boulot d'un Freescale ou d'un TI que de prendre un assemblage d'IP et de les fondre. Après les autres IP... bah y en a des tonnes, beaucoup viennent de la maison, d'autres vienne de l'extérieur. Ca dépend du marché. On prend l'IP d'un controleur UART qui vient d'une boite externe parce qu'elle coute pas cher et que ca couterait plus cher à développer, on prend le controleur DMA maison,... Et on concoit un nouveau processeur. En gros, c'est comme ça que ça marche (le plus long c'est l'étape de placement).
Les boites qui viendent de l'IP, eux, sont chargés de concevoir la boite de A à Z, regarde les IO, optimiser le path en nombre de transistor, gérer l'autonomie.
C'est schématique, mais en gros, il faut savoir qu'un fondeur comme TI ou Freescale reçoi un IP de la part de ARM, par exemple, et se débrouille pour le placer sur son Soc. IP qui peut etre sous forme de code source, ou de chip synthétisé (selon le contrat). Faire causer tout ce petit monde est un énorme boulot, évidement. Et gérer le power consumption de tout le monde est encore plus ENORME.
Concernant les routines d'accélérations dont l'on discute, je n'ai pas le "source" des processeurs en questions, et savoir s'il y en a ou pas pour une DCT par exemple, excusez moi, mais on s'en contre fous. Ce qui importe c'est ce que nous fourni le toolkit du DSP.
Car IP ou pas, la plupart du temps le fondeur (TI, Freescale,...) fourni un ensemble de librairie optimisées pour certains traitements. Dont tu n'as pas les sources, évidement. En ce moment, ne pas mettre de routines d'accélération H.264 est suicidaire sur le marché. Routine qui tourne principalement sur le DSP et qui peut, en interne, utiliser un IP d'accélération de DCT par exemple (c'est tout a fait envisageable, même si peu probable).
Si tu n'utilises leur lib optimisé, tu dois redévelopper en code DSP, ce qui n'est pas une mince à faire. C'est ça qui est important. Qu'il y ait un IP dédié H.264 ou potentiellement réutilisable pour un autre codec, s'il n'est pas accessible car caché derriere des miriades de registres non documenté, bah je n'en vois pas l'intéret.
Quant à motorola (de bons souvenirs d'ailleurs), effectivement on cause à un DSP ou à un ARM sans voir ce qu'il y a derriere. Et ce n'est pas à eux de fondre des IP.