Guillaume Savaton a écrit 147 commentaires

Est-ce quelqu'un sait si Sozi est toujours maintenu ?

Sozi est d'abord un projet personnel que j'ai développé pour répondre à mes propres besoins dans mon métier d'enseignant-chercheur. J'ai aujourd'hui une autre activité dans laquelle j'ai moins d'occasions de créer des présentations.
Alors malheureusement, j'ai perdu l'essentiel de ma motivation pour continuer à développer Sozi.

La rédaction du Guide de Sozi est également à l'arrêt. L'échec du financement participatif qui lui était consacré m'a un peu refroidi.

La dernière version de Sozi semble dater de début 2021

J'ai sans doute oublié de mettre à jour le site web. En réalité, la dernière version officielle date de mars 2022.

Une version beta avec quelques corrections de bugs est également disponible depuis septembre dernier. J'ai l'intention de la promouvoir en tant que version stable officielle mais le système de construction de l'installeur pour Windows ne fonctionne plus depuis mon changement de distribution.

Au final, ça coche toutes mes cases, sauf celle de la simplicité, ce qui semble être ta priorité…

En effet. Sozi a été conçu pour créer des présentations avec un contenu majoritairement graphique que l'on veut explorer sous différentes points de vue et à différentes échelles (voir à ce sujet la page À propos de Sozi).

Pour réaliser des présentations à base de listes à puces, même avec des animations, les outils mentionnés dans l'article restent plus pertinents.

Le dialogue de FSM en vhdl est un enfer.

Tout à fait d'accord. Et c'est sans doute vrai pour tous les langages lorsqu'on travaille à ce niveau d'abstraction.

Ça fait partie des sujets que j'aimerais explorer : à partir d'un langage comme Hydromel, est-il possible de construire des abstractions de plus haut niveau, pour aller vers du Transaction-Level Modeling par exemple ?

On en parlait beaucoup quand j'étais en thèse il y a 20 ans. Il était souvent mentionné avec les autres langages synchrones Signal et Lustre. Je ne les ai jamais utilisés personnellement.

Je vois qu'il y a eu des travaux pour synthétiser du matériel à partir d'Esterel, mais je ne sais pas à quel point le langage est adapté à cet usage. Dans tous les cas, il semble assez orthogonal à l'approche que j'ai présentée dans ce journal : Esterel semble mettre l'accent sur la partie contrôle d'un système (émission et attente d'événements, processus qui peuvent être interrompus) alors que Clash et Hydromel s'appuient sur des fonctions pures qui manipulent des séquences de valeurs.

En effet. J'aurais pu le citer avec Clash dans la liste des langages basés sur Haskell.
Lava est également cité dans la documentation officielle de Clash : Clash vs Lava.

Merci beaucoup pour ces exemples.

Maintenant je vois Sozi comme un outil un peu plus polyvalent qu'un simple créateur de présentations

C'est vrai. Il faudrait peut-être trouver une autre définition de ce qu'est Sozi. C'est un peu plus qu'un outil de présentation, mais ce n'est pas pour autant un outil d'animation généraliste.

Et je trouve que ça donne un résultat finalement plus cohérent ; plus de fond que de forme ; ça me correspond mieux. Après, je fais des présentations techniques, pas commerciales/marketing.

C'est un point de vue, mais je pense que freejeff et moi faisons aussi beaucoup de présentations scientifiques et techniques.

Dans mes présentations également, il y a plus de fond que de forme, mais "fond" ne veut pas forcément dire "texte". Personnellement, en tant que spectateur, je déteste les présentations où je dois écouter l'orateur et lire ses diapos en même temps.

Si j'ai fini par arrêter, c'est que le travail nécessaire pour faire une belle présentation est 10x plus long qu'une présentation libreoffice …

En effet, de manière générale, créer une présentation avec Sozi demande plus de travail qu'un diaporama. Au lieu de créer des diapos indépendantes, il faut réfléchir à l'agencement spatial des éléments pour les réutiliser intelligemment d'une vue à l'autre.

Ça fonctionne pour moi parce que j'ai du temps et parce que j'arrive assez bien à construire mon SVG en anticipant le résultat que je veux obtenir. Mais si on me demande une présentation la veille pour le lendemain, j'irai plutôt vers LibreOffice et je ferai des diapos à base de listes à puces.

En fait, pour faire un SVG en libre, c'est principalement Inkscape, et ce logiciel demande de tout créer soit même, de ce fait c'est long, très long.

Comme le principe de Sozi est de ne pas s'occuper de l'édition du contenu graphique, je ne me suis jamais vraiment penché sur ce problème.
J'ai aussi tendance à le négliger parce que dans mon cas, mes présentations sont surtout composées de schémas que j'aurais dessinés avec Inkscape de toutes façons.

Pour le moment, on a le choix entre des outils généralistes, où il faut tout dessiner soi-même, et des outils très spécialisés comme les éditeurs de diagrammes, de cartes mentales ou de design d'interfaces utilisateur.

Je ne sais pas à quoi pourrait ressembler un éditeur SVG qui supporterait la notion de patron. Pour Inkscape, il est peut-être possible de créer un plug-in qui permettrait d'insérer rapidement des "composants" graphiques (un cadre avec un titre, ou une liste d'items, par exemple).

Une autre idée serait que Sozi accepte des documents HTML en entrée. Je n'y avais jamais pensé avant mais j'ai l'impression que ça pourrait débloquer beaucoup d'hésitants, qui ne se sentent pas assez "artistes" pour affronter la page blanche sous Inkscape.

Merci. Sozi existe depuis 2009. Je n'ai pas vraiment de statistiques fiables pour estimer le nombre d'utilisateurs.

Il y a une communauté d'utilisateurs fidèles qui suit le projet depuis le début, qui participe régulièrement aux discussions sur les forums ou qui repartage les annonces sur Twitter. Ça représente quelques dizaines de personnes.

GitHub indique environ 1300 étoiles sur le projet Sozi et à peu près 3000 téléchargements pour la dernière version, mais il est difficile de savoir combien utilisent réellement l'outil.

C'est prévu mais ça aussi, ça demande du temps pour être fait sérieusement.

Concernant le financement participatif, je comptais d'abord sur les utilisateurs qui connaissent déjà Sozi pour fournir un premier apport. En principe, d'après les retours que j'ai depuis que Sozi existe, ils sont assez nombreux.

Avec 300€ actuellement, je peux déjà prendre trois ou quatre jours pour créer la matière qui donnera envie à d'autres de participer.

Je suis d'accord. Mais comme il s'agit d'un projet personnel que je développe seul sur mon temps libre, je ne pourrai jamais en faire la promotion autant qu'il serait souhaitable pour "faire décoller le truc".

À une époque, je comptais un peu sur les utilisateurs pour partager des exemples. Il y en a quelques-unes sur l'ancien forum.

La page "sozi-demos" n'est pas vraiment représentative d'une utilisation courante de Sozi comme outil de présentation.

Je n'arrive pas a trouver sur le site.

S'il s'agit du nouveau site, effectivement, il n'y a encore pas grand-chose pour les raisons que j'ai expliquées dans le journal.

Mais la documentation sur le site du projet contient quelques exemples.

Tout à fait d'accord sur le fond. Je poste rarement des liens ici mais cette fois-ci, j'ai été gêné de ne pas pouvoir ajouter d'explications.

Vous trouverez des explications dans le billet intitulé Des nouvelles de Sozi

Très intéressant.

Ça fait longtemps que je rêve d'une suite d'outils libres, interopérables et faciles à installer, pour synthétiser du VHDL-2008 et générer un bitstream pour FPGA Xilinx.
J'ai l'impression que ça avance bien mais ça ne paraît pas encore accessible à des débutants.

Il y a d'ENSTAB qui vient de «sortir» un kit virtuel utilisant l'interface vpi de GHDL.

Très intéressant.
Je voudrais la même chose pour la carte Basys3.

J'ai réalisé plusieurs interfaces similaires pour les TP que j'ai encadrés entre avril et juin 2020. J'en ai même parlé dans ce commentaire à ton journal sur CocoTB.

Mon approche était d'utiliser GHDL, CocoTB et tkinter, en proposant pour chaque exercice une interface ne contenant que les entrées/sorties nécessaires (boutons, interrupteurs, LED, afficheurs 7 segments). Il faudrait que je mette le code dans un dépôt git public.

Faudrait que je retrouve l’info, mais j'étais tombé sur un post qui disait que non

Étonnant. Je suis curieux de connaître la source.

Peut-être une histoire de version du standard

Je possède une version d'époque du standard VHDL-87 (avis aux collectionneurs). Il contient des exemples qui montrent que, depuis le début, un package peut contenir des déclarations de constantes avec leurs valeurs.

Certains outils ne le supportent peut-être pas, mais en plus de 20 ans, je n'ai jamais rencontré de problème. Je m'efforce de respecter le standard VHDL-93, avec parfois quelques emprunts à VHDL-2008 lorsque les outils le permettent.

Merci pour cet article. Ça fait longtemps que je projette de tester GHDL-Synth et Yosys.

J'avais également l'intention d'écrire un tap-tempo en VHDL afin de le proposer en exercice à mes étudiants. Je pense que je le ferais à peu près de la même manière, mais je ne le décomposerais pas autant : par exemple, décrire un simple compteur dans une architecture séparée, comme timepulse ne me paraît pas nécessaire.

Lorsque tu écris :

Le VHDL est très hiérarchique, on décrit des modules avec leurs entrées-sorties que l’on assemble ensuite à la manière d’un schéma bloc dans un composant «top».

je préciserais qu'on est tout à fait libre de choisir la structuration de son circuit.

On peut tout mettre dans une seule architecture si on le veut, ou on peut le découper en un assemblage de nombreux composants simples. Comme dans les langages de programmation, mettre tout dans le main n'est généralement pas une bonne idée, mais créer une myriade de petites fonctions peut aussi être excessif.

Vous noterez la lourdeur d’avoir à déclarer le type de la constante dans le package avant de donner sa valeur dans le body

En réalité, on peut très bien indiquer les valeurs des constantes directement dans le package.
Par contre, pour les procédures et fonctions, on doit obligatoirement placer la déclaration dans le package et l'implémentation dans le body.

Merci pour ces informations.

Comme évoqué plus haut en prenant l'exemple de Jitsi, ce serait idéal si le partage et le pilotage des présentations Sozi se faisaient à travers le même service que le streaming audio.
Je vais me renseigner sur BigBlueButton.

Si je comprends bien il y aurait un orateur, et les participants peuvent uniquement l'entendre lors du déroulement de la séance, mais pas le voir ?

C'est comme ça que je vois les choses. D'autres utilisateurs pourraient souhaiter garder un canal vidéo pour une caméra mais pas pour la présentation elle-même.

Du coup est-ce qu'une solution telle que suivant est acceptable […]

Je pense que ce serait tout à fait acceptable pour les utilisateurs mais le principe d'une "plate-forme de broadcasting" est justement ce que je cherche à éviter.

Pour le moment, je ne m'intéresse pas tellement à la question du partage des fichiers Sozi. Dans un premier temps, il suffirait que l'orateur configure sa "console de présentation" (le fichier -presenter.sozi.html créé par Sozi) en fournissant, par exemple, un nom de serveur et un identifiant de salon. Les spectateurs pourraient alors ouvrir la présentation (le fichier .sozi.html) en renseignant les mêmes informations.

Ensuite, si la voix passe par Jitsi, par exemple, ce serait pratique que Jitsi fournisse également un canal de données pour les messages Sozi. Ou au minimum, que Jitsi serve de "signaling server" pour une connexion WebRTC spécifique à Sozi.

Le résultat intéressait peut-être Framasoft

En effet, Framasoft et les CHATONS seraient des partenaires intéressants pour éviter d'avoir un serveur Sozi centralisé.

sinon est-ce que vos utilisateurs sont du genre à déployer leur instance ?

J'ai très peu d'informations sur les utilisateurs de Sozi mais a priori, je dirais que non.
Ceux qui utilisent Sozi dans l'enseignement supérieur pourraient peut-être faire installer un serveur par leur établissement, mais ce n'est pas toujours possible.

Merci pour ce retour.

En effet, les WebSockets pourraient servir de base à une solution mais ça me paraît être d'assez bas niveau.

Avec WebRTC, j'ai l'impression qu'il y a une API prête à l'emploi pour l'échange de messages à condition d'avoir établi une connexion. C'est là que le "signaling server" intervient. Certains serveurs reposent sur les WebSockets mais ce n'est pas obligatoire.

J'ai commencé à utiliser CocoTB pendant le confinement, dans le cadre d'un enseignement à distance du VHDL.

Habituellement, nous utilisons la suite Vivado de Xilinx pour la simulation et la synthèse, et des cartes Digilent pour les essais avec du vrai matériel.
Pendant le confinement, il était impossible de fournir des cartes à tous les étudiants. Nous ne pouvions faire que de la simulation. Sachant que les étudiants travaillaient avec leur ordinateur personnel, j'ai rapidement écarté Vivado pour trois raisons :

• Il n'est pas disponible sous OS X.
• L'installation nécessite 20 Go d'espace disque libre.
• Et surtout, la simulation sous Vivado n'est pas interactive : certes, on peut écrire un banc de test et afficher des chronogrammes, mais on ne peut pas créer une interface graphique avec des widgets simulant les entrées/sorties de la carte, comme on peut le faire par exemple avec le simulateur commercial Modelsim.

Je me suis orienté vers une solution utilisant GHDL, GtkWave, CocoTB et tkinter.
CocoTB est utilisé de deux manières :

• D'abord pour automatiser des tests, ce qui est sa raison première.
• Mais aussi pour faire l'interface entre, d'une part de petites interfaces graphiques écrites en Python avec tkinter (avec des boutons, des interrupteurs, des LED ou des afficheurs 7 segments), et d'autre part l'entité principale VHDL simulée par GHDL.

Dans le premier cas, on veut que la simulation soit la plus rapide possible ; le temps simulé est relativement indépendant de la durée que prend le simulateur pour exécuter le design.
Dans le deuxième cas, au contraire, si la description VHDL prévoit qu'une LED clignote toutes les secondes, on veut la voir clignoter à la bonne vitesse sur l'interface graphique. Il a fallu tricher un peu, et ça n'a pas toujours bien fonctionné lorsque les performances des PC des étudiants n'étaient pas suffisantes.

En quelque sorte, CocoTB a sauvé nos TP de VHDL, et je pense même continuer à l'utiliser l'année prochaine.

Est-ce que Sozi propose aussi des bonnes pratiques pour ce style radicalement différent de présentation ? Ou bien est-ce juste une manière de faire des transitions rigolotes et un peu excentriques ?

Il n'y a pas encore de guide de bonnes pratiques.
J'ai toujours de le projet de rédiger un document de référence sur l'utilisation de Sozi, si je trouve du temps…

Pour avoir examiné des exemples faits par différents utilisateurs, je sais que certains l'utilisent pour faire des diaporamas améliorés, avec beaucoup de texte et de listes à puces.
D'autres, comme moi, l'utilisent pour illustrer un discours, avec beaucoup de diagrammes et de nombreux calques.
Cette deuxième approche demande beaucoup plus de travail et peut décourager.

Je suis vraiment tombé dessus par hasard en regardant les réponses à mes posts mais la visibilité de cette annonce est insuffisante.

C'est vrai. C'est parce que ce message t'était personnellement destiné :)
En réalité, j'ai également rédigé une annonce sur le forum de discussion de Sozi et sur Twitter. Je vais aussi ajouter des infos dans la rubrique "Contribuer" sur le site web.