Re: [myhdl-list] Next Python to VHDL generator by using LLVM

[Jan L. <jan...@et...>]

Am 15.01.2013 19:43, schrieb Christopher Felton:
>>> On 1/15/2013 11:45 AM, David Blubaugh wrote:
>>>> I was wondering if someone has looked in the use of the LLVM to be able to generate full featured python into synthesizable VHDL with simulation support of course ??
>>>>
>>>> I STRONGLY BELIEVE YOU GUYS NEED TO LOOK AT LLVM for greatly enhancing MyHDL to support a greater domain of the python language to support synthesizable designs and testbench support.
>>> I completely disagree this is *not* something the MyHDL
>>> group should be interested in.  There would be no benefit
>>> for the MyHDL folks to look at this.
>>>
>>> In addition, other than a buzz word you didn't provide
>>> any technical arguments why this would be desirable.
>> The reason as to why this needs to be looked at is that if you want to support higher level functionality of the python language to support synthesizable HDL designs the current method is to to use a subset of the python language.  What I am talking about is the possibility of extending MyHDL capabilities of supporting ALL if not most of the higher level functionality of the python language to support advanced designs in synthesizable HDLs.  Take a look at Trident C programmingl language with LLVM support.  It supported close to 98 percent of C functionality for directed and efficient synthesizable HDL design.
>>
>> Please take a look at the following link:
>>
>> http://trident.sourceforge.net/
>>
>> This is for the C language but I wonder if an equivalent system could not be developed by using python as the central controlling programming language instead of C.  LLVM stands for low level virtual machine language that allows the expression of one language, this case python, to be implemented on an entirely different architecture (FPGAS instead of a von-neumann architecture).
>>
>> Any feedback or questions is more than appreciated !!!
>>
>> David
> I am familiar with trident, have actually used it.  I am
> familiar with LLVM (barely).  The state of trident is that
> it was used for a particular set of cases/experiments.  It
> would be difficult to use it other than experiments and
> investigation.
>
> I don't believe trident has been touched in years.  I am not
> an LLVM expert but I think LLVM fits better if you are trying
> to kludge C-family of code into something rather than something
> like Python.  At one point, I thought Uladen-Swallow Python
> (US-Python) would win out over pypy, well that appears to have
> played out and US-Python was the loser.  I don't know for sure
> but I believe US-Python didn't succeed because of limitations
> in LLVM.  I also (gut guess) don't think LLVM is ideal as
> an intermediate format for representing hardware.
>
> I believe LLVM is great for languages like C/C++ and resulted
> in cleaner C* compilers (e.g. clang).  But I don't think it is
> a cure all fit all.  I am commenting out of my league about this
> C compiler stuff, I only know the little I have read here and
> there.
>
> If someone where really interested in this LLVM -> HDL it
> won't be the MyHDL folks.  The MyHDL folks are interested
> in describing hardware in Python in the manner Jan D. has
> outlined.  Which may or many not include some HLS as it
> grows.  If you want a magic Python -> intermediate
> format -> hardware, I don't think it overlaps with the
> efforts/goals of MyHDL.  What you would want to do is get
> your LLVM->HDL working (use the trident framework, which
> by the way is in java) and when someone completes the
> Python->LLVM you will be set, but again, I don't think it
> is something that is of interest to the majority of MyHDL users.
>
> I believe, if MyHDL incorporates HLS it will be in the same
> elaboration/generator (HDL) description as exists now.  I
> believe this really fits what you would want for hardware
> description.  Instead of trying to convert a ton of Python
> code, ugh that would be a mess with or without an LLVM.
> I think you are under estimating what a Python to LLVM
> and LLVM to HDL would take and overestimating what LLVM
> provides.

Hi all,

I would like to quickly comment:

I agree that LLVM is not a solution for MyHDL. Its front end, which 
would be the interesting part, offers little more value to MyHDL than 
the introspection, bytecode compilation and builtin parsing capabilities 
that Python itself already got out of the box. In general, LLVM solves a 
problem for C/C++ that does not exist in Python. I am probably "leaning 
way too much out of the window" right now :-).

Furthermore, the value of HLS starting from Python is not that big at 
the moment. For the next time HLS will probably need a statically typed 
input language. After all, hardware is static and the stuff that is 
allowed inside the MyHDL generators is pretty much static, too.

Regards,
Jan