Oula rien à voir. Les cpu softcore sont géniaux pour tout ce qui est "Control lent" et complexe, type méga grosse machine d'état. D'ailleurs d'un point de vue hardware, elle pourrait être plus rapide mais pas forcément plus petit qu'un softcore + son programme. (mon premier stage de conception en 2000 était justement de remplacer une machine d'état par un petit risc, on est passé de 7k portes à 3k.)
Non, je pensais à l'inverse : tu prends un CPU classique Leon ou OpenRisc. Je suis persuadé qu'il existe des opcodes libres pour de futurs extension, ainsi tu rajoutes quelques instructions. Celles-ci sont réalisées par un bloc FPGA dans le CPU qui est à coté de l'ALU et du load/store. En gros, au lieu d'avoir un bloc externe complexe, tu as simplement un nouveau bloc d'opération. Dans ton cas simple, tu peux ainsi faire des pack/unpack dédié pour un processeur réseau par exemple. L'idée est de faire le cœur de calcul dans le FPGA et laisser gérer le reste par le cpu (IO, MUL, LOAD/STORE).
L'énorme contrainte est que ton FPGA doit être assez rapide pour ne pas trop ralentir le reste du CPU. Si ton pack/unpack prend 5 cycles cpu, mais 1 avec ton FPGA, si le FPGA est 5 fois plus lent, c'est inutile.
Je pense toujours qu'une instruction dédiée est toujours plus efficace qu'un "core" externe : pas de communication en plus, pas de code OS spécialisé. Il suffit de faire générer la bonne instruction assembleur par le compilateur. Un "driver" ne serait utile que pour changer le contenu du FPGA.
[^] # Re: chip de test
Posté par Nicolas Boulay (site web personnel) . En réponse au journal k1g1 : le premier FPGA Libre.... Évalué à 4.
Oula rien à voir. Les cpu softcore sont géniaux pour tout ce qui est "Control lent" et complexe, type méga grosse machine d'état. D'ailleurs d'un point de vue hardware, elle pourrait être plus rapide mais pas forcément plus petit qu'un softcore + son programme. (mon premier stage de conception en 2000 était justement de remplacer une machine d'état par un petit risc, on est passé de 7k portes à 3k.)
Non, je pensais à l'inverse : tu prends un CPU classique Leon ou OpenRisc. Je suis persuadé qu'il existe des opcodes libres pour de futurs extension, ainsi tu rajoutes quelques instructions. Celles-ci sont réalisées par un bloc FPGA dans le CPU qui est à coté de l'ALU et du load/store. En gros, au lieu d'avoir un bloc externe complexe, tu as simplement un nouveau bloc d'opération. Dans ton cas simple, tu peux ainsi faire des pack/unpack dédié pour un processeur réseau par exemple. L'idée est de faire le cœur de calcul dans le FPGA et laisser gérer le reste par le cpu (IO, MUL, LOAD/STORE).
L'énorme contrainte est que ton FPGA doit être assez rapide pour ne pas trop ralentir le reste du CPU. Si ton pack/unpack prend 5 cycles cpu, mais 1 avec ton FPGA, si le FPGA est 5 fois plus lent, c'est inutile.
Je pense toujours qu'une instruction dédiée est toujours plus efficace qu'un "core" externe : pas de communication en plus, pas de code OS spécialisé. Il suffit de faire générer la bonne instruction assembleur par le compilateur. Un "driver" ne serait utile que pour changer le contenu du FPGA.
"La première sécurité est la liberté"