[myhdl-list] A design question: "Exposing" signals
Brought to you by:
jandecaluwe
From: Nick P. <np...@in...> - 2003-10-05 23:25:21
|
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 |