On 23/03/15 12:10, Sarah Mount wrote:
As it happens this is of interest to be, because I may have a use for
MyHDL or something similar in a year or so. However, from this thread
I'm a little confused about where the RPython toolchain would fit in.
Sorry if I'm completely off-base here...
Presumably you want to keep your Python (2?) front end -- you wouldn't
want application programmers using RPython directly, it is really
tricky to write in as it's designed for a very specific use case which
is very different from generic Python programming.
Well, users currently _are_ restricted to a small subset of
"convertible" python. I would suggest this is actually more restrictive
than RPython. I suppose the question I have is what happens at the
boundary with RPython - can one construct an object that is crosses the
boundary, with some RPython only methods and some general Python methods?
It might be that code that is RPython compliant cannot also use
necessary MyHDL constructs, though there may well be workarounds (it
would almost certainly not be the case that the code is too flexible).
It's worth noting the MyHDL is several overlapping things. It's first
and foremost a library for representing hardware concurrency. If a
developer is restricted to only a small subset of valid Python and
types, the blocks that are described using MyHDL constructs can be
converted into VHDL or Verilog. It allows very neat workflow - one has
the full power of Python for defining behaviour, and then one writes the
convertible code (which is verified against the behavioural model), and
then one cosimulates the converted code, verifying that is doing the
write thing (using a Verilog/VHDL simulator).
I would guess that the reason for porting MyHDL to an RPython
toolchain is that you don't just produce a flat Verilog file, but you
also have a runtime system which simulates the Verilog (or the higher
level Python description)? This sounds very interesting, I'm not sure
how helpful the RPython GCs and JIT would be in your case, but it
would be interesting to hear where you think a performance improvement
can be made.
Well, potentially, but the big win is in being allowed a broader range
of convertible constructs. For example, there is currently no way to
handle general iterables (only loops of the form `for i in range(N):`
are allowed). Clearly, this is very restrictive for writing nice,
expressive code.
Stepping back a minute. The ultimate goal IMO would be a tool that takes
a MyHDL instance block (that is, that represents the function of a
hardware block), along with the associated static namespace, and
converts into something that downstream tools can understand (VHDL or
Verilog), with as much expressive power in the code as makes sense given
the target restrictions.
All these things are possible in the current approach, but I've been
wondering if the similar functionality of similar tools can be used to
do some of the heavy lifting. The current approach is essentially trying
to implement a "MyHDL restricted" python to VHDL/Verilog translator.
You might have seen this paper on the PyPy status blog, on instruction
set simulators:
http://csl.cornell.edu/~cbatten/pdfs/lockhart-pydgin-ispass2015.pdf
<http://csl.cornell.edu/%7Ecbatten/pdfs/lockhart-pydgin-ispass2015.pdf> I
don't think it is quite the same as your use case, but there are some
interesting ideas in there.
That's interesting. I had seen it but not really noticed it's relevance.
Cheers,
Henry
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
