Busports: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 7: Line 7:


= Any Block Can Be Bussified =
= Any Block Can Be Bussified =
[[File:Busport-demo.gif]]


* Right click on a block to toggle source/sink bus feature.
* Right click on a block to toggle source/sink bus feature.
Line 48: Line 50:
* What if you don't specify the bus_structure to define these indices? One will be provided for you.<br />
* What if you don't specify the bus_structure to define these indices? One will be provided for you.<br />
Here's the default:
Here's the default:
* [ [0,1,...,m] ]<br />
<pre>[ [0,1,...,m] ]</pre>
(m is the total number of ports).<br />
(m is the total number of ports).<br />
[[File:bus_connections.png|bus_connections.png]]
[[File:bus_connections.png|bus_connections.png]]

Latest revision as of 09:59, 8 January 2024

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

Busport-demo.gif

  • 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?