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

[Nick P. <np...@in...>]

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.

/npat

-- 
Mathematics belongs to God.
  -- Donald E. Knuth