Busports: Difference between revisions
Jump to navigation
Jump to search
(Imported from Redmine) |
|||
| Line 3: | Line 3: | ||
* Notionally, busports act as ganged sources or sinks. | * Notionally, busports act as ganged sources or sinks. | ||
* A connection between busports represents connection(s) between the underlying ports.<br /> | * A connection between busports represents connection(s) between the underlying ports.<br /> | ||
[[File:prots.png|]]<br /> | [[File:prots.png|prots.png]]<br /> | ||
[[File: | [[File:No_ports.png|No_ports.png]] | ||
= Any Block Can Be Bussified = | = Any Block Can Be Bussified = | ||
| Line 10: | Line 10: | ||
* Right click on a block to toggle source/sink bus feature. | * Right click on a block to toggle source/sink bus feature. | ||
* Toggling will scrub connections on the bus.<br /> | * Toggling will scrub connections on the bus.<br /> | ||
[[File:toggle.png|]] | [[File:toggle.png|toggle.png]] | ||
= A Key to Reading Busports = | = A Key to Reading Busports = | ||
| Line 18: | Line 18: | ||
* To the left of the hash is the index of the port. | * To the left of the hash is the index of the port. | ||
* To the right is the number of ports represented by the busport.<br /> | * To the right is the number of ports represented by the busport.<br /> | ||
[[File:close-up.png|]] | [[File:close-up.png|close-up.png]] | ||
= Busport DTD Issues = | = Busport DTD Issues = | ||
| Line 39: | Line 39: | ||
[i_{n,0}, i_{n,0}, … , i_{n,m_n}] ] | [i_{n,0}, i_{n,0}, … , i_{n,m_n}] ] | ||
* Python list of lists naming the indices represented by each port.<br /> | * Python list of lists naming the indices represented by each port.<br /> | ||
[[File:multi-busses.png|]] | [[File:multi-busses.png|multi-busses.png]] | ||
= What Does It Mean to Connect? = | = What Does It Mean to Connect? = | ||
| Line 48: | Line 48: | ||
* [ [0,1,...,m] ]<br /> | * [ [0,1,...,m] ]<br /> | ||
(m is the total number of ports).<br /> | (m is the total number of ports).<br /> | ||
[[File:bus_connections.png|]] | [[File:bus_connections.png|bus_connections.png]] | ||
= Busports and Hier Blocks = | = Busports and Hier Blocks = | ||
| Line 55: | Line 55: | ||
* There are new Bus Source/Sink and Bus Source/Sink Structure properties for defining hier block XML files. | * 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).<br /> | * You can use variables or parameters in bus_structure_sink/source properties (just as you can with nports).<br /> | ||
[[File:heir_block.png|]] | [[File:heir_block.png|heir_block.png]] | ||
= Some Details (FWIW) = | = Some Details (FWIW) = | ||
Revision as of 15:54, 18 March 2017
Introducing Busports
- Notionally, busports act as ganged sources or sinks.
- A connection between busports represents connection(s) between the underlying ports.
Any Block Can Be Bussified
- Right click on a block to toggle source/sink bus feature.
- Toggling will scrub connections on the bus.
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.
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.
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).
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).
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?