[myhdl-list] Re: A design question: "Exposing" signals

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

Nick Patavalis wrote:
> Imagine a high-level block ("superblock"), with an instantiation
> function defined like this:
> 
>   def gen_superblock(sig1, sig2, sig3):
> 	s1 = Signal(...)
>         s2 = Signal(...)
>         ...
> 	s100 = Signal(...)
> 
>         fb = []
> 	fb.append(gen_simpleblock1(sig1, s1, s2, s30)
> 	fb.append(gen_simpleblock2(s1, sig2, s7, sig1)
> 	fb.append(gen_simpleblock1(s10, s20, s30, sig3)
>         ...
> 	return fb
> 
> As you can see this block is connected to some "external" signals
> given as arguments to its instantiation function (here: "sig1",
> "sig2", "sig3"). Internally "gen_superblock" creates several
> "internal" signals (s1, s2, ..., s100) and instantiates many simpler
> blocks connecting them to the external and internal signals. It finaly
> returns the list of the instantiated blocks to the caller.
> 
> Now assume that for some reason (and I can think of several such
> reasons), the block wants to **expose** some of its internal signals,
> so that other blocks can connect to them, should they wish to. The
> obvious solution is to consider the exposed signals as external, and
> have them supplied by the caller (as arguments to superblock's
> instantiation function). While this is technically sufficient, it
> doesn't "map" to the concept of "exposing" very well. By treating the
> exposed signals as external, it's like saying that they're not
> internal to the block anymore, that they *must* be supplied by the
> caller, that the caller *must* take the burden of creating and
> initializing them. But most typical callers should not need to worry
> (or even know much) about these "exposed" signals.
> 
> Another approach would be to treat exposed signals like this (assume
> you want to expose s10, s20, s30, ... s100):
> 
>   def gen_superblock(sig1, sig1, sig2, sig3):
> 	s1 = Signal(...)
>         s2 = Signal(...)
>         ...
> 	s100 = Signal(...)
> 
>         fb = []
> 	fb.append(gen_simpleblock1(sig1, s1, s2, s30)
> 	fb.append(gen_simpleblock2(s1, sig2, s7, sig1)
> 	fb.append(gen_simpleblock1(s10, s20, s30, sig3)
>         ...
> 
> 	class sigs_exposed: pass
> 	exposed = sigs_exposed()
> 	exposed.s10 = s10
> 	exposed.s20 = s20
> 	exposed.s30 = s30
>         ...
> 	exposed.s100 = s100
> 
> 	return fb, exp
> 
> Now, ordinary callers don't need to worry about the exposed signals,
> they can simply ignore the second return-value like this:
> 
>    supeblock, dummy = gen_superblock(sig1, sig2, sig3)
> 
> or even more blatantly like this:
> 
>    supeblock = gen_superblock(sig1, sig2, sig3)[0]
> 
> but still these signals can be used by callers knowing a bit more
> about the inner-workings of "superblock", like for example by testing
> or tracing blocks.
> 
> This approach looks very clean, and very "pythonic" to
> me. Unfortunately it breaks the almost-explicit assumption that
> instantiation functions must return *only* the instantiated blocks,
> and cannot return additional information about them.
> 
> Any comments welcome.

This is a reasonably (and anticipated) request, which should have
an even more pythonic solution!

Some background:
- in MyHDL, an instance is modeled as a (nested) sequence (of 
generators). One way to create them is to return them from 
functions. However, this is not and should not be a requirement.
- one can start with MyHDL without having to know anything about
classes, which is nice I think. However, classes are of course 
available to accomplish more interesting things. 
- since Python2.2, it is possible to subclass built-in Python types.

The way I envisage to solve this is therefore to model a module
as a class that inherits from 'list', instead of as a function,
e.g. as follows:

class gen_superblock(list):

    def __init__(self, sig1, sig2, sig3):

        self.s1 = s1 = Signal(...)
        self.s2 = s2 = Signal(...)
        ...
        self.s100 = s100 = Signal(...)

        fb = []
	fb.append(gen_simpleblock1(sig1, s1, s2, s30)
	fb.append(gen_simpleblock2(s1, sig2, s7, sig1)
	fb.append(gen_simpleblock1(s10, s20, s30, sig3)
        ...
        self[:] = fb
      
So, the desired signals will be available as attributes of
the instance. Moreover, any other interesting thing may
be made available in the same way. And, this should 
work with MyHDL as it stands today.

Caution: though I anticipated this style in the implementation,
I have not tried it myself yet.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Bored with EDA the way it is? Check this:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html