Busports

From GNU Radio
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Introducing Busports

  • Notionally, busports act as ganged sources or sinks.
  • A connection between busports represents connection(s) between the underlying ports.

prots.png
No_ports.png

Any Block Can Be Bussified

  • Right click on a block to toggle source/sink bus feature.
  • Toggling will scrub connections on the bus.

toggle.png

A Key to Reading Busports

  • Busports are wildcard colored (white).
  • They're fatter than ordinary ports.
  • To the left of the hash is the index of the port.
  • To the right is the number of ports represented by the busport.

close-up.png

Busport DTD Issues

  • <!ELEMENT block (key, param*, bus_sink?, bus_source?)>
    • For GRC flowgraph files.
    • The xml definition for a block may now contain bus_sink or bus_source fields.
    • These fields follow the params fields, sink first followed by source.
    • Busports are binary... if the field exists, they're on.
  • <!ELEMENT block (name, key, category?, throttle?, import*, var_make?, make, callback*, param*, bus_sink?, bus_source?, check*, sink*, source*, bus_structure_sink?, bus_structure_source?, ** doc?, grc_source?)>
    • Likewise for block XML definitions.
    • bus_structure_sink and bus_structure_source are optional fields following the sink and source fields.

Wait a Second... bus_structure?

  • Yep, there's actually a reason for including the bus index in the port label: there can be multiple busports per source/sink, and they're pretty flexible.
[ [i_{0,0}, i_{0,1}, … , i_{0,m_0}],
[i_{1,0}, i_{1,1}, … , i_{1,m_1}],
…
[i_{n,0}, i_{n,0}, … , i_{n,m_n}] ]
  • Python list of lists naming the indices represented by each port.

multi-busses.png

What Does It Mean to Connect?

  • When you connect the j^th source busport to the l^th sink busport, source port i_{j,k} is connected to sink port i_{l,k} for each k in {0, 1, … , m_j}. It's up to the user to ensure sink and source ports correspond in type and number.
  • What if you don't specify the bus_structure to define these indices? One will be provided for you.

Here's the default:

  • [ [0,1,...,m] ]

(m is the total number of ports).
bus_connections.png

Busports and Hier Blocks

  • First, pad sources and sinks support multiple streams (nports). You can bussify pads (or any other block with sources/sinks).
  • There are new Bus Source/Sink and Bus Source/Sink Structure properties for defining hier block XML files.
  • You can use variables or parameters in bus_structure_sink/source properties (just as you can with nports).

heir_block.png

Some Details (FWIW)

  • When a source/sink is bussified, GRC adds a port of type “bus” for each index list in the source/sink structure (by default, there is one).
  • GRC keeps its port lists sorted, so busports come at the end of the list. Keys for busports will show up in the connections list of a .grc file.
  • Busports are a GRC-centric concept. Busports affect the python generated by GRC in that they shape connections lists, but busports themselves don't show up in the python.

Motivation

  • BER curves need lots of connections!(github/namccart/fecapi)
  • In general, GRC should evolve to do more dynamic/inductive things. The nports property represents a first small step in that direction, but what good is it to create an arbitrary, variable-dependent number of ports if you still have to connect all the ports manually?
  • I expect there to follow more improvements to GRC yielding a visual language for “doing things n times” and generating corresponding python.
  • What Python(ic) features are worth encoding visually as stream-processing features?