Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump

2016-11-14 Thread Martin Strubel

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 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

2016-10-27 Thread René Doß


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

2016-10-27 Thread Martin Strubel


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

2016-10-26 Thread Martin Strubel

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

2016-10-26 Thread Adam Jensen
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

2016-10-26 Thread Brian L. Drummond
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 <ghdl-discuss-boun...@gna.org> on behalf of Vern Muhr 
<vern.m...@gmail.com>
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 / XML dump

2016-10-24 Thread Martin Strubel

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

2016-10-17 Thread whygee

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

2016-10-17 Thread Tristan Gingold

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

2016-10-17 Thread Tristan Gingold

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

2016-10-17 Thread whygee

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

2016-10-17 Thread Salvador Eduardo Tropea

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

2016-10-15 Thread Patrick Lehmann
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 <tging...@free.fr> 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

2016-10-15 Thread Tristan Gingold

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

2016-10-15 Thread Patrick Lehmann
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 <tging...@free.fr> 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" is_within_fla

Re: [Ghdl-discuss] Synthesis for FPGAs / XML dump

2016-10-15 Thread Tristan Gingold

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

2016-10-12 Thread Salvador Eduardo Tropea
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

2016-10-11 Thread Adrien Prost-Boucle
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

2016-10-11 Thread Salvador Eduardo Tropea
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

2016-10-05 Thread Svenn Are Bjerkem
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

2016-10-04 Thread Tristan Gingold

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

2016-10-04 Thread Brian Drummond
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

2016-10-03 Thread Tristan Gingold

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

2016-10-03 Thread Adrien Prost-Boucle
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

2016-10-03 Thread whygee

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

2016-10-03 Thread Adrien Prost-Boucle
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

2016-10-03 Thread Walter F.J. Mueller

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