|
Bas de page | |
---|---|
Auteur | Sujet : Adaptation SystemC en VHDL |
Publicité | Posté le 08-03-2012 à 13:36:13 |
h3bus Troll Inside | Quelle expérience as-tu avec VHDL? La description fonctionnelle est très mal adaptée à une implémentation hadware. Dans ce cas je génèrerai deux blocs séquencés, un générant une solution, l'autre vérifiant la solution. Ces blocs accédant à une SRAM (un tableau sera très certainement implémenté en SRAM si chaque accès est correctement séquencé) En tous les cas ce n'est pas évident à faire... Message édité par h3bus le 08-03-2012 à 13:41:02 --------------- sheep++ |
Gefroren | Salut, merci pour la réponse rapide.
|
h3bus Troll Inside | Pour l'instant le problème n'est pas le VHDL mais la représentation hardware du circuit et les machines d'état à réaliser. Je te conseille de décomposer ton algorithme en machines d'état, puis de coucher sur une feuilles des modules simples hardware qui s'interfacent avec tes machines d'état. C'est une gymnastique complètement différente de la programmation itérative. Essaie d'oublier le concept de variable pour voir ça comme des registres, les boucles doivent être implémentées avec des machine d'état et des compteurs. ça ne t'aide pas beaucoup, je sais, essaie de ne traiter qu'une partie du problème pour commencer. Je vais essayer d'y réfléchir de mon côté mais je ne te donnerai pas la solution, d'abord parce que je ne connais pas la technique et peut me planter, et aussi par ce que c'est contraire aux règle du forum. Bon courage, n'hésite pas à poster ton avancement même si tu penses que c'est naze, on pourra te réorienter si tu ne sembles pas être dans la bonne voie! Message édité par h3bus le 09-03-2012 à 12:54:19 --------------- sheep++ |
Gefroren | Ok, merci
|
h3bus Troll Inside | Vu l'algo tu ne pourras surement pas te passer des appels récursifs.
--------------- sheep++ |
Gefroren | Suite à ce que tu m'as dit, j'ai fait une machine d'états de l'algo, dis-moi ce que t'en penses : |
h3bus Troll Inside | Les choses commencent à se poser. Une petite remarque avant de passer à la LIFO, l'état TEST est complexe, il nécessite à lui seul un parcours du tableau pour vérifier la validité des valeurs en place. Cela dit je te conseille de mettre ça de côté, je vois plusieurs implémentation pour cette fonction, plus ou moins compliquées et rapides. Concernant la LIFO, je perçois son utilisation ainsi: Par ce procédé on implémente mode de fonctionnement récursif, avec des machines d'état et une lifo Du coup il faudrait un autre état après test, disons UNSET pour réaliser cet algorithme. Un petit détail, 0 ne représente pas une case vide (car 0 est une valeur possible d'une case). Il faut donc une valeur qui représente une case vide, 10 par exemple... Voilà, je reviens de soirée un petit peu arrosée, excuse l'éventuel manque de clarté de mes propos Message édité par h3bus le 23-03-2012 à 01:21:06 --------------- sheep++ |
Gefroren | Bon, en fait 0 représente bel et bien une case vide puisque sinon on aurait 10 valeurs différentes (de 0 à 9) à remplir dans 9 cases (ça devait être du fait de l' "arrosage" )
Message édité par Gefroren le 28-03-2012 à 16:06:28 |
h3bus Troll Inside | Bon le code de la pile devrait synthétiser.
--------------- sheep++ |
Publicité | Posté le 25-03-2012 à 21:23:45 |
Gefroren | Ah ben si déjà la pile ça va, c'est déjà bien. Je savais que l'autre partie ne pouvais pas passer, c'était un premier essai.
|
h3bus Troll Inside | Oops j'avais pas vu effectivement ta machine d'état est cadencée, mais pas le reste (il y a beaucoup de boucle combinatoires, il faudrait cadencer le process complet ou utiliser des next_xxx pour beacoup de signaux);
--------------- sheep++ |
Gefroren | Je m'execute, tient pourquoi c'est mieux le rising edge plus que le clk'event and clk='1' ?
|
h3bus Troll Inside | L'avantage n'est pas gigantesque, mais c'est une bonne habitude à prendre: Effectivement par next_xxx j'entends bien le signal combinatoire qui entre dans la bascule. Message édité par h3bus le 27-03-2012 à 15:18:41 --------------- sheep++ |
Gefroren | Bon j'ai essayé de tout cadencer, j'ai donc mis des blocs if reset ... aux endroits où j'appelais des fonctions. Pour le reset je savais pas trop, donc lorsque le reset passe à un on retourne à l'IDLE. Voilà dis moi ce que t'en pense.
Message édité par Gefroren le 28-03-2012 à 16:05:55 |
h3bus Troll Inside | C'est trop compliqué pour que je t'indique ou sont les soucis, problème par problème. Je te conseille de commencer par faire un seul petit bout simple (et sans utiliser les fonctions), je t'aiderai à corriger et améliorer la syntaxe puis on rajoutera petit bout par petit bout. Dis toi bien que si ça ne synthétise pas, il y a un soucis (et là ça va pas synthétiser). Donc simplifie, poste un code (utilise les balise de code "ada", de mémoire ça marche sur HFR et c'est très proche de VHDL), mais seulement si ça synthétise (ou si tu ne sais pas pourquoi ça ne synthétise pas) à partir de là je pourrai t'aider. Courage, ce que tu essaies de faire est compliqué, même pour un as du VHDL, mais avec de la méthode tu vas y arriver. Message édité par h3bus le 27-03-2012 à 19:48:41 --------------- sheep++ |
Gefroren | Arf... Ok, merci pour ton aide en tout cas.
|
h3bus Troll Inside | Cf bbcode, bon c'est pas idéal mais ça marchotte...
--------------- sheep++ |
Sujets relatifs | |
---|---|
Adaptation auto. Page Web / Résolution | question sur la description structurelle en vhdl |
SystemC | [VHDL] Question concernant les case avec des if |
VHDL - Contrôleur de feux | [VHDL/Verilog] Les FPGA et leur programmation |
Problème de gestion de la liaison série RS232 en VHDL | programmer en SystemC |
Adaptation d'un code Javascript | [Resolu]Adaptation programme Windows vers Linux |
Plus de sujets relatifs à : Adaptation SystemC en VHDL |