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

[George P. <ge...@ga...>]

>
> Discussing about a spec will make it possible to understand
> the issues better, and perhaps even come up with a better
> solution for what you want to achieve.
>

I agree. I've been doing some pathfinding on my own, evaluating different
methods of making the MyHDL code more readable while using (and unit
testing) hardware modules with many signals.

I've also done some experiments using classes for hardware blocks and
theres a synergistic effect with using signal bundles (dicts).

What I do know is that bundling signals using dicts seems to be a good wa=
y
to group related signals and manage complexity. The problem areas with
using  signal bundles as I seem them currently are:

Top-level modules for conversion to synthesizable Verilog:
 - Probably not much of a problem in practice, but I'll have to experimen=
t.

Using toVerilog with cosimulation:
 - Since toVerilog() requires a flat signal list, this is problematic.
   There may be a way to get around this by using some advanced Pythoning=
=20
   (such as the function wrapping features in 2.5). I'll have to
experiment.

Being required to unbundle signals for use in generators, since toVerilog
doesn't currently support directly using dicts in generators:

def module(sigs):

   # 'sigs' may contain more signals than we acutally unbundle and use.

   # This is actually clearer than using the dict directly,
   # since it describes the signal from the perspective of this module.
   # Also, it's easier to type.
   clk_i =3D sigs['clk']
   dat_o =3D sigs['drd']
   dat_i =3D sigs['dwr']

   @always(clk_i.posedge)
   def proc():
      ...

   return instances()


 - This isn't too much of a problem. I've often found that unbundling the
signals enhances readability anyway. Note this works fine in unit tests
without cosimulation. But if cosimulation doesn't support it, then the
unit tests can't really use it in practice.


 - Being able to manipulate all signals in a dict while inside a
generator,       and have the generated Verilog only contain a single
'always' block. This seems to be a strongly desireable feature, but as
you said is a lot harder to implement than the previous item.


I'm not quite sure how to start off a discussion on specs. Could you give
me a hint to get started?

Even with these problem areas, I've had considerable success already in m=
y
experiments, using classes and bundled signals. Python and MyHDL really
give me a lot of freedom to be creative.

I'm working on a ring buffer module that uses classes, signal bundling,
and some more of my 'home grown' ideas. Would it be helpful if I posted
the code and unit test sometime later?

Regards,
George


--=20
George Pantazopoulos
http://www.gammaburst.net