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 :-)
T
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
_
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
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
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-processin
ilding 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] Syn
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
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 al
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/listinf
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)
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 signa
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)
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
interprete
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
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 effectiv
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
-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
es 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: R
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
elaborati
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
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 synthesi
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 s
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
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 des
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/
Un
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
i
016 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
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 r
richt 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 i
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.
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
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
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
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
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.
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) h
> 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 t
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
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 t
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.
>
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.
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/listinf
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 p
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/
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 generate
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 ge
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
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
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
49 matches
Mail list logo
