Les instructions spécialisées sont aussi bien plus simples à utiliser qu'un core externe : il suffit d'avoir un compilateur pour générer le bon code.
Pour utiliser un core spécialisé, il faut écrire un driver pour l'OS
Je ne suis pas sûr duquel est le plus simple : modifier le compilo ou l'OS ?...
il faut modifier la façon de travailler de certaine librairie pour transmettre et récupérer les blocs traités.
Effectivement, car tu réutilises l'infrastructure du CPU. Du coup du perd la répartition de ressource et le parallélisme au passage.
Les temps de mise en route ne sont pas nuls,
Effectivement, c'est un handicap.
la gestion d'énergie peut être complexe.
Oui, mais tu as délégué la complexité au CPU, quoi.
Il faut aussi trouver un moyen de partager l'accès à la ressource entre 2 logiciels utilisant la fonctionnalité.
Oui, comme ce qui arrive aujourd'hui avec le multicore (façon NUMA) : la tendance est quand même de gérer aujourd'hui ce genre de complexité correctement car elle est de plus en plus présente partout.
mais la complexité va être dans l'accès à la RAM et/ou à un autre CPU pour des besoins de communication sur IP ou sans fils par exemple.
Ya bien des cartes qui font du RDMA... c'est pas si complexe (et de mieux en mieux intégré dans le noyau ces dernières années ; je ne suis pas utilisateur, je constate juste).
mais finalement on utilise beaucoup de DSP pour ça, car c'est plus simple à utiliser. [...] on peut même utiliser des cpu classique
Tu vois, tu finis par te tirer une balle dans le pieds : inventer des traitements complexes dans un FPGA « pour la vitesse », ça marche pour quelques petits cas particuliers, mais au final le compromis spécialisation finit par casser quand on trouve un entre-deux à peu près correct.
J'ai l'impression même que ces derniers temps, les architectures hybrides ARM avec un Cortex-M secondaire qui map une partie de la RAM remplace les « petits » FPGA pour du traitement temps-réels (car ces CPU « assistants » ne sont pas si ridicule ! Et se programment simplement).
Merci pour les arguments, mais ce ne m'a toujours pas convaincu.
[^] # Re: chip de test
Posté par benoar . En réponse au journal k1g1 : le premier FPGA Libre.... Évalué à 5.
Je ne suis pas sûr duquel est le plus simple : modifier le compilo ou l'OS ?...
Effectivement, car tu réutilises l'infrastructure du CPU. Du coup du perd la répartition de ressource et le parallélisme au passage.
Effectivement, c'est un handicap.
Oui, mais tu as délégué la complexité au CPU, quoi.
Oui, comme ce qui arrive aujourd'hui avec le multicore (façon NUMA) : la tendance est quand même de gérer aujourd'hui ce genre de complexité correctement car elle est de plus en plus présente partout.
Ya bien des cartes qui font du RDMA... c'est pas si complexe (et de mieux en mieux intégré dans le noyau ces dernières années ; je ne suis pas utilisateur, je constate juste).
Tu vois, tu finis par te tirer une balle dans le pieds : inventer des traitements complexes dans un FPGA « pour la vitesse », ça marche pour quelques petits cas particuliers, mais au final le compromis spécialisation finit par casser quand on trouve un entre-deux à peu près correct.
J'ai l'impression même que ces derniers temps, les architectures hybrides ARM avec un Cortex-M secondaire qui map une partie de la RAM remplace les « petits » FPGA pour du traitement temps-réels (car ces CPU « assistants » ne sont pas si ridicule ! Et se programment simplement).
Merci pour les arguments, mais ce ne m'a toujours pas convaincu.