Hi, On Mon, Mar 23, 2015 at 12:41 PM, Henry Gomersall <heng@cantab.net> wrote:
On 23/03/15 12:10, Sarah Mount wrote:
<snip>
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?
Ah, my mistake.
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).
Thanks, that has certainly clarified things for me.
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.
Hmm. So, what I understand from this is that your current front-end implements a very small subset of Python, you have noticed that RPython implements a slightly larger subset of Python, so you want to replace your front-end and maybe some internals with the RPython equivalents? I'm not sure how well this will work. For one thing, RPython is intended to be translated to a native format (i.e. you take a description of an interpreter or VM in RPython and after a very long compile you get a native executable that is your interpreter, with any RPython internals, such as JITs and GCs, included). I'm not sure if this is a win for you or not, because I'm not sure if an RPython front-end can really be made to fit a MyHDL back-end, without just re-writing the whole thing as an interpreter. Cheers, Sarah -- Dr. Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2