Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
On 11/04/2016 01:34 PM, why...@f-cpu.org wrote: Le 2016-11-04 10:59, Martin Strubel a écrit : On the other side there's a lot of possibilities for fun stuff, like creating SVG images from the XML using built-in browser XSL abilities. That's the best-looking idea of today ! I want that :-) Thy wish shall be heard. Put up a Q&D demo. Just drag the output from --file-to-xml using your file manager onto the canvas. Tested with recent Firefox only: http://section5.ch/dclib/xhdl/ And in case: no worries, as noted, none of your design data is transmitted anywhere. Cheers, - Strubi ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Le 2016-11-04 10:59, Martin Strubel a écrit : On the other side there's a lot of possibilities for fun stuff, like creating SVG images from the XML using built-in browser XSL abilities. That's the best-looking idea of today ! I want that :-) - Martin yg ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Hi all, I've played around with XSLT a bit more - here's an attempt to extract some structure from a set of GHDL files. It's in a state "works for me", so don't expected the full coverage. And: no docs, just Makefile. http://section5.ch/downloads/xhdl-0.0proto.tgz However, I had to make some changes to the original XML output, the XSLT expects a specific ghdl namespace, so you have to change the node into http://www.gna.org/schema/ghdl";> for the time being (apology for the wild guess on a namespace URL..) You need a very recent ghdl checkout (like g4c7c53b). The generated XML file should open up with a XML editor such as XXE, see also included *.css styles. Plans are to create a XSD schema for this "dialect", once somewhat consolidated. Next step is the actual RTL description, this is somewhat more complex. On the other side there's a lot of possibilities for fun stuff, like creating SVG images from the XML using built-in browser XSL abilities. If some folks would want to hack along, I'm up for opening up a repo somewhere. Cheers, - Martin ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/27/2016 12:47 PM, Brian L. Drummond wrote: > But the GHDL runtime system is mostly written in Ada, so embedding > Python into that may still be relevant. > Nice point! Thanks, Brian. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Am 26.10.2016 um 21:43 schrieb Adam Jensen: > > > I suggest that any co-processing that the simulation model needs should > take place in a separate process and be accessed via typical IPC > (Inter-Process Communication) methods. This would allow flexibility in > the selection of the co-processing environment (e.g., Octave, R, SciPy, > etc.). > > I use Ethernet in my simulation to connect me with other applications. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
No, the VHDL is not translated into an Ada program. But the GHDL runtime system is mostly written in Ada, so embedding Python into that may still be relevant. Where the sticking point probably comes is this : a normal Ada application is built using the normal Ada RTS (for Gnat, that is GNARL, the Gnat Runtime Library) whereas the GHDL runtime system is independent of the Ada RTS, since it effectively replaces it. So the Gems #105,106 may not be directly applicable, to the extent they depend on GNARL. To what extent is that? I don't know. You'd probably have to try building the relevant bits of Gnatcoll stand-alone, without the underlying RTS, and ditto the Gem example to find out... -- Brian From: Ghdl-discuss on behalf of Adam Jensen Sent: 27 October 2016 17:33:10 To: ghdl-discuss@gna.org Subject: Re: [Ghdl-discuss] Synthesis for FPGAs On 10/27/2016 07:06 AM, Martin Strubel wrote: > I've also checked > > http://docs.adacore.com/gnatcoll-docs/scripting.html#the-python-language > > and it looks like there might be OO templates (the Console class > wrapper) to make this engineering task nice. Someone's gotta try.. :) [snip] After thinking about it a bit, embedding Python (or Tcl) into an Ada application might not be the issue. While the GHDL compiler is written in Ada, I don't think it does anything like translating the VHDL into an Ada program (at which point the above mentioned technique would be used to embed an interpreter) and then compiles it with GNAT. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/27/2016 07:06 AM, Martin Strubel wrote: > I've also checked > > http://docs.adacore.com/gnatcoll-docs/scripting.html#the-python-language > > and it looks like there might be OO templates (the Console class > wrapper) to make this engineering task nice. Someone's gotta try.. :) [snip] After thinking about it a bit, embedding Python (or Tcl) into an Ada application might not be the issue. While the GHDL compiler is written in Ada, I don't think it does anything like translating the VHDL into an Ada program (at which point the above mentioned technique would be used to embed an interpreter) and then compiles it with GNAT. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Hi Adam,
I think that road is well traveled [2]. Considering what is available,
embedding a big complicated Python interpreter might actually be easier
than embedding a simple little Tcl interpreter.
[2]:
http://www.adacore.com/adaanswers/gems/gem-106-lady-ada-kisses-python-part-2/
I've also checked
http://docs.adacore.com/gnatcoll-docs/scripting.html#the-python-language
and it looks like there might be OO templates (the Console class
wrapper) to make this engineering task nice. Someone's gotta try.. :)
The big work from my experience always came from wrapping low level
objects into a "nice" but robust class design while maintaining the
proper ownership of objects (classical topic coming up when things
crash..). Automatic wrapping seems to be an art, after attempts with
Boost (no comment..) and SWIG a few years ago I still ended up doing it
as described in the Python docs ("Extending and embedding").
Greetings,
- Martin
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
For convenience: http://www.adacore.com/adaanswers/gems/gem-105-lady-ada-kiss-python-part-1/ > http://www.adacore.com/adaanswers/gems/gem-106-lady-ada-kisses-python-part-2/ ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/27/2016 03:33 AM, Martin Strubel wrote:
[snip]
> $ ./sim --interactive --port=2016
>
> Python:
>> import ghdlex
>> def cond(signals):
>>return True
>> ...
>> sim = ghdlex.connect(":2016")
>> sim.set("Timescale", "1ns")
>> s0 = ghdlex.StopCondition(cond)
>> sim.stop_conditions.insert(s0)
>> sim.start()
>> while sim.state() == ghdlex.RUNNING:
>> time.sleep(0.1)
>
Excellent idea. Like the saying "a picture is worth a thousand words",
so is an example or a demonstration. I think I understand now - many of
the people on this list are actually willing to use Python as a command
line shell interface. (I sometimes forget that Windows and GUI users
aren't steeped in [The Tao of Unix][1]).
[1]: https://gist.github.com/wmayner/d3a0ebf059982abbe3ad
> Well, if you'd embed the python interpreter as a cli which would fire up
> everything behind as a separate (asynchronous) thread, you could
> probably have both (a) and (b) using callbacks.
[snip]
> The ugly side of it (from an engineering side of view) is: I wouldn't
> know how Ada can interface with Python except going through a C API.
I think that road is well traveled [2]. Considering what is available,
embedding a big complicated Python interpreter might actually be easier
than embedding a simple little Tcl interpreter.
[2]:
http://www.adacore.com/adaanswers/gems/gem-106-lady-ada-kisses-python-part-2/
___
Ghdl-discuss mailing list
Ghdl-discuss@gna.org
https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
In these cases, I think we may be describing the same thing. To
reconcile terms and elaborate:
a) I've been clumsily trying to describe an interactive command shell
with loadable configuration/extension scripts. With this, one could
"change directories" through the design hierarchy, select signals to
trace, inspect state, step the simulation forward, etc. Is this what you
mean by "control simulation from outside (asynchronously)"?
Yes, let me throw in a somewhat documented scenario (with the current
limitations):
http://tech.section5.ch/news/?p=124
The "plus" features would be something like:
$ ./sim --interactive --port=2016
Python:
> import ghdlex
> def cond(signals):
>return True
> ...
> sim = ghdlex.connect(":2016")
> sim.set("Timescale", "1ns")
> s0 = ghdlex.StopCondition(cond)
> sim.stop_conditions.insert(s0)
> sim.start()
> while sim.state() == ghdlex.RUNNING:
> time.sleep(0.1)
The interface would also have to react to the assert events that you
would normally use to terminate your sim from *within* your HDL.
It is arguable to have a blocking call like
> evt = sim.run()
too.
Some LabVIEW uers would do that similarly, the simulation then being
accessed by a VI.
b) I've vaguely imagined some kind of generic VHPI library connected to
the embedded interpreter such that writing VHDL that interfaces through
configurable IPC to whatever environment one prefers (e.g., Octave, R,
SciPy, etc.) would be easy.
It can just slow down your system massively to make blocking calls from
the simulation to something else. If you only do that every now and then
with a artificially slow clock, it might be ok (I'm using that to
refresh a virtual display, some outdated example:
http://tech.section5.ch/news/?p=130).
The more performant way is just a software FIFO running as a separate
thread, I think. I've also implemented a virtual RAM for more
performance that can be accessed through the network backdoor. In fact
that's the more elegant way to run a framebuffer display.
If you have any non-covered application scenarios in mind, feel free to
elaborate (no pun intended).
By "client side stuff from inside the simulation" do you mean actually
implementing the VHPI coroutines in the embedded interpreter? I suppose
that is where the embedded Python [program] interpreter would be *much*
more useful than a light-weight Tcl [command] interpreter. But that
would also most likely mean that Python would be used as the interactive
command interface.
Well, if you'd embed the python interpreter as a cli which would fire up
everything behind as a separate (asynchronous) thread, you could
probably have both (a) and (b) using callbacks.
But this calls for complicated scenarios, typically. That's why I tend
to insert the small "netpp" property layer only into the exes that are
supposed to speak to each other, i.e. resolving into a clear
client/server (master/slave) relationship that's calling for less
pitfalls, I guess. The simulation.exe just does not feel like a "master"
to me.
The ugly side of it (from an engineering side of view) is: I wouldn't
know how Ada can interface with Python except going through a C API.
That's why it would probably be wise to separate things and look at a
plugin concept as it's already there with the .vpi DLL interface.
...
How often does shell syntax need to change? (Rhetorical).
Not too often. For the tcl user, things don't matter much. It's rather
implementation-wise. I just had tried to migrate some old (10y) code a
few years ago to a newer TCL version. Compared to updating old python
crap, this turned out to be more of a maintenance pain. You might start
an argument with Python v2.x vs 3.x, but since this would be a new
design anyway, no point looking at legacy.
On the other side, the pain you may have with Python/C interfacing are
reference count issues. Certainly, I wouldn't want to create too many
python dynamic objects from within a simulation.
I hadn't really considered that including Tk would be desirable. Would
people want to create a graphical interface to the [executable
simulation model][2]? The jimTcl implementation does *not* have a Tk
interface.
I know jimtcl somewhat from the OpenOCD debugger side, but this always
was something to me that worked half way. That's probably got nothing to
do with jimtcl but with the messy implementation concept of OpenOCD. But
eventually, it's always up to the one doing the job to decide :-)
[2]: What is a good way to refer to the executable binary file that is
produced by the ghdl compiler?
Sounds verbose to me "as is". Or 'simulation runtime'? Or Herman the
german style: Elaboriertes Kompilat :-)
Now we've gotten off the actual synthesis topic though.
If we make the loop from Python back to synthesis, I'd like to point out
that there's a powerful MyHDL framework that already has all the
ast/elaboration issues covered inside the python runtime environment.
However its
Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/26/2016 07:30 PM, Martin Strubel wrote: > There's more confusion to be added, even: > a) Control simulation from outside (asynchronously) > b) Do "client side" stuff from inside the simulation In these cases, I think we may be describing the same thing. To reconcile terms and elaborate: a) I've been clumsily trying to describe an interactive command shell with loadable configuration/extension scripts. With this, one could "change directories" through the design hierarchy, select signals to trace, inspect state, step the simulation forward, etc. Is this what you mean by "control simulation from outside (asynchronously)"? b) I've vaguely imagined some kind of generic VHPI library connected to the embedded interpreter such that writing VHDL that interfaces through configurable IPC to whatever environment one prefers (e.g., Octave, R, SciPy, etc.) would be easy. By "client side stuff from inside the simulation" do you mean actually implementing the VHPI coroutines in the embedded interpreter? I suppose that is where the embedded Python [program] interpreter would be *much* more useful than a light-weight Tcl [command] interpreter. But that would also most likely mean that Python would be used as the interactive command interface. > [snip] I don't want to start a language war [snip] I don't really get that either. I guess it's behavior in the same category as the enthusiasm of sports fans, or nationalism. The FreeBSD community has the notion of a "bikeshed"[1]. [1]: https://www.freebsd.org/doc/en/articles/mailing-list-faq/bikeshed.html Anyway, assuming hormone driven states of mind can be regulated , it seems most appropriate to address the issues with the same type of analysis as any other engineering decision. > [snip] but tcl/tk appears a bit outdated to me [snip] How often does shell syntax need to change? (Rhetorical). I hadn't really considered that including Tk would be desirable. Would people want to create a graphical interface to the [executable simulation model][2]? The jimTcl implementation does *not* have a Tk interface. [2]: What is a good way to refer to the executable binary file that is produced by the ghdl compiler? ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Hi all, It occurred to me while having a walk about a few moments ago that there could be a confusion of two separate ideas in these discussions: first, is embedding an interpreter into the run-time results of the ghdl compiler (into the simulation model); the second is embedding an interpreter into the ghdl compiler itself (extending its capabilities in some way, I suppose). I've been thinking and remarking entirely on the first scenario. There's more confusion to be added, even: a) Control simulation from outside (asynchronously) b) Do "client side" stuff from inside the simulation I think most users would want (a) to control the simulation process. I don't really see the reason embedding a Python interpreter, although that can be done on an ortho-generated exe already - you just need to call an init wrapper from your VHDL TB that spawns a thread. But calling Python-Coroutines from GHDL doesn't make sense to me. It rather makes sense to me giving access to more GHDL internals over an asynchronous command interface, for example, if you want the modelsim like start/stop or specific signal trace/selection features. The mcode GHDL is of course a different story. But I guess both ortho and mcode could supply a plugin API for simulation control (on top of the VHPI interface) that would load a user specific extension DLL. On 10/26/2016 04:20 PM, Patrick Lehmann wrote: Using IPC is a big performance hit. It might be good enough for analysis tasks, but it's a bottleneck for co-simulations. Others on this list have used the IPC technique. They're probably better equipped to remark on performance issues and partitioning thresholds. I'm even using RPC over networked simulations, like a gdb speaking over virtual JTAG to a simulated SoC which again spits out data over a pty (using ghdlex/netpp). Or the dance with qemu and GHDL-simulated peripherals. Since simulation is typically slower, there's no significant bottleneck, unless you have a lot of ping-pong between simulation domains, such as a virtual bus. Via ghdlex, Python scripted control of the VHDL simulation (_not_ the simulator engine) is already possible. However, I've never covered the mcode side of it. Counter question: Why do assume that is the reason? (Rhetorical question, I know why. (Have I mentioned the feistiness?)). It's not a poor reason - if CAD tool users already know the syntax, that reduces the obstacles and burdens. I don't want to start a language war, but tcl/tk appears a bit outdated to me and doesn't have the ecosystem that the Python world has, apart from performance/integration issues with C DLLs or object kernels. The point that EDA people are used to TCL is certainly valid, on the other hand, I believe it's worth modernizing that domain a bit. I have made good experiences with the CAD dudes adopting Python :-) Greetings, - Martin ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
The season is changing here (US/EST) and with it, so changes the local flora and fauna, including the human animal. I woke up a little feisty today, and decided to indulge it on this list by revisiting the embedded scripting issue. It occurred to me while having a walk about a few moments ago that there could be a confusion of two separate ideas in these discussions: first, is embedding an interpreter into the run-time results of the ghdl compiler (into the simulation model); the second is embedding an interpreter into the ghdl compiler itself (extending its capabilities in some way, I suppose). I've been thinking and remarking entirely on the first scenario. On 10/26/2016 04:20 PM, Patrick Lehmann wrote: > Using IPC is a big performance hit. It might be good enough for analysis > tasks, but it's a bottleneck for co-simulations. Others on this list have used the IPC technique. They're probably better equipped to remark on performance issues and partitioning thresholds. > I saw an EDA tool which has 2 embedded scripting languages: Tcl and Python! Cool. Seems like a lot of work, but options are cool when they're free. > Counter question: Why do CAD tool users think that Tcl is a GOOD > embedded scripting language? There is plenty of text here: http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html May you find elucidation and illumination. (Feisty, I say!) > Just because vendors ship their tools with > Tcl, doesn't make Tcl a good language... Counter question: Why do assume that is the reason? (Rhetorical question, I know why. (Have I mentioned the feistiness?)). It's not a poor reason - if CAD tool users already know the syntax, that reduces the obstacles and burdens. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/26/2016 01:44 PM, Vern Muhr wrote: [snip] > I have read that there is consideration of embedding Python in the GHDL > system. [snip] I still don't get why so many people believe that embedding a Python interpreter is a desirable thing to do. The methods of the pyCult are undeniably effective. ;) I suggest that any co-processing that the simulation model needs should take place in a separate process and be accessed via typical IPC (Inter-Process Communication) methods. This would allow flexibility in the selection of the co-processing environment (e.g., Octave, R, SciPy, etc.). Given that situation, some configuration support might be in order. I would prefer a command shell for interactive exploration of the model's structure & state, and loadable scripts for configuration and automated control of the simulation. It seems desirable that the source code, syntax, and embedded executable should be light-weight and straight-forward to use, document, and maintain. This problem has already been solved. http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html http://jim.tcl.tk ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Using IPC is a big performance hit. It might be good enough for analysis tasks, but it's a bottleneck for co-simulations. Which IPC technique works on all supported GHDL platforms?I saw an EDA tool which has 2 embedded scripting languages: Tcl and Python!Counter question: Why do CAD tool users think that Tcl is a GOOD embedded scripting language? Just because vendors ship their tools with Tcl, doesn't make Tcl a good language...Kind regards Patrick---Wissenschaftliche HilfskraftTechnische Universität DresdenFakultät InformatikInstitut für Technische InformatikLehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur 01062 Dresden, GERMANYTel.: +49 351 463-38451 Fax: +49 351 463-38324E-Mail: patrick.lehm...@tu-dresden.de WWW:http://vlsi-eda.inf.tu-dresden.de Ursprüngliche Nachricht Von: Adam Jensen Datum:26.10.2016 21:44 (GMT+01:00) An: ghdl-discuss@gna.org Betreff: Re: [Ghdl-discuss] Synthesis for FPGAs On 10/26/2016 01:44 PM, Vern Muhr wrote: [snip] > I have read that there is consideration of embedding Python in the GHDL > system. [snip] I still don't get why so many people believe that embedding a Python interpreter is a desirable thing to do. The methods of the pyCult are undeniably effective. ;) I suggest that any co-processing that the simulation model needs should take place in a separate process and be accessed via typical IPC (Inter-Process Communication) methods. This would allow flexibility in the selection of the co-processing environment (e.g., Octave, R, SciPy, etc.). Given that situation, some configuration support might be in order. I would prefer a command shell for interactive exploration of the model's structure & state, and loadable scripts for configuration and automated control of the simulation. It seems desirable that the source code, syntax, and embedded executable should be light-weight and straight-forward to use, document, and maintain. This problem has already been solved. http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html http://jim.tcl.tk ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss smime.p7s Description: S/MIME Cryptographic Signature ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
You could look into Cocotb. The embedded CPython into C. GHDL has already some C APIs, so it needs to add a hand full of Python classes written in C like Cocotb did for a unified simulator interface.---Wissenschaftliche HilfskraftTechnische Universität DresdenFakultät InformatikInstitut für Technische InformatikLehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur 01062 Dresden, GERMANYTel.: +49 351 463-38451 Fax: +49 351 463-38324E-Mail: patrick.lehm...@tu-dresden.de WWW:http://vlsi-eda.inf.tu-dresden.de Ursprüngliche Nachricht Von: Vern Muhr Datum:26.10.2016 19:46 (GMT+01:00) An: ghdl-discuss@gna.org Betreff: Re: [Ghdl-discuss] Synthesis for FPGAs Hi, ZamiaCAD is an open source VHDL development environment with simulation and synthesis capabilities. It is written in Java, but would probably be helpful in terms of getting an idea of an approach to the synthesis problem. I believe they do the synthesis from a representation of the elaboration of the design instead of the AST. That makes more sense to me. Another interesting feature of ZamiaCAD is that a Python (actually Jython) interpreter is embeded. I use Jython to export designs to an external simulator. I have read that there is consideration of embedding Python in the GHDL system. That would probably be a lot of work compared to embedding Jython in a Java based system. Has anyone done much work on embedding Python in an Ada app.? Best, Vern smime.p7s Description: S/MIME Cryptographic Signature ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Here's where I'd start... http://www.adacore.com/adaanswers/gems/gem-105-lady-ada-kiss-python-part-1/ Gem #105: Lady Ada Kisses Python -- Part 1 | Ada Gem of ...<http://www.adacore.com/adaanswers/gems/gem-105-lady-ada-kiss-python-part-1/> www.adacore.com Gem #105: Lady Ada Kisses Python—Part 1. The GNAT Components Collection (GNATCOLL) has included, since the beginning, a collection of packages to easily interface ... From: Ghdl-discuss on behalf of Vern Muhr Sent: 26 October 2016 18:44:37 To: ghdl-discuss@gna.org Subject: Re: [Ghdl-discuss] Synthesis for FPGAs Hi, ZamiaCAD is an open source VHDL development environment with simulation and synthesis capabilities. It is written in Java, but would probably be helpful in terms of getting an idea of an approach to the synthesis problem. I believe they do the synthesis from a representation of the elaboration of the design instead of the AST. That makes more sense to me. Another interesting feature of ZamiaCAD is that a Python (actually Jython) interpreter is embeded. I use Jython to export designs to an external simulator. I have read that there is consideration of embedding Python in the GHDL system. That would probably be a lot of work compared to embedding Jython in a Java based system. Has anyone done much work on embedding Python in an Ada app.? Best, Vern ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Hi, ZamiaCAD is an open source VHDL development environment with simulation and *synthesis* capabilities. It is written in Java, but would probably be helpful in terms of getting an idea of an approach to the synthesis problem. I believe they do the synthesis from a representation of the elaboration of the design instead of the AST. That makes more sense to me. Another interesting feature of ZamiaCAD is that a Python (actually Jython) interpreter is embeded. I use Jython to export designs to an external simulator. I have read that there is consideration of embedding Python in the GHDL system. That would probably be a lot of work compared to embedding Jython in a Java based system. Has anyone done much work on embedding Python in an Ada app.? Best, Vern ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Hi Tristan, thanks for the snippet. Played around a bit with XSL and got some usable output just for dumping purposes. Reality will be far more complex though... 4) I was wondering, if it was actually possible to hack an .XSL to extract register assignments as the above, or if a more complex tree parsing via a "real" programming language was required. I fear that xsl is not the best way to write a syntheziser... I'd tend to say "impossible", but in in a few cases so far I found ways to translate from XML dialect A into dialect B which again can be processed easier, without going through complex classical DOM parsing solutions (saxon/expat/...). So a possible first step could be to identify constructs that synthesize and express them in an easier-to read (and *then* schematize via XSD) XML language. I've played around in the past with the Python/MyHDL approach (with the built-in native access to the AST) to generate RTL for DSP units. Not considered "nice", but usable. Nice would be to have an intermediate "XML DNA", but that's way more complex than a few DSP slices... I also liked YG's idea/approach with the virtual machine, but the path from a 'simulation primitive' (event driven logic) to a level where the VM would know how to handle a HDL-Design with a set of FPGA technology elements seems already more complex than a HDL analysis based on the actual code (via AST) with a mapping stage in between. Wild dreaming: Deploy machine learning algos (but spend a few years on research...) But the coverage aspect of it is very nice, also, a different way of optimization could take place, that considers the real application scenario based on the test bench. It might also give a lot more control to place & route from a mapper level. Can't think of the time burnt just because tools do what they want by just crunching brute force in the wrong direction. And then it's a bad time having to reverse engineer and find out: The human brain is often the better router. Cheers, - Martin ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Le 2016-10-17 20:59, Tristan Gingold a écrit : On 17/10/16 12:54, why...@f-cpu.org wrote: I didn't know it would be so easy, however I am wondering : the AST describes the circuit but what about the elaboration ? The XML represents the VHDL file after analysis. Then I suppose that the synthesiser must perform elaboration... Tristan. yg ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
On 17/10/16 12:54, why...@f-cpu.org wrote: Le 2016-10-17 12:37, Salvador Eduardo Tropea a écrit : El 15/10/16 a las 03:21, Tristan Gingold escribió: I have just added a new command to dump the AST tree in XML: ghdl --file-to-xml FILEs Thanks! Thanks from me too ! I didn't know it would be so easy, however I am wondering : the AST describes the circuit but what about the elaboration ? The XML represents the VHDL file after analysis. Tristan. My idea of running a virtual machine of a tagged architecture would solve this because the elaboration would elaborate properly... What detail did I miss ? Regards, Salvador yg ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
On 17/10/16 11:29, Martin Strubel wrote: Hi Tristan, Comments and suggestions are welcome. 1) Cool stuff! That might come in very handy for Co-Simulation and other code analysis 2) Could you post a simple example XML output of a FF/register assignment (only if you have the nerve for it, of course), e.g. process(clk) begin if rising_edge(clk) then if en = '1' then r0 <= r1; end if; end if; end process; The interesting part of the xml is: file="ex.vhdl" line="12" col="3" label="" seen_flag="false" end_has_postponed="false" passive_flag="false" postponed_flag="false" visible_flag="false" is_within_flag="false" has_label="false" has_is="false" end_has_reserved_id="true" end_has_identifier="false" wait_state="unknown"> line="14" col="5" label="" suspend_flag="false" visible_flag="false" end_has_identifier="false"> file="ex.vhdl" line="14" col="8" expr_staticness="none" name_staticness="none"> kind="association_element_by_expression" file="ex.vhdl" line="14" col="20" whole_association_flag="true" collapse_signal_flag="false"> file="ex.vhdl" line="14" col="20" identifier="clk" is_forward_ref="false" expr_staticness="none" name_staticness="local"> file="ex.vhdl" line="15" col="8" identifier="en" is_forward_ref="false" expr_staticness="none" name_staticness="local"> file="ex.vhdl" line="15" col="13" identifier="'1'" is_forward_ref="false" expr_staticness="local" name_staticness="local"> delay_mechanism="inertial" visible_flag="false" guarded_target_state="false"> expr_staticness="none" name_staticness="local"> line="12" col="11" identifier="clk" is_forward_ref="false" expr_staticness="none" name_staticness="local"> 3) Someone mentioned a schema (XSD), this sounds like an awful lot of work to me, esp. at an early stage, when things might change. I'd rather see many conversion examples. I have never written XSD, to I cannot really comment. 4) I was wondering, if it was actually possible to hack an .XSL to extract register assignments as the above, or if a more complex tree parsing via a "real" programming language was required. I fear that xsl is not the best way to write a syntheziser... Tristan. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Le 2016-10-17 12:37, Salvador Eduardo Tropea a écrit : El 15/10/16 a las 03:21, Tristan Gingold escribió: I have just added a new command to dump the AST tree in XML: ghdl --file-to-xml FILEs Thanks! Thanks from me too ! I didn't know it would be so easy, however I am wondering : the AST describes the circuit but what about the elaboration ? My idea of running a virtual machine of a tagged architecture would solve this because the elaboration would elaborate properly... What detail did I miss ? Regards, Salvador yg ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
El 15/10/16 a las 03:21, Tristan Gingold escribió: I have just added a new command to dump the AST tree in XML: ghdl --file-to-xml FILEs Thanks! Regards, Salvador -- Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA FAX: (+54 11) 4754 5194 Buenos Aires * Argentina ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Hi Tristan, Comments and suggestions are welcome. 1) Cool stuff! That might come in very handy for Co-Simulation and other code analysis 2) Could you post a simple example XML output of a FF/register assignment (only if you have the nerve for it, of course), e.g. process(clk) begin if rising_edge(clk) then if en = '1' then r0 <= r1; end if; end if; end process; 3) Someone mentioned a schema (XSD), this sounds like an awful lot of work to me, esp. at an early stage, when things might change. I'd rather see many conversion examples. 4) I was wondering, if it was actually possible to hack an .XSL to extract register assignments as the above, or if a more complex tree parsing via a "real" programming language was required. I'm working a lot with XML to create HDL and other sources, it took quite a while to design the dialect such that the translation overhead is not too massive (IP-XACT not being the best example here...) But this topic is definitely different, more like disassembly, so I guess the next story (where the XSD makes sense) would be the design of the transfer language, i.e. apart from the pure analysis aspect, being able to identify FF/Muxer/LUT and other primitives and translate them into some mid level XML RTL, that again would translate to a netlist usable by the mapper tools. But the big gordian knot might be, to keep this layer independent of the FPGA technology (assuming that the HDL design is free of vendor specifics). Cheers, - Strubi ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Regarding "we":My viewer somehow introduced a linebreak and created a standalone we tag :)Mistery solved.---Wissenschaftliche HilfskraftTechnische Universität DresdenFakultät InformatikInstitut für Technische InformatikLehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur 01062 Dresden, GERMANYTel.: +49 351 463-38451 Fax: +49 351 463-38324E-Mail: patrick.lehm...@tu-dresden.de WWW:http://vlsi-eda.inf.tu-dresden.de Ursprüngliche Nachricht Von: Tristan Gingold Datum:15.10.2016 11:49 (GMT+01:00) An: ghdl-discuss@gna.org Betreff: Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump On 15/10/16 11:07, Patrick Lehmann wrote: > Hello Tristan, > > I have seen many bad structured XML formats in my life, but GHDL's > output looks VERY GOOD! Especially that you use XML attributes and ids. It is written by hand and not very complex. Nodes have id, lists have list-id. This is not very regular, so maybe all XML elements must have id (I will certainly use nXX for nodes and lXX for lists in that case). > Two notes: > 1) > You are almost using long readable names except for el and we. Can give > the long name? el stands for element of a list or of a chain. That's not very interesting so I plan to keep it. we ? No, it doesn't exist. There is we_value which stands for waveform_element_value. This comes directly from iirs.ads, so no plan to change it immediately. > 2) > The output needs a root element like design_file and a version number > for the AST version. That was only an excerpt. The start of the file is: identifier="std" date="12" ... Adding a version to root is a good idea. Tristan. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss smime.p7s Description: S/MIME Cryptographic Signature ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
On 15/10/16 11:07, Patrick Lehmann wrote: Hello Tristan, I have seen many bad structured XML formats in my life, but GHDL's output looks VERY GOOD! Especially that you use XML attributes and ids. It is written by hand and not very complex. Nodes have id, lists have list-id. This is not very regular, so maybe all XML elements must have id (I will certainly use nXX for nodes and lXX for lists in that case). Two notes: 1) You are almost using long readable names except for el and we. Can give the long name? el stands for element of a list or of a chain. That's not very interesting so I plan to keep it. we ? No, it doesn't exist. There is we_value which stands for waveform_element_value. This comes directly from iirs.ads, so no plan to change it immediately. 2) The output needs a root element like design_file and a version number for the AST version. That was only an excerpt. The start of the file is: https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Hello Tristan,I have seen many bad structured XML formats in my life, but GHDL's output looks VERY GOOD! Especially that you use XML attributes and ids.Two notes:1)You are almost using long readable names except for el and we. Can give the long name?2)The output needs a root element like design_file and a version number for the AST version.To the community: Is an XSD required?E.g. It allows easier versioning and better tool integrations.Kind regards Patrick ---Wissenschaftliche HilfskraftTechnische Universität DresdenFakultät InformatikInstitut für Technische InformatikLehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur 01062 Dresden, GERMANYTel.: +49 351 463-38451 Fax: +49 351 463-38324E-Mail: patrick.lehm...@tu-dresden.de WWW:http://vlsi-eda.inf.tu-dresden.de Ursprüngliche Nachricht Von: Tristan Gingold Datum:15.10.2016 08:22 (GMT+01:00) An: ghdl-discuss@gna.org Betreff: Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump Hello, I have just added a new command to dump the AST tree in XML: ghdl --file-to-xml FILEs The output can be very large (XML is not compact, and even std.standard is not small). See iirs.ads for documentation of the fields. Enjoy (or not). Comments and suggestions are welcome. Tristan. As an example, the XML part for: architecture behav of simple1 is signal s : bit; begin s <= '1'; process begin report "Start of simple1" severity note; assert s = '0' severity failure; wait for 0 ns; assert s = '1' severity failure; wait; end process; end behav; is: file="simple1.vhdl" line="4" col="14" identifier="behav" foreign_flag="false" visible_flag="true" is_within_flag="false" end_has_reserved_id="false" end_has_identifier="true"> line="4" col="23" identifier="simple1" is_forward_ref="false" expr_staticness="???" name_staticness="???"> line="5" col="10" identifier="s" has_disconnect_flag="false" has_active_flag="false" has_identifier_list="false" visible_flag="true" after_drivers_flag="false" use_flag="false" is_ref="false" guarded_signal_flag="false" signal_kind="bus" expr_staticness="none" name_staticness="local"> file="simple1.vhdl" line="5" col="14" identifier="bit" is_forward_ref="false" expr_staticness="???" name_staticness="???"> file="simple1.vhdl" line="7" col="3" label="" delay_mechanism="inertial" postponed_flag="false" visible_flag="false" guarded_target_state="false"> line="7" col="3" identifier="s" is_forward_ref="false" expr_staticness="none" name_staticness="local"> file="simple1.vhdl" line="7" col="8"> file="simple1.vhdl" line="7" col="8" identifier="'1'" is_forward_ref="false" expr_staticness="local" name_staticness="local"> line="9" col="3" label="" seen_flag="false" end_has_postponed="false" suspend_flag="true" passive_flag="false" postponed_flag="false" visible_flag="false&
Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump
Hello, I have just added a new command to dump the AST tree in XML: ghdl --file-to-xml FILEs The output can be very large (XML is not compact, and even std.standard is not small). See iirs.ads for documentation of the fields. Enjoy (or not). Comments and suggestions are welcome. Tristan. As an example, the XML part for: architecture behav of simple1 is signal s : bit; begin s <= '1'; process begin report "Start of simple1" severity note; assert s = '0' severity failure; wait for 0 ns; assert s = '1' severity failure; wait; end process; end behav; is: file="simple1.vhdl" line="4" col="14" identifier="behav" foreign_flag="false" visible_flag="true" is_within_flag="false" end_has_reserved_id="false" end_has_identifier="true"> line="4" col="23" identifier="simple1" is_forward_ref="false" expr_staticness="???" name_staticness="???"> line="5" col="10" identifier="s" has_disconnect_flag="false" has_active_flag="false" has_identifier_list="false" visible_flag="true" after_drivers_flag="false" use_flag="false" is_ref="false" guarded_signal_flag="false" signal_kind="bus" expr_staticness="none" name_staticness="local"> file="simple1.vhdl" line="7" col="8"> file="simple1.vhdl" line="7" col="8" identifier="'1'" is_forward_ref="false" expr_staticness="local" name_staticness="local"> visible_flag="false" is_within_flag="false" has_label="false" has_is="false" end_has_reserved_id="true" end_has_identifier="false" wait_state="unknown"> file="simple1.vhdl" line="11" col="5" label="" visible_flag="false"> file="simple1.vhdl" line="11" col="40" identifier="note" is_forward_ref="false" expr_staticness="local" name_staticness="local"> string_length="16" has_signed="false" has_sign="false" has_length="false" bit_string_base="BASE_NONE" expr_staticness="local"> kind="array_subtype_definition" file="simple1.vhdl" line="11" col="12" resolved_flag="false" signal_type_flag="true" has_signal_flag="false" index_constraint_flag="true" type_staticness="local" constraint_state="fully constrained"> file="simple1.vhdl" line="12" col="5" label="" visible_flag="false"> kind="equality_operator" file="simple1.vhdl" line="12" col="14" expr_staticness="none"> file="simple1.vhdl" line="12" col="12" identifier="s" is_forward_ref="false" expr_staticness="none" name_staticness="local">
Re: [Ghdl-discuss] Synthesis for FPGAs
I agree 100% with you Adrien. That's why I'm asking for a GHDL collaboration. Even when Yodl is providing some results. El 11/10/16 a las 15:37, Adrien Prost-Boucle escribió: Moreover, when we need a parser it's in most cases to do something that is not directly related to it, but still _needs_ it. The development time needed to have half of a parser is high and not rewarding since it's a component and not the core of the target tool. -- Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA FAX: (+54 11) 4754 5194 Buenos Aires * Argentina ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On Tue, Oct 11, 2016 at 8:03 PM, Tristan Gingold wrote: > On 11/10/16 13:25, Salvador Eduardo Tropea wrote: > > [...] > > Additional data: now that iCE40 FPGAs are working the IceStorm people is >> putting effort on reverse engineering the Xilinx 7 family. >> > > Do you have links on that effort ? Hi Tristan, I've asked Clifford Wolf if he was documenting the process along the way but didn't get a response. You may want to poke him... Here's where it starts: https://twitter.com/oe1cxw/status/782257812114116608 Regards, -Pascal -- Homepage (http://www.ece.mcgill.ca/~pgiard1) Debian GNU/Linux (http://www.debian.org) TCL: École polytechnique fédérale de Lausanne (http://tcl.epfl.ch) ISIP Laboratory: McGill (http://www.isip.ece.mcgill.ca) COMunité/LACIME: École de technologie supérieure (http://comunite.etsmtl.ca) ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On Tue, 2016-10-11 at 20:03 +0200, Tristan Gingold wrote: > On 11/10/16 13:25, Salvador Eduardo Tropea wrote: > > [...] > > > > > Additional data: now that iCE40 FPGAs are working the IceStorm > > people is > > putting effort on reverse engineering the Xilinx 7 family. > > Do you have links on that effort ? There is at least a Twitter message: https://twitter.com/oe1cxw/status/782257812114116608 ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 11/10/16 13:25, Salvador Eduardo Tropea wrote: [...] Additional data: now that iCE40 FPGAs are working the IceStorm people is putting effort on reverse engineering the Xilinx 7 family. Do you have links on that effort ? ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 11/10/16 15:45, Salvador Eduardo Tropea wrote: A note to make things more clear: Yosys converts Verilog into an AST, GHDL also does it. The point is: if we manage to convert GHDL's AST into the Yosys AST we get a VHDL synthesis tool ;-) That's not so easy because the AST are very different. I think it would be simpler to directly generate a pre-netlist from GHDL AST. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
A note to make things more clear: Yosys converts Verilog into an AST, GHDL also does it. The point is: if we manage to convert GHDL's AST into the Yosys AST we get a VHDL synthesis tool ;-) -- Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA FAX: (+54 11) 4754 5194 Buenos Aires * Argentina ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
> It slightly helps integration but the main problem is still present: > the AST changes frequently. Not a problem, it's part of the game :-) Like LLVM / CLang, the AST changes frequently, and it's the swiss army of C/C++ parsers / formatters / etc. There is an attempts at having a reduced API that they maintain stable (libclang if I remember correctly), but everybody doing serious stuff uses the AST. > Creating a lib isn't very hard to do. But I doubt that this will > generate a lot of interest compared to a JSON/XML output. It think it would. - embedded parser = less burden for users of resulting tools - if it compiles, then it works (99% of chances, but it alleviates testing) - developers can stick to a version of the AST and hence of the parser, no problem Update to newer lib version when very much needed, e.g. support for new VHDL standard, etc - faster ? - no burden about maintaining XML/JSON dumpers and parsers Also quoting your latest message: > If you look at disp_vhdl, this module is able to reprint vhdl sources from > the AST. GHDL can also reprint VHDL? So much icing on the cake :-] Then with a generic lib anyone can reuse, how could the GHDL project be more universal than that? ;-) We've suffered too much all these years trying to build up toy and ugly and unreusable stuff each time we needed to do something with VHDL. I have a dream that one day there is a lib! Nobody will have any excuse using re-developped parser, standard-locked, non-standard compliant, for synthesis tool suites. The real problem becomes maintaining headers for C/C++... But this could be done only for major changes of the AST, should be doable? Regards, Adrien ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Are we talking about something like what yosys does for verilog? If so, have the work of Tim Edwards in memory: http://www.opencircuitdesign.com/qflow/index.html Alliance and Coriolis efforts from https://soc-extras.lip6.fr/en/alliance-abstract-en/ Mostly ASIC related backend stuff, but FPGA most likely needs to be routed by the proprietary tools. I guess mapping to FPGA can be done by FOSS tools if there is a logic library available. -- Svenn ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 04/10/16 13:09, Brian Drummond wrote: On Tue, 2016-10-04 at 05:49 +0200, Tristan Gingold wrote: On 03/10/16 22:33, why...@f-cpu.org wrote: Why ? Instead of translating the AST to mcode, you can write a pass that transform it into a netlist. That was always on my TODO list, I just have to find the time to do it. Tristan. How would one go about it? It seems to me that the "ortho" language would be a good place to start - looks like it can already be read and written independently of the backend, and its reader is relatively simple - how does this relate to the AST? Code in Translate packages compiles the AST to mcode, but that's really for simulation, not synthesis. Is it actually a representation of the AST or has it already been linearised by a tree walker? I would say none of that. Each node of the AST is read to generate code. Would it nevertheless be a possible place to start, or would it be better to go further back, and if so, where in the source? (I'm guessing, that would be the input to "translate") Yes, synthesis should start with the input of translate. For a point in the code, see Compile_Elab in ghdlrun.adb Tristan. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On Tue, 2016-10-04 at 05:49 +0200, Tristan Gingold wrote: > On 03/10/16 22:33, why...@f-cpu.org wrote: > > > > Why ? Instead of translating the AST to mcode, you can write a pass > that transform it into a netlist. That was always on my TODO list, > I > just have to find the time to do it. > > Tristan. How would one go about it? It seems to me that the "ortho" language would be a good place to start - looks like it can already be read and written independently of the backend, and its reader is relatively simple - how does this relate to the AST? Is it actually a representation of the AST or has it already been linearised by a tree walker? Would it nevertheless be a possible place to start, or would it be better to go further back, and if so, where in the source? (I'm guessing, that would be the input to "translate") -- Brian ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 03/10/16 22:33, why...@f-cpu.org wrote: Le 2016-10-03 22:23, Adam Jensen a écrit : On 10/03/2016 02:19 PM, why...@f-cpu.org wrote: Let's think again about an idea I suggested, probably in 2009... Can you find a link to that suggestion? I would like to read it and trace this idea's history. No link or idea where I wrote about it in public but the idea of using GHDL for synthesis is far from new and GHDL is obviously NOT designed for sysnthesis. Why ? Instead of translating the AST to mcode, you can write a pass that transform it into a netlist. That was always on my TODO list, I just have to find the time to do it. Tristan. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/03/2016 04:33 PM, why...@f-cpu.org wrote: > But as you know, ideas are cheap. > Implementation will always be the king. LOL, but I think I understand your perspective. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Le 2016-10-03 22:23, Adam Jensen a écrit : On 10/03/2016 02:19 PM, why...@f-cpu.org wrote: Let's think again about an idea I suggested, probably in 2009... Can you find a link to that suggestion? I would like to read it and trace this idea's history. No link or idea where I wrote about it in public but the idea of using GHDL for synthesis is far from new and GHDL is obviously NOT designed for sysnthesis. However if GHDL generates code (like with the mcode version), then it's possible to tweak the code and add "useful features" that then generates the desired DDFG when it's run. I doubt I clearly see what you have envisioned but kudos for the novelty, innovation, and generally for thinking outside of the box! Thanks. But as you know, ideas are cheap. Implementation will always be the king. I can only knock on the door of the GHDL kingdom, I'm not even capable of compiling it. So maybe a mcode fork is possible, adding "tagging" of signals, export as an internal representation, then "walking" through the signal chain from the outputs... But I'm not able to implement it :-( yg ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Hello,I started to write a VHDL parser some weeks ago. It's written in Python with documentation extraction in mind. The parser supports VHDL-2008, I don't know if I want to support 2002, 93 or 87 too.The parser is streaming oriented and needs several passes. Different proof of concepts show what's possible with my uncommon parsing approach. Sure it could be used for more complex flows like netlist generation, but I don't think if this is a good idea ...Current /planned passes:1. Character grouping as tokens (space, string, char)2. Token replacement (e.g. by keyword tokens) and grouping into blocks3.a) grouping blocks into groups (not published)3.b) transform blocks into a VHDL DOM4. resolve symbols (planned)5. create an in-memory netlistPossible use cases:a) compile order extractionb) documentation extraction (-> Shpinx / ReadTheDocs)c) syntax highlightling / linked syntaxd) rewrite VHDL-2008 to synthesizable VHDL-93 codec) rewrite to Verilog, ...My code and an example is published at https://github.com/Paebbels/pyVHDLParserThe current code base is huge but very fast. There should be space for optimizations.P.S. It's also possible to translate my parser into pure C with a simple stack, a record and one function pointer per state :).Kind regards Patrick---Wissenschaftliche HilfskraftTechnische Universität DresdenFakultät InformatikInstitut für Technische InformatikLehrstuhl VLSI-Entwurfssysteme, Diagnostik und Architektur 01062 Dresden, GERMANYTel.: +49 351 463-38451 Fax: +49 351 463-38324E-Mail: patrick.lehm...@tu-dresden.de WWW:http://vlsi-eda.inf.tu-dresden.de Ursprüngliche Nachricht Von: Adrien Prost-Boucle Datum:03.10.2016 20:09 (GMT+01:00) An: GHDL discuss list Betreff: Re: [Ghdl-discuss] Synthesis for FPGAs Hi, Synthesis and simulation are indeed completely different things. There are a few Verilog-to-VHDL tools such as vhdl2verilog http://www.edautils.com/vhdl2verilog.html vhd2vl http://doolittle.icarus.com/~larry/vhd2vl/ vhdlpp https://github.com/steveicarus/iverilog/tree/master/vhdlpp But all of them could implement their own, limited VHDL parser. Limited as much in syntax checking and in functionalities and conversion abilities. As VHDL is a programming language with complicated features, I think that parsing it is in fact a challenge. Being able to reuse a good parser would be very helpful, and there is no doubt GHDL's is the best out there in the open-source world. Also, existing code introspection features certainly strongly help conversion, for translation to Verilog as well as doing synthesis: executing functions that just generate constants or do casts, etc. Even if you consider that as the "simplest" part, it's still a big part, and any reuse of good stuff would saves a lot of reinvent-the-wheel time and allow to better focus on the the rest. Regards, Adrien On Mon, 2016-10-03 at 19:18 +0200, Walter F.J. Mueller wrote: > Hi all, > > open source synthesis is fine. Can be quite independent of the > target device, with limited knowledge of it one can get probably > quite far. Using such a tool to generate a netlist and the vendor > tool chains for implementation ((place and route) and bitstream > generation might be worth a try. > > But for the implementation step and bitstream generation, as tried > in icestorm, one needs a very precise timing model and lots of other > very deep knowledge about the target device. And in case of a mistake > in implementation one can easily burn up an FPGA. > > And to your question: simulation, as done by ghdl, and synthesis, as > done by Yosys, are very different things. They both start with a > parser for the input language (VHDL), but that's in fact the simplest > part. > > > > With best regards, Walter > > > > On 10/03/2016 06:21 PM, Salvador Eduardo Tropea wrote: > > > > Hi All! > > > > > > Last year the first free software tool chain for FPGAs emerged. The IceStorm (http://www.clifford.at/icestorm/) project allows > > synthesis from Verilog for Lattice iCE40 FPGAs. > > > > > > This tool-chain uses Yosys (http://www.clifford.at/yosys/) as base. > > > > > > But no VHDL. Recently Yodl (https://github.com/forflo/yodl) emerged. Yodl is an effort to do what Yosys does for Verilog, but for VHDL. > > > > I'm a complete ignorant about GHDL, Yosys and Yodl internals, but I'm curious about the synergy between GHDL and Yodl. > > > > I know GHDL is ADA code and I see Yodl is C++. But I see Yodl people having some problems (or doubts) about the VHDL parser. > > > > Just wondering ... > > > > Regar
Re: [Ghdl-discuss] Synthesis for FPGAs
On 10/03/2016 02:19 PM, why...@f-cpu.org wrote: > Let's think again about an idea I suggested, probably in 2009... > Can you find a link to that suggestion? I would like to read it and trace this idea's history. > GHDL is a VHDL compiler. > Let's create a pseudo-machine target where the generated code > can be simulated, when run by a virtual machine, which will also > tag data as they pass throught function, ports etc. > > A few runs will "discover", or simply "cover" all the datapaths > and thus create a directed dependency graph, which can be then > traced back from the outputs. > > There, you have a synthesiser which would seamlessly integrate > with the best open source VHDL simulator. I doubt I clearly see what you have envisioned but kudos for the novelty, innovation, and generally for thinking outside of the box! ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
I'm not sure about what whar your idea consists in... Are you suggesting to integrate a special back-end to GHDL? I think the problen of interfacing the generated stuff with the rest of the world would remain. Or should GHDL perform the discovery / coverage of the directed dependency graph and generate that in a data format that others can import? But for synthesis your approach would drop attributes that are very often used in VHDL to guide synthesis, such as implementation of arrays (RAM blocks vs. distributed RAM vs. registers), attribute KEEP, etc. List alsolutely not exhaustive xD Also I think your approach would be of little help for translation to Verilog and for auto-formatting of VHDL or modifying it for certain functionalities. I have always been thinking that making the GHDL parser a shared library would be very useful. With headers for use by external tools written in other languages, C/C++ in particular. That way synthesis tools that use it would have full design information and be able to do their own implementation choices (possibly target-dependant) + other functionalities such as synthesize PSL rules and asserts (ok these are rare uses, but I am really sensitive to genericity :-) ). Adrien On Mon, 2016-10-03 at 20:19 +0200, why...@f-cpu.org wrote: > Le 2016-10-03 20:09, Adrien Prost-Boucle a écrit : > > > > Hi, > > > > Synthesis and simulation are indeed completely different things. > > > > > > > Even if you consider that as the "simplest" part, it's still a big > > part, and any reuse of good stuff would saves a lot of > > reinvent-the-wheel time and allow to better focus on the the rest. > > > > Regards, > > Adrien > > Let's think again about an idea I suggested, probably in 2009... > > GHDL is a VHDL compiler. > Let's create a pseudo-machine target where the generated code > can be simulated, when run by a virtual machine, which will also > tag data as they pass throught function, ports etc. > > A few runs will "discover", or simply "cover" all the datapaths > and thus create a directed dependency graph, which can be then > traced back from the outputs. > > There, you have a synthesiser which would seamlessly integrate > with the best open source VHDL simulator. > > yg > > ___ > Ghdl-discuss mailing list > Ghdl-discuss@gna.org > https://mail.gna.org/listinfo/ghdl-discuss ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Le 2016-10-03 20:09, Adrien Prost-Boucle a écrit : Hi, Synthesis and simulation are indeed completely different things. Even if you consider that as the "simplest" part, it's still a big part, and any reuse of good stuff would saves a lot of reinvent-the-wheel time and allow to better focus on the the rest. Regards, Adrien Let's think again about an idea I suggested, probably in 2009... GHDL is a VHDL compiler. Let's create a pseudo-machine target where the generated code can be simulated, when run by a virtual machine, which will also tag data as they pass throught function, ports etc. A few runs will "discover", or simply "cover" all the datapaths and thus create a directed dependency graph, which can be then traced back from the outputs. There, you have a synthesiser which would seamlessly integrate with the best open source VHDL simulator. yg ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Hi, Synthesis and simulation are indeed completely different things. There are a few Verilog-to-VHDL tools such as vhdl2verilog http://www.edautils.com/vhdl2verilog.html vhd2vl http://doolittle.icarus.com/~larry/vhd2vl/ vhdlpp https://github.com/steveicarus/iverilog/tree/master/vhdlpp But all of them could implement their own, limited VHDL parser. Limited as much in syntax checking and in functionalities and conversion abilities. As VHDL is a programming language with complicated features, I think that parsing it is in fact a challenge. Being able to reuse a good parser would be very helpful, and there is no doubt GHDL's is the best out there in the open-source world. Also, existing code introspection features certainly strongly help conversion, for translation to Verilog as well as doing synthesis: executing functions that just generate constants or do casts, etc. Even if you consider that as the "simplest" part, it's still a big part, and any reuse of good stuff would saves a lot of reinvent-the-wheel time and allow to better focus on the the rest. Regards, Adrien On Mon, 2016-10-03 at 19:18 +0200, Walter F.J. Mueller wrote: > Hi all, > > open source synthesis is fine. Can be quite independent of the > target device, with limited knowledge of it one can get probably > quite far. Using such a tool to generate a netlist and the vendor > tool chains for implementation ((place and route) and bitstream > generation might be worth a try. > > But for the implementation step and bitstream generation, as tried > in icestorm, one needs a very precise timing model and lots of other > very deep knowledge about the target device. And in case of a mistake > in implementation one can easily burn up an FPGA. > > And to your question: simulation, as done by ghdl, and synthesis, as > done by Yosys, are very different things. They both start with a > parser for the input language (VHDL), but that's in fact the simplest > part. > > > > With best regards, Walter > > > > On 10/03/2016 06:21 PM, Salvador Eduardo Tropea wrote: > > > > Hi All! > > > > > > Last year the first free software tool chain for FPGAs emerged. The > > > > IceStorm (http://www.clifford.at/icestorm/) project allows > > synthesis from Verilog for Lattice iCE40 FPGAs. > > > > > > This tool-chain uses Yosys (http://www.clifford.at/yosys/) as base. > > > > > > But no VHDL. Recently Yodl (https://github.com/forflo/yodl) emerged. > > > > Yodl is an effort to do what Yosys does for Verilog, but for VHDL. > > > > I'm a complete ignorant about GHDL, Yosys and Yodl internals, but I'm > > curious about the synergy between GHDL and Yodl. > > > > I know GHDL is ADA code and I see Yodl is C++. But I see Yodl people having > > some problems (or doubts) about the VHDL parser. > > > > Just wondering ... > > > > Regards, Salvador > > > > P.D: I know IceStorm currently support > > http://www.edautils.com/vhdl2verilog.html and this is an incomplete > > solution. > > > > > ___ > Ghdl-discuss mailing list > Ghdl-discuss@gna.org > https://mail.gna.org/listinfo/ghdl-discuss ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
Re: [Ghdl-discuss] Synthesis for FPGAs
Hi all, open source synthesis is fine. Can be quite independent of the target device, with limited knowledge of it one can get probably quite far. Using such a tool to generate a netlist and the vendor tool chains for implementation ((place and route) and bitstream generation might be worth a try. But for the implementation step and bitstream generation, as tried in icestorm, one needs a very precise timing model and lots of other very deep knowledge about the target device. And in case of a mistake in implementation one can easily burn up an FPGA. And to your question: simulation, as done by ghdl, and synthesis, as done by Yosys, are very different things. They both start with a parser for the input language (VHDL), but that's in fact the simplest part. With best regards, Walter On 10/03/2016 06:21 PM, Salvador Eduardo Tropea wrote: Hi All! Last year the first free software tool chain for FPGAs emerged. The IceStorm (http://www.clifford.at/icestorm/) project allows synthesis from Verilog for Lattice iCE40 FPGAs. This tool-chain uses Yosys (http://www.clifford.at/yosys/) as base. But no VHDL. Recently Yodl (https://github.com/forflo/yodl) emerged. Yodl is an effort to do what Yosys does for Verilog, but for VHDL. I'm a complete ignorant about GHDL, Yosys and Yodl internals, but I'm curious about the synergy between GHDL and Yodl. I know GHDL is ADA code and I see Yodl is C++. But I see Yodl people having some problems (or doubts) about the VHDL parser. Just wondering ... Regards, Salvador P.D: I know IceStorm currently support http://www.edautils.com/vhdl2verilog.html and this is an incomplete solution. ___ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
