-
Notifications
You must be signed in to change notification settings - Fork 25
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The main change in TaPaSCo 2020.10 is the new runtime. It is completely re-engineered in Rust and comes with many improvements like better error handling and multithreading support. This change requires the rust compiler as a prerequisite (please get a recent version via https://rustup.rs/). Other changes included in the release are: * Standardized feature to connect PEs to network ports for supported platforms (VC709, ZC706, XUP-VVH, NetFPGA-SUME) * The addition of the Alveo U280 data center card as a supported card * Support for Vivado 2020.1 and CentOS 8 This release closes 12 [issues](https://github.com/esa-tu-darmstadt/tapasco/issues?q=is%3Aissue+milestone%3A2020.10+is%3Aclosed) closed in over 260 commits.
- Loading branch information
Showing
301 changed files
with
12,192 additions
and
23,484 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,106 @@ | ||
| SFPPLUS in TaPaSCo | ||
| =================== | ||
|
|
||
| A number of platforms in TaPaSCo provide the SFP+-feature which allows to send/recieve network packets. | ||
| The following will describe the general configuration format. | ||
| The information, which platforms are supported, as well as platform specific information (like the number of available SPF+ Ports), | ||
| can be found [here](tapasco-features.md). | ||
|
|
||
| ## Configuration format | ||
|
|
||
| The configuration format is split into two parts: | ||
| 1. The [Port Definition](#port-definition) | ||
| 2. The [Connections of PEs](#pe-connections) to ports | ||
|
|
||
|
|
||
| ### Port Definition | ||
|
|
||
| Here you can specify a list of ports. Each port has four properties: | ||
| - The name of the port: Used to reference the port when specifiying the connections | ||
| - The mode of the port: How PEs are connected to the port ([singular](#singular-mode), [roundrobin](#roundrobin-mode), [broadcast](#broadcast-mode)) | ||
| - The physical port number: Depends on the platform, see [TaPaSCo Features](tapasco-features.md) | ||
| - Where the clock synchronization should occur: Either the synchronization is done via AXI-Stream interconnects (`ic_sync: true`). | ||
| Alternatively the synchronization can be handled by the PE (`ic_sync: false`). In the latter case the PE must have a separate | ||
| clock/reset-pair for each AXI-Stream interface. | ||
|
|
||
| Example: | ||
|
|
||
| ``` | ||
| SFPPLUS { | ||
| "Ports": [ | ||
| { | ||
| "name": "port_A", | ||
| "mode": "singular", | ||
| "physical_port": "0", | ||
| "ic_sync": false | ||
| }, | ||
| { | ||
| "name": "port_B", | ||
| "mode": "roundrobin", | ||
| "physical_port": "1", | ||
| "ic_sync": true | ||
| } | ||
| ], | ||
| ... | ||
| } | ||
| ``` | ||
|
|
||
| #### Singular Mode | ||
|
|
||
| In this mode each Port can only have one sending AXIS-Interface and one recieving AXIS-Interface connected. They are directly connected to the port. | ||
|
|
||
| #### Roundrobin Mode | ||
|
|
||
| In this mode the packets recieved on the port are distributed to all connected AXIS-Interface round-robin: The first recieved packet is forwarded | ||
| to the first AXIS-Interface, the second packet to the second AXIS-Interface and so on... | ||
|
|
||
| #### Broadcast Mode | ||
|
|
||
| In this mode all recieved packets are forwarded to all connected AXIS-Interfaces. | ||
|
|
||
| ### PE Connections | ||
|
|
||
| Here you first define groups of PEs and then for each group how their AXIS-Interfaces are mapped to the ports. | ||
| A group of PE is defined by the ID of the PE-Type and a number. Each PE in your composition may only be used | ||
| in one of these groups. Each group defines mappings from their AXIS-Interfaces to ports. | ||
| A mapping consists of | ||
| - the name of the interface | ||
| - the direction: `rx` for recieving packets and `tx` for sending packets | ||
| - the port name ([see](#port-definition)) | ||
|
|
||
| Example: | ||
|
|
||
| ``` | ||
| SFPPLUS { | ||
| ... | ||
| "PEs": [ | ||
| { | ||
| "ID": "PE1", | ||
| "Count": "1", | ||
| "mappings": [ | ||
| { | ||
| "interface": "sfp_axis_0_rx", | ||
| "direction": "rx", | ||
| "port": "port_A" | ||
| }, | ||
| { | ||
| "interface": "sfp_axis_0_tx", | ||
| "direction": "tx", | ||
| "port": "port_A" | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "ID": "PE2", | ||
| "Count": "4", | ||
| "mappings": [ | ||
| { | ||
| "interface": "sfp_axis_0_rx", | ||
| "direction": "rx", | ||
| "port": "port_B" | ||
| } | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` |
Oops, something went wrong.