On 15/03/15 22:18, Josy Boelen wrote:
> Any workaround is a good as any other workaround, but still is a
> workaround. I just added the 4 (in my actual module, not the example)
> constants in the call.
> None of the workarounds can be classified as_pythonic_, I'd say. What
> if I come up with a 8 * 8 constant matrix (like in JPEG DCT)? And it is
> well supported in VHDL ...
> I checked the _toVHDL code and process (I built a lot of tracing in my
> local copy), and it is not evident how to add support for this. But
> we'll discuss this another time? (It's bedtime over here ...)
There are quite a few conversion gotchas. I've been thinking lately
about a dynamic conversion based around PyPy - something like using a
custom object space to tease out the convertible parts from the
non-convertible parts. In principle the python parts would be fixed at
run time, or converted if possible. There would be a new set of problems
with such an approach - things that are expected to be dynamic might no
longer be so, so one might get unexpected cosimulation failures.
Anyway, it's just a mental mulling at the moment...
Henry
|
