Re: [myhdl-list] Dream Mux (still a dream for now)

[Jan D. <ja...@ja...>]

George:

A couple of points:

> Hi Jan,
> 
>     Thanks for your reply. Unfortunately, even though the above does 
> convert, I think it leaves a lot to be desired because it produces 
> long-winded, hard to follow Verilog code.

Mm. The code for 4 muxes, as can be expected.

With Python 2.5, we'll be able to write mux behavior with one-liners:

     z.next = b if sel else a

which implies that the convertor will then simply produce 4 assign
statements (using the Verilog one-liner counterpart).

> I think it's important for the 
> Verilog code to stay reaonably readable and MyHDL already does a great 
> job in that respect.

For the code that is converted, yes. Even of higher quality than what
many a Verilog coder produces. But - I keep hammering on the same nail -
not all code is/needs to be converted, and that can be used to one's
advantage. In the sense that you can produce synthesizable Verilog
even when your MyHDL code uses features for which there is no Verilog
counterpart or no support in the synthesis tool. Obviously in such
cases the Verilog output will not reflect the MyHDL input code - it
will be at a much "lower level". But it will do the same thing!

In summary, "readability" of the Verilog output is only my 3rd goal.
The first is correctness, and the second is conversion power. As I
try to show, the finest conversion results are sometimes obtained
when no code is converted at all! (Because it has been taken care
of before, by the elaboration with the Python interpreter.) And when,
consequently, the Verilog output seems unrelated to the MyHDL input.

Some of these ideas are explored on the following page:

    http://myhdl.jandecaluwe.com/doku.php/cookbook:sinecomp

A very good example of what I'm trying to say is here:

    http://myhdl.jandecaluwe.com/doku.php/cookbook:bitonic

The latter page shows that you can use structural recursion even
when your target language or synthesis tool don't support recursion
at all.

> I'm going to try to find my own solution, and I'll let you know if I 
> come up with anything. Yeah, Python hacking! :-)

Fine. But note that your original code is most likely not what
you want, because it's only sensitive to the control signal.
For proper combinatorial behavior, it should be sensitive to
the data signals as well.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com