release v1.3: VDHL-2008, SV2017, AST as Python objects, sim. part

[Nic30]

• [done] VHDL will get new full 2008 grammar
• [done] all AST object will have own class defined in Python and instantiated by C++ (JSON conversion will disappear from C++)
• [done] AST and HDL objects will be simplified to reduce codebase and to simplify processing
• [done] separate C++/Python parts, proper include directory
• [done] error reporting before it is too late
• [done] CMake C-lib only install target
• [done] replace Verilog2001 and SystemVerilog2012 by sv1800-2017
  • [done] fix performance issues A fast System Verilog grammar #53 (entirely hand rewritten grammar, all Icarus + hdlConvertor Verilog sources ~1.5s)
  • [done] fix operator priority
• [done] Verilog preprocessor: proper path stack for transitive include resolution + tests
  • [done] Python API for macro database
  • [done] fixed ifdef marco substitution, include
  • [done] expansion of macros in macro which is a result of macro expansion
  • [done] fixed __LINE__, __FILE__ [verilog preprocessor] half-working __FILE__, __LINE__ #79
• [done] full reverse conversion to Verilog/VHDL to assert the functionality
  • [done] hierarchy, connections, expressions, statements
    • [done] VHDL
    • [done] Verilog
  • functions, tasks etc.
    • [done] VHDL
    • [done] Verilog
  • sim part
    • [done] VHDL
    • [done] Verilog
• [done] move utils scripts to a separate repo
• [done] smart pointers for hdlObjects (to solve memory leaks in exception handling)

After this update:

• PIP release
  • minify change list
• [done] Lexer only mode which will print or return lexer tokens (mainly for debugging, implemented as a flag on parser/preprocessor containers)
• deb for c++ lib in public repo
• custom typedefs
  • SV
  • VHDL

[imec-myhdl]

Hi, I have used a previous version to parse our vhdl source, with the intent to convert them (partially) to myhdl (see myhdl.org), to be able to co-simulate with the rest of our system model. I am excited to see that you are working on a simple universal AST, because that will greatly ease the addition of translation to myhdl.

My question: Do you have a timeline for this simple universal AST? (weeks/months/years).

Kind regards, Paul

P.S. MyHDL already has a conversion to Verilog/Vhdl, so I would 'only' need to work out the conversion from this simplified AST to myhdl

[Nic30]

My question: Do you have a timeline for this simple universal AST? (weeks/months/years).

Month. Can be done much sooner, but I have to do some things first in order to advance in my PhD.

MyHDL already has a conversion to Verilog/Vhdl

• i know, without support for user defined types etc.
• it is the most easy part and I am not worry about it now
  • For MyHDL output I am using hdlConvertor "universal AST" -> hwt - > MyHDL, but it is only experimental feature and I did not know about anyone who would use this. So I did not put much effort in to it.

Also share link on your project.
It would be great if I can also use some tests from your project to test this library, as writing tests consumes a lot of time.

[imec-myhdl]

Hi Nic30,
I am pretty fluent in python, do occasionally write verilog, but the vhdl is rusty. I am interested in hdlConverter because we need to revive a legacy project with a lot of vhdl, while all our models and testbenches are in myhdl.

I currently work on Spyce (https://github.com/imec-myhdl/Spyce) a graphical drawing tool that generates myhdl code. It is work in progress: it does work, but there are quite some outdated blocks, and I still need to add a clear example. Do not use our myhdl branch (yet) if you want to test, because we are currently updating the fixbv implementation to be able to convert to verilog and the modifications are not backward compatible.

Unfortunately I cannot share even a line of vhdl, but of course I can test the hdlConvertor on our code base, and report the results/bugs.

Kind regards, Paul

[Nic30]

a graphical drawing tool that generates myhdl code

(May not be necessary useful to you but maybe interesting.)

3 years ago I was thinking about exactly the same thing. But I find out that it is actually much more developer friendly to write myhdl (or any other hdl) and see what the circuit looks like.
(Which leads to very hard computational problem how to draw a nice graph from the netlist... etc.)

I do have library which generates and draws such a diagrams I am using it in doc generator (example)

I can test the hdlConvertor on our code base, and report the results/bugs.

Nice, exactly what I need. (Sharing VHDL code is not required, it is always about just some construct in file and not about code as a whole.)

[imec-myhdl]

I do have library which generates and draws such a diagrams I am using it in doc generator (example)

Nice tools! You are right about developer friendly, but customers and occasional users prefer point and click (the schematic is a communication tool that happens to output executable code...) And the barrier for non language-experts is too high.

Perfect example is simulink; horrible tool, and way too expensive, yet we found that projects in matlab are never explored by non-experts, whereas simulink is used all the time. The tool is only to make the barrier lower. You would never draw a fsm for example, but simply use a myhdl view under a symbol, it is mainly useful to visualize signal-flow

Kind regards, Paul