TICS - The Integrated Circuit Simulator

Un petit projet sur lequel je bosse, qui permet d’interpréter des circuits logiques facilement a partir de bêtes images bitmaps.

J'ai documenté tout le projet sur github ICI.

Quelques exemples visuels:
Un compteur binaire qui affiche la valeur hexa sur un afficheur 7-segment:


Une RAM de 64 octets:


Une grosse RAM de 1ko:
https://i.imgur.com/jxnkkHN.gif

Les circuits sont de simples images avec des code couleurs spécifiques.
Par ex un compteur comme celui du gif (mais qui utilise des blocs de mémoire a la place des ou en cascade):


L'interpreteur est dispo pour linux/windows: https://github.com/onidev/TICS/releases

Si vous faites des circuits cool hésitez pas a les poster ou a les pull sur github

C'est vraiment abouti !
Tu l'utilises à des fins de vérification de tes propres circuits ou tu as une autre idée en tête ?

Dans l'idée, c'est juste un test pour voir si je pourrais intégrer ça dans centauri sous forme d’électronique bas niveau (facultative, couplée a l'electronique haut niveau).
En l'état le système bien que performant n'est pas viable, il faut encore que je fasse un système de compilation et que j'ai un proof of concept assez gros (genre un petit ordinateur programmable 8 bit conçu avec) pour faire mes tests. Car dans centauri on pourrait se retrouver avec des centaines de simulations simultanées...

Par contre le système ne prend pas en compte plusieurs choses comme les décalages temporels donc en théorie on ne peut pas l'utiliser pour une application réelle.
C'est vraiment juste sous forme de jeu, comme the powder toy, mais pour la logique combinatoire :p

Multiplication et division 8bits:

C'est assez magnifique! J'adore voir les animations!

Une ALU (Unité arithmétique et logique) 8 bits, qui permet de faire (presque) tous les calculs de base:


Je vais pouvoir commencer les choses sérieuses avec ça

Mon premier chipset programmable (pas super utile, mais fonctionnel):


Le plus dur était surtout de faire tout tenir ensemble, gérer les sleeps et le fetch correctement.
Prochaine étape: ajouter des registres (afin de rendre les calculs un peu plus utiles) et des sauts conditionnels.

Un nouveau chipset plus élaboré:


Plus qu'a ajouter du branching et j'aurais un truc Turing complet a priori.

C'est vraiment cool!

L’exécutable fonctionne très bien sous linux.
Pourquoi ne donner que l’exécutable et pas les sources?
ça serait difficile de le faire fonctionner avec WebAssembly sur une page web?

Merci :p

C'est simple, le git est fait pour les circuits, pas le logiciel. En fait les circuits ont pris vraiment beaucoup de temps a être designé, et le code est pas vraiment intéressant, c'est implémentable en 2-3h si on a une classe d'image et un workflow de base.
Et le programme est fait avec mon workflow personnel du coup il ne pourra pas être compilé vu que je ne le distribue pas (bien que ça doit pas être dur a porter sur SDL2).
Enfin je pourrais toujours poster un snippet si ça t’intéresse, mais c'est pas vraiment la partie centrale du truc.

Pour un export web je pense pas qu'il y ai de soucis. Mais comme c'est juste un interpréteur sans édition c'est pas très intéressant pour le moment.
Je travaille petit a petit sur un éditeur complet, je pense que je me pencherais sur l'export web quand il sera fini, la ce sera bien plus intéressant.

Sinon hier j'ai fait ma première chipset turring complete (si on omet la limite de mémoire actuelle):

Petite démo avec la suite de Fibonacci qui se calcule dessus: https://i.imgur.com/I6tdx8A.gif

Je retravaillerais l'architecture pour ajouter un carry flag, et la multiplication 8 bit (qui est un peu chiante car elle doit output dans 2 registres, vu que le résultat est en 16 bits).
Avec un peu plus d'instructions et de registres on pourra commencer a programmer des choses intéressantes avec.


Mais pour vous donner un peu une idée au niveau de la suite, quand l'éditeur de circuit logiques sera finis, il y aura un éditeur de circuits électroniques ou l'on pourra utiliser ses puces sous forme de boîtiers DIP (avec les I/O), des protocoles de communication entre les chipsets (comme I2C), un assembleur universel avec un interpréteur C intégré pour pouvoir créer ses propres assembleurs, et ainsi pouvoir coder ses chipsets personnalisés facilement (actuellement je rentre tout en binaire directement dans la cellule de mémoire, mais ce sera pas possible une fois la puce "crée" dans son boîtier DIP, il faudra lui envoyer le code).
Une fois tout cela finis ça me permettra de faire un jeu complet et ludique pour apprendre les bases de la logique combinatoire en situation relativement "réelle", mais aussi certains aspects de l’électronique (au niveau de la prog des puces et leur communication).

Bref, y a encore pas mal de taf au niveau soft (faire les GUI etc), mais y a aussi beaucoup de taf encore au niveau du design des circuits logiques.
Il faut que je fasse des protocoles de communication, que je crée des architectures pratiques a programmer (j'aimerais bien avoir un truc qui ressemble a de l'AVR a la fin), et que j'ai un gros proof of concept qui sera utilisé dans le jeu en lui même (le joueur aura accès a des chipsets tous prets pour pouvoir s'amuser avec).

Quelques news.
J'ai commencé le compilateur de circuit pour optimiser les performances.
C'était assez marrant a faire donc je vais décrire un peu les tests que j'ai fait pour optimiser les calculs tout en restant dans des choses pas trop complexes.

A ce stade le compilateur ne gère pas les mémoire et les sous circuits.
J'ai donc fais tous mes essais sur mon plus gros circuit "simple", l'alu 8 bits.

1. Compilation en une VM simple avec 4 instructions (and, or, nand, nor)
Sur 1000 iterations:
- avant: 3842.32 ms / 1000 => ~3.8ms
- apres:    6.68 ms / 1000 => ~6.7us

Le code d'execution de la VM ressemble a ça:

Code:

for(const Instr& instr: instructions) {
    switch(instr.opcode) {
    case OpCode::And:
        registers[instr.r1] = registers[instr.r2]&registers[instr.r3];
        break;
    case OpCode::Nand:
        registers[instr.r1] = !(registers[instr.r2]&registers[instr.r3]);
        break;
    case OpCode::Or:
        registers[instr.r1] = registers[instr.r2]|registers[instr.r3];
        break;
    case OpCode::Nor:
        registers[instr.r1] = !(registers[instr.r2]|registers[instr.r3]);
        break;
    }
}

2. On change l'ordre de l'enum: les temps varient beaucoup étrangement (pourquoi?)
Sur 100k iterations, on arrive a obtenir ~570 ms contre ~670 avant.

3. On ajoute une instruction xor pour diminuer le nombre d'instructions On passe de 1903 instructions a 1506.
Sur 100k iterations, on passe dans les 720 ms (donc beaucoup moins performant).
> Le branching semble être ce qui joue le plus sur les performances, bien plus que le nombre d'instructions.

4. On convertis toutes les portes logiques en NANDs pour ne plus avoir qu'un seul type d'instruction. On passe a 2314 instructions.
Sur 100k iterations, on obtiens ~450 msec soit un beau gain de performances malgres le nombre d'instructions en plus.

5. Essayons de ne garder que des Xor et des Nands:
Sur 100k iterations, on passe dans les 520 ms. Avoir plus d'instructions d'un seul type reste donc la meilleur chose a faire.
> On restera par la suite que sur du NAND du coup.

Le code de la VM ressemble maintenant à ça:

Code:

for(const InstrNand& instr: nands) {
    registers[instr.r1] = !(registers[instr.r2]&registers[instr.r3]);
}

6. Actuellement on a une case mémoire par instruction.
On utilise un algorithme d'allocation de registres avec coloration de graphs pour diminuer le nombre de registres/variables et optimiser le cache:
- avant: 2346 registres
- apres: 177 registres
Performances: le gain est minime... domage.

7. On passe les registres (sensé contenir un booléen) de 8bits par valeur (un tableau de uint8_t) a 32 bits par valeur:
Sur 100k iterations, on gagne ~10ms. Le gain est faible mais non négligeable.
On a des résultats quasi identiques en optimisant ou non le nombre de "registres".


Conclusion: les performances sont vraiment prometeuses sans avoir a passer par des algorithmes très complexes.
Je vais rester sur ces optimisations et continuer la compilation en prennant en compte les mémoires et sous circuits, en esperant ne pas trop y perdre de performances.


Sinon j'ai commencé un peu a designer l'éditeur de circuits haut niveau:

Tu veux dire que tu as fait quelque chose qui convertit un "programme" en un "circuit"? Un peu comme ce qu'on pourrait faire en VHDL?
Ou peut-être bien un compilateur vers un code assembleur lisible par un une machine écrit dans ton système de circuit?

Ça converti le circuit en bytecode
Pour l'instant l’interpréteur traitait l'image directement (ce qui permet de faire les animations par exemple).
Sous forme de bytecode le circuit est bien plus rapide a exécuter du coup.

Pour le VHDL ça aurait été marrant d'avoir un équivalent mais je crois que c'est un peu trop complexe a mettre en place pour moi

J'ai finis la compilation et les résultats sont prometteurs.
Ça gère tout, les sous circuits, les mémoires...
Sans avoir encore optimisé la (nouvelle) VM, pour exécuter le calcul de la suite de fibonacci sur ma puce de test, on passe de:
-non compilé: 2985.29 ms
-compilé: 3.97123 ms

Edit: je m'étais fail sur les flags de compilation...
On passe de:
-non compilé: 400.117 ms
-compilé: 0.79237 ms

Donc tu fais la compilation dans l'autre sens: du circuit vers le code. J'ai compris ^^
Intéressant ! J'ai pas grand chose à dire, mais donne nous quand même des nouvelle dès que tu as quelque chose de nouveau.

Je me suis amusé a simuler game of life dans TICS:
https://i.imgur.com/BjcuCII.gif

Chapeau!

Monsieur Onilink_, vous êtes fous, et j'admire / adore !

Franchement, je sais pas quoi ajouter, c'est trop cool ! =D
(et sacrément zinzin ! Mais trop cool XD )

Ahah merchi :p

Cet homme est fou.

onilink_ a écrit:

Ahah merchi :p

=P

Y a plus qu'a faire un convertisseur vers du VHDL, une petite carte élec qui va bien, et le circuit est en vrai =P
(Je veux même pas savoir à quoi ressemble ton code XD )

Ouaiis enfin moi je ne dessine pas mes circuits en PA, c'est mort

Hrooo allez, ça peut être drôle nan ? =P

Le code de simu est super simple, contrairement aux apparences.
C'est le code de compilation vers la VM qui est un peu plus compliqué (et encore ça a rien d'incroyable).

Pour du VHDL ça serait marrant, mais le truc c'est que c'est pas une simu réaliste, ça prend pas en compte les décalages temporels ni rien.
Donc on pourrait pas adapter ça sur un vrai circuit.

Héhé, pour les décalages temporels pourtant, tu peut compter les pixels =P
Propagation dans la porte + longueur du fil + pondération sur les fils avoisinants + ...
Ok, je vois où tu veux en venir =P

C'est surtout que je veux le truc le plus rapide a exécuter, vu que c'est pour un jeu.
Les décalages temporels empêchent énormément d'optimisations, et améliorent pas spécialement le gameplay.

Ha bha vi, quand on prends des composants parfaits, ça va tout de suite mieux =P

Mais je comprends tout à fait le but ^^
(et ça va être génial, j'en suis sûr =D )

Bah surtout que le temporel ne fait pas sens à cette échelle, qui est une confusion entre du micro et du macro. Ca serait vraiment galère de devoir appliquer des temps de propagation à des parties du circuit spécifiquement (portes logiques) et pas à d'autres (bus de données, afficheurs, etc).

Bha dans minecraft, ça marche comme ça =P
Mais je suis d'accord qu'il vaut mieux soit tout instantané, soit avec des temps réalistes.
Et que pour un jeu, l'instantané, c'est mieux =)

Je pense surtout que sur MC, c'est de la grosse flemme. Pour ne pas avoir à opti le moteur de redstone, ils ont dû le concevoir de façon à ce qu'il n'exécute qu'un nombre limité d'opérations par tick (typiquement, juste propager le signal aux cases adjacentes).
Ce qui crée des temps de propagation pas du tout réalistes