+
+
+
+## Table of Contents
+
+- [ZIGGO Device: A flexible and standard-compliant toolkit for TSN performance evaluation.](#ziggo-device-a-flexible-and-standard-compliant-toolkit-for-tsn-performance-evaluation)
+ - [Table of Contents](#table-of-contents)
+ - [Introduction](#introduction)
+ - [ZIGGO Open Platform](#ziggo-open-platform)
+ - [Demo](#demo)
+ - [Features](#features)
+ - [Read before start](#read-before-start)
+ - [Getting Started](#getting-started)
+ - [System Design](#system-design)
+ - [Demo APP Tutorial](#demo-app-tutorial)
+ - [License and Citation](#license-and-citation)
+ - [TODO List](#todo-list)
+ - [Contributing](#contributing)
+
+## Introduction
+
+ZIGGO is a `flexible`, `standard-compliant`, and `control-function-virtualized` TSN switch platform ready for **industrial control**, **automotive electronics**, and other **time-sensitive applications**.
+
+This is the document for the ZIGGO Device. (We also offer [ZIGGO-CaaS-Switch](https://github.com/Mobisense/Ziggo-CaaS-Switch) that comply with the IEEE 802.1 TSN standard.) Our Device supports testing all standards-compliant switches.
+
+## ZIGGO Open Platform
+
+
+
+The construction of the ZIGGO Open Platform consists of three levels: network device, management tools, and a Demo App:
+
+- The software and hardware projects, along with the development board startup [tutorial](/ZIGGO_WEB/device/getting-started/), provide instructions for setting up an individual network device.
+
+- The [CNC User Manual](docs/cnc-manual.md) and [Device User Manual](/ZIGGO_WEB/device/getting-started/) cover system configuration and management tools.
+
+- Lastly, we offer a comprehensive [Demo App building tutorial](/ZIGGO_WEB/device/testbed/) that instructs how to
+ collaboratively build a complete and functional Demo using network devices and
+ management tools.
+
+## Demo
+
+We provide a demonstration video of the TSN switch. It demonstrates the superior performance of the `ZIGGO-CaaS-Switch` compared to the normal switch.
+
+The left side of the picture is the ZYNQ development board we use, and the right side is the TSN display board we built.
+
+[](https://cloud.tsinghua.edu.cn/f/b307da6840d84e5f9ff1/)
+
+> Click the pic to watch the video! Or just click [here](https://cloud.tsinghua.edu.cn/f/b307da6840d84e5f9ff1/).
+
+## Features
+
+* ZIGGO supports the simultaneous transmission of both `Information Technology (IT)` and `Operation Technology (OT)` data traffic with QoS guarantee.
+
+* ZIGGO complies with IEEE standards `802.1AS`, `Qav`, `Qbv`, and `Qcc`.
+
+* ZIGGO provides `Real-time` and `Deterministic` Ethernet transport
+
+ * ZIGGO achieve **Zero Packet Loss** , **Microsecond-level Latency** with **Nanosecond-level Jitter Gate Ability**.
+ * ZIGGO guarantee **Gigabit Throughput**.
+ * ZIGGO provide gate accuracy applicable to **All Ethernet Frame Sizes**.
+
+## Read before start
+
+Getting started with ZIGGO-CaaS-Switch/ZIGGO-Device is a ***pretty hard*** task. Users/developers need to have sufficient basic knowledge and be prepare to for a long periond of learning and debugging.
+
+Please refer to [basic_knowledge.md](/ZIGGO_WEB/device/basic_knowledge/) to check if you have ability to use ZIGGO competently.
+
+## Getting Started
+
+Please refer to [required.md](/ZIGGO_WEB/device/require/) to get prepared.
+
+After that, please refer to [getting_started.md](/ZIGGO_WEB/device/getting-started/) for the build and run a single ZIGGO Device.
+
+## System Design
+
+ZIGGO is implemented on ZYNQ-7000 SoC and exploits ZYNQ's both hardware and software programmability.
+
+
+
+We also provide more in-depth [documentation](/ZIGGO_WEB/device/system-design/) explaining specific design principles for ZIGGO Device.
+
+## Demo APP Tutorial
+
+We also provide a [testbed build document](/ZIGGO_WEB/device/testbed/) that allows you to build a real-time Ethernet system using the ZIGGO swtich and Device.
+
+Through this platform, we can measure the `delay` and `jitter` of TSN time-critcial traffic, the switch's `gating capability`, `bandwidth guarantee` and `gating accuracy`.
+
+Replacing ZIGGO CaaS switches with commercial TSN switches can also test its above capabilities.
+
+## License and Citation
+
+ZIGGO is released under a [MIT license](https://github.com/MobiSense/Ziggo-Device/blob/main/LICENSE.txt).
+
+Please consider citing our papers if the project helps your research with the following BibTex:
+
+```bibtex
+@inproceedings{caas,
+ author={Yang, Zheng and Zhao, Yi and Dang, Fan and He, Xiaowu and Wu, Jiahang and Cao, Hao and Wang, Zeyu and Liu, Yunhao},
+ booktitle={IEEE INFOCOM 2023 - IEEE Conference on Computer Communications},
+ title={CaaS: Enabling Control-as-a-Service for Time-Sensitive Networking},
+ year={2023},
+ pages={1-10},
+ doi={10.1109/INFOCOM53939.2023.10228980}}
+```
+
+```bibtex
+@inproceedings{etsn,
+ author={Zhao, Yi and Yang, Zheng and He, Xiaowu and Wu, Jiahang and Cao, Hao and Dong, Liang and Dang, Fan and Liu, Yunhao},
+ booktitle={IEEE ICDCS 2022 - IEEE International Conference on Distributed Computing Systems},
+ title={E-TSN: Enabling Event-triggered Critical Traffic in Time-Sensitive Networking for Industrial Applications},
+ year={2022},
+ volume={},
+ number={},
+ pages={691-701},
+ doi={10.1109/ICDCS54860.2022.00072}}
+```
+
+## TODO List
+
+- [x] ZIGGO CaaS Switch Release
+- [x] ZIGGO Device Release
+- [x] ZIGGO Device Source Code
+- [x] Tutorial for build a testbed
+- [ ] Test Case for TSN
+
+> We will expand each test in the tutorial to multiple test cases to cover different edge cases and comprehensively test the performance of TSN switches.
+
+- [ ] Support Device List
+
+> At present, we have only tested our own Ziggo switches and are testing other commercial switches (such as Huawei ,H3C and NXP). We expect to maintain a list of test results in the future.
+
+## Contributing
+
+Please see the [guide](/ZIGGO_WEB/device/contributing/) for information on how to ask for help or contribute to the development of ZIGGO!
+
+> The development team will only answer questions on github issues and reject other forms of questions.
\ No newline at end of file
diff --git a/content/device/figs/Alinx7021.png b/content/device/figs/Alinx7021.png
new file mode 100644
index 0000000..8156f7b
Binary files /dev/null and b/content/device/figs/Alinx7021.png differ
diff --git a/content/device/figs/FPGA_boot_mode_switch.png b/content/device/figs/FPGA_boot_mode_switch.png
new file mode 100644
index 0000000..2f74d61
Binary files /dev/null and b/content/device/figs/FPGA_boot_mode_switch.png differ
diff --git a/content/device/figs/analyse_result.png b/content/device/figs/analyse_result.png
new file mode 100644
index 0000000..80efff1
Binary files /dev/null and b/content/device/figs/analyse_result.png differ
diff --git a/content/device/figs/banner.jpg b/content/device/figs/banner.jpg
new file mode 100644
index 0000000..c94260d
Binary files /dev/null and b/content/device/figs/banner.jpg differ
diff --git a/content/device/figs/demo-app.png b/content/device/figs/demo-app.png
new file mode 100644
index 0000000..046fb88
Binary files /dev/null and b/content/device/figs/demo-app.png differ
diff --git a/content/device/figs/device_arch.png b/content/device/figs/device_arch.png
new file mode 100644
index 0000000..730bb7b
Binary files /dev/null and b/content/device/figs/device_arch.png differ
diff --git a/content/device/figs/device_test_demo.png b/content/device/figs/device_test_demo.png
new file mode 100644
index 0000000..33f1164
Binary files /dev/null and b/content/device/figs/device_test_demo.png differ
diff --git a/content/device/figs/download_petalinux.PNG b/content/device/figs/download_petalinux.PNG
new file mode 100644
index 0000000..4131d41
Binary files /dev/null and b/content/device/figs/download_petalinux.PNG differ
diff --git a/content/device/figs/example_pkt_gen_period.png b/content/device/figs/example_pkt_gen_period.png
new file mode 100644
index 0000000..a157918
Binary files /dev/null and b/content/device/figs/example_pkt_gen_period.png differ
diff --git a/content/switch/software_build/example_topology.png b/content/device/figs/example_topology.png
similarity index 100%
rename from content/switch/software_build/example_topology.png
rename to content/device/figs/example_topology.png
diff --git a/content/device/figs/export_bitstream.png b/content/device/figs/export_bitstream.png
new file mode 100644
index 0000000..9c7c556
Binary files /dev/null and b/content/device/figs/export_bitstream.png differ
diff --git a/content/device/figs/framework.jpg b/content/device/figs/framework.jpg
new file mode 100644
index 0000000..5986d4e
Binary files /dev/null and b/content/device/figs/framework.jpg differ
diff --git a/content/device/figs/moba_serial.png b/content/device/figs/moba_serial.png
new file mode 100644
index 0000000..4dbb934
Binary files /dev/null and b/content/device/figs/moba_serial.png differ
diff --git a/content/device/figs/offline_analyse.png b/content/device/figs/offline_analyse.png
new file mode 100644
index 0000000..19b38f7
Binary files /dev/null and b/content/device/figs/offline_analyse.png differ
diff --git a/content/device/figs/online_analyse.png b/content/device/figs/online_analyse.png
new file mode 100644
index 0000000..85c91e4
Binary files /dev/null and b/content/device/figs/online_analyse.png differ
diff --git a/content/switch/system_design/switch_fabric.png b/content/device/figs/switch_fabric.png
similarity index 100%
rename from content/switch/system_design/switch_fabric.png
rename to content/device/figs/switch_fabric.png
diff --git a/content/device/figs/testbed.jpg b/content/device/figs/testbed.jpg
new file mode 100644
index 0000000..78bb234
Binary files /dev/null and b/content/device/figs/testbed.jpg differ
diff --git a/content/switch/system_design/time_sync_state_machine.png b/content/device/figs/time_sync_state_machine.png
similarity index 100%
rename from content/switch/system_design/time_sync_state_machine.png
rename to content/device/figs/time_sync_state_machine.png
diff --git a/content/device/figs/topo.PNG b/content/device/figs/topo.PNG
new file mode 100644
index 0000000..404865e
Binary files /dev/null and b/content/device/figs/topo.PNG differ
diff --git a/content/device/figs/topo_config.png b/content/device/figs/topo_config.png
new file mode 100644
index 0000000..0f4dc56
Binary files /dev/null and b/content/device/figs/topo_config.png differ
diff --git a/content/device/figs/vivado_bitstream.png b/content/device/figs/vivado_bitstream.png
new file mode 100644
index 0000000..a05b890
Binary files /dev/null and b/content/device/figs/vivado_bitstream.png differ
diff --git a/content/device/figs/vivado_tcl_console.png b/content/device/figs/vivado_tcl_console.png
new file mode 100644
index 0000000..e8ed104
Binary files /dev/null and b/content/device/figs/vivado_tcl_console.png differ
diff --git a/content/device/figs/vivado_workdir.png b/content/device/figs/vivado_workdir.png
new file mode 100644
index 0000000..48167c1
Binary files /dev/null and b/content/device/figs/vivado_workdir.png differ
diff --git a/content/switch/system_design/zynq.png b/content/device/figs/zynq.png
similarity index 100%
rename from content/switch/system_design/zynq.png
rename to content/device/figs/zynq.png
diff --git a/content/switch/_index.md b/content/switch/_index.md
index 399a7a8..7c64a15 100644
--- a/content/switch/_index.md
+++ b/content/switch/_index.md
@@ -1,3 +1,152 @@
----
+
+
+
+# ZIGGO CaaS Switch: A flexible, standard-compliant, and control-function-virtualized TSN switch platform
+
+
ZIGGO is a flexible, standard-compliant, and control-function-virtualized TSN switch platform ready for industrial control, automotive electronics, and other time-sensitive applications.
+
This is the document for the ZIGGO Device. (We also offer ZIGGO-CaaS-Switch that comply with the IEEE 802.1 TSN standard.) Our Device supports testing all standards-compliant switches.
+
ZIGGO Open Platform
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The construction of the ZIGGO Open Platform consists of three levels: network device, management tools, and a Demo App:
+
+
+
The software and hardware projects, along with the development board startup tutorial, provide instructions for setting up an individual network device.
Lastly, we offer a comprehensive Demo App building tutorial that instructs how to
+collaboratively build a complete and functional Demo using network devices and
+management tools.
+
+
+
Demo
+
We provide a demonstration video of the TSN switch. It demonstrates the superior performance of the ZIGGO-CaaS-Switch compared to the normal switch.
+
The left side of the picture is the ZYNQ development board we use, and the right side is the TSN display board we built.
Click the pic to watch the video! Or just click here.
+
+
Features
+
+
+
ZIGGO supports the simultaneous transmission of both Information Technology (IT) and Operation Technology (OT) data traffic with QoS guarantee.
+
+
+
ZIGGO complies with IEEE standards 802.1AS, Qav, Qbv, and Qcc.
+
+
+
ZIGGO provides Real-time and Deterministic Ethernet transport
+
+
ZIGGO achieve Zero Packet Loss , Microsecond-level Latency with Nanosecond-level Jitter Gate Ability.
+
ZIGGO guarantee Gigabit Throughput.
+
ZIGGO provide gate accuracy applicable to All Ethernet Frame Sizes.
+
+
+
+
Read before start
+
Getting started with ZIGGO-CaaS-Switch/ZIGGO-Device is a pretty hard task. Users/developers need to have sufficient basic knowledge and be prepare to for a long periond of learning and debugging.
+
Please refer to basic_knowledge.md to check if you have ability to use ZIGGO competently.
After that, please refer to getting_started.md for the build and run a single ZIGGO Device.
+
System Design
+
ZIGGO is implemented on ZYNQ-7000 SoC and exploits ZYNQ’s both hardware and software programmability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
We also provide more in-depth documentation explaining specific design principles for ZIGGO Device.
+
Demo APP Tutorial
+
We also provide a testbed build document that allows you to build a real-time Ethernet system using the ZIGGO swtich and Device.
+
Through this platform, we can measure the delay and jitter of TSN time-critcial traffic, the switch’s gating capability, bandwidth guarantee and gating accuracy.
+
Replacing ZIGGO CaaS switches with commercial TSN switches can also test its above capabilities.
Please consider citing our papers if the project helps your research with the following BibTex:
+
@inproceedings{caas,
+author={Yang, Zheng and Zhao, Yi and Dang, Fan and He, Xiaowu and Wu, Jiahang and Cao, Hao and Wang, Zeyu and Liu, Yunhao},
+booktitle={IEEE INFOCOM 2023 - IEEE Conference on Computer Communications},
+title={CaaS: Enabling Control-as-a-Service for Time-Sensitive Networking},
+year={2023},
+pages={1-10},
+doi={10.1109/INFOCOM53939.2023.10228980}}
+
@inproceedings{etsn,
+author={Zhao, Yi and Yang, Zheng and He, Xiaowu and Wu, Jiahang and Cao, Hao and Dong, Liang and Dang, Fan and Liu, Yunhao},
+booktitle={IEEE ICDCS 2022 - IEEE International Conference on Distributed Computing Systems},
+title={E-TSN: Enabling Event-triggered Critical Traffic in Time-Sensitive Networking for Industrial Applications},
+year={2022},
+volume={},
+number={},
+pages={691-701},
+doi={10.1109/ICDCS54860.2022.00072}}
+
TODO List
+
+
ZIGGO CaaS Switch Release
+
ZIGGO Device Release
+
ZIGGO Device Source Code
+
Tutorial for build a testbed
+
Test Case for TSN
+
+
+
We will expand each test in the tutorial to multiple test cases to cover different edge cases and comprehensively test the performance of TSN switches.
+
+
+
Support Device List
+
+
+
At present, we have only tested our own Ziggo switches and are testing other commercial switches (such as Huawei ,H3C and NXP). We expect to maintain a list of test results in the future.
+
+
Contributing
+
Please see the guide for information on how to ask for help or contribute to the development of ZIGGO!
+
+
The development team will only answer questions on github issues and reject other forms of questions.
ZIGGO is a flexible, standard-compliant, and control-function-virtualized TSN switch platform ready for industrial control, automotive electronics, and other time-sensitive applications.
+
This is the document for the ZIGGO CaaS Switch. (We also offer ZIGGO-Device that comply with the IEEE 802.1 TSN standard.)
+
ZIGGO Open Platform
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
The construction of the ZIGGO Open Platform consists of three levels: network device, management tools, and a Demo App. More details in ZIGGO-Device.
+
Demo
+
We provide a demonstration video of the TSN switch. It demonstrates the superior performance of the ZIGGO-CaaS-Switch compared to the normal switch.
+
The left side of the picture is the ZYNQ development board we use, and the right side is the TSN display board we built.
Click the pic to watch the video! Or just click here.
+
+
Features
+
+
+
ZIGGO supports the simultaneous transmission of both Information Technology (IT) and Operation Technology (OT) data traffic with QoS guarantee.
+
+
+
ZIGGO complies with IEEE standards 802.1AS, Qav, Qbv, and Qcc.
+
+
+
ZIGGO provides Real-time and Deterministic Ethernet transport
+
+
+
ZIGGO achieve Zero Packet Loss , Microsecond-level Latency with Nanosecond-level Jitter Gate Ability.
+
+
+
ZIGGO guarantee Gigabit Throughput.
+
+
+
ZIGGO provide gate accuracy applicable to All Ethernet Frame Sizes.
+
+
+
+
+
Read before start
+
Getting started with ZIGGO-CaaS-Switch/ZIGGO-Device is a pretty hard task. Users/developers need to have sufficient basic knowledge and be prepare to for a long periond of learning and debugging.
+
Please refer to basic_knowledge.md to check if you have ability to use ZIGGO competently.
Please refer to hardware-build.md for the build hardware for ZIGGO Evaluation Toolkit and software-build.md to run time synchronization logic and set up TSN GCL .
+
System Design
+
ZIGGO is implemented on ZYNQ-7000 SoC and exploits ZYNQ’s both hardware and software programmability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
We also provide more in-depth documentation explaining specific design principles for ZIGGO CaaS Switch.
+
Demo APP Tutorial
+
We also provide a testbed build document(in ZIGGO Device) that allows you to build a real-time Ethernet system using the ZIGGO swtich and ZIGGO Device.
+
Through this platform, we can measure the delay and jitter of TSN time-critcial traffic, the switch’s gating capability, bandwidth guarantee and gating accuracy.
+
Replacing ZIGGO CaaS switches with commercial TSN switches can also test its above capabilities.
Please consider citing our papers if the project helps your research with the following BibTex:
+
@inproceedings{caas,
+author={Yang, Zheng and Zhao, Yi and Dang, Fan and He, Xiaowu and Wu, Jiahang and Cao, Hao and Wang, Zeyu and Liu, Yunhao},
+booktitle={IEEE INFOCOM 2023 - IEEE Conference on Computer Communications},
+title={CaaS: Enabling Control-as-a-Service for Time-Sensitive Networking},
+year={2023},
+pages={1-10},
+doi={10.1109/INFOCOM53939.2023.10228980}
+}
+
@inproceedings{etsn,
+author={Zhao, Yi and Yang, Zheng and He, Xiaowu and Wu, Jiahang and Cao, Hao and Dong, Liang and Dang, Fan and Liu, Yunhao},
+booktitle={IEEE ICDCS 2022 - IEEE International Conference on Distributed Computing Systems},
+title={E-TSN: Enabling Event-triggered Critical Traffic in Time-Sensitive Networking for Industrial Applications},
+year={2022},
+volume={},
+number={},
+pages={691-701},
+doi={10.1109/ICDCS54860.2022.00072}}
+
TODO List
+
+
+
ZIGGO CaaS Switch Release
+
+
+
ZIGGO Evaluation Toolkit Release
+
+
+
ZIGGO Evaluation Toolkit Source Code
+
+
+
Tutorial for build a testbed
+
+
+
Test Case for TSN
+
+
+
+
We will expand each test in the tutorial to multiple test cases to cover different edge cases and comprehensively test the performance of TSN switches.
+
+
+
Support Device List
+
+
+
At present, we have only tested our own Ziggo switches and are testing other commercial switches (such as Huawei ,H3C and NXP). We expect to maintain a list of test results in the future.
+
+
Contributing
+
Please see the guide for information on how to ask for help or contribute to the development of ZIGGO!
+
+
The development team will only answer questions on github issues and reject other forms of questions.
This repo contains source code to enable CaaS Switches’ time synchronization logic and set up TSN GCL (gate control list), switch forwarding rules (including to dual-DMA).
+
Build
+
mkdir build
+cd build
+cmake ..
+make
+
After successfully build, there should be two executables: “time_sync_app” & “switch_config”
+
Config
+
The “config” directory contains topology & TSN/CaaS schedule results.
+
This document takes the following topology as an example to give example configurations:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
***-config.json: Mainly describes the network’s topology, including the type of each node (device or switch), MAC address, PTP port status, and other node information, topology information, and MAC forwarding table. Example and explanation are as follows (note that the comments in the file are just for explanation, do not have such comments in actual use):
+
{
+"nodes":[// Used to describe the information of each node in the network
+{
+"id":10,// Node ID, corresponding to "src" and "dst" below
+"type":"switch",// Node type, divided into "switch" and "device"
+"mac":"00:0a:35:00:00:10",// Node's physical MAC address
+"ptp_ports":[
+1,
+0,
+3,
+0,
+3
+]// Node's PTP port status
+// The quintuple represents the clock status of [local, ETH1, ETH2, ETH3, ETH4]
+// Number meaning: (0: MASTER, 1: SLAVE, 2: PASSIVE, 3: DISABLED)
+// If local is 1, it means that the node is the master clock node;
+// If local is 0, it means that the node is the slave clock node.
+},
+{
+"id":14,
+"type":"device",
+"mac":"00:0a:35:00:00:14"
+},
+{
+"id":15,
+"type":"device",
+"mac":"00:0a:35:00:00:15"
+}
+],
+"links":[// Topology information, composed of each link, each link is a directed edge
+{
+"id":0,// link ID
+"src":14,// Source node ID of the link
+"src_port":0,// Port number of the source node
+// port 0,1,2,3 correspond to ETH1,2,3,4 in reality
+"dst":10,// Destination node ID of the link
+"dst_port":0// Port number of the destination node
+},
+{
+"id":1,
+"src":10,
+"src_port":0,
+"dst":14,
+"dst_port":0
+},
+{
+"id":2,
+"src":10,
+"src_port":2,
+"dst":15,
+"dst_port":0
+},
+{
+"id":3,
+"src":15,
+"src_port":0,
+"dst":10,
+"dst_port":2
+}
+],
+"fwd":[// Forwarding table, which can be generated by the scheduling algorithm in CNC
+// In the forwarding table where you send to yourself, the port is 4 (caas) / 5 (PS ETH for new hardware)
+{
+"src":10,// Current node ID
+"dst":14,// Output port number
+"id":0,// Entry ID
+"src_port":0// Destination node ID
+},
+{
+"src":14,
+"dst":10,
+"id":1,
+"src_port":0
+},
+{
+"src":10,
+"dst":15,
+"id":2,
+"src_port":2
+},
+{
+"src":15,
+"dst":10,
+"id":3,
+"src_port":0
+}
+]
+}
+
If the master clock selection algorithm is used, only the configuration of nodes is different, and the rest are the same. The newly added externalPortConfigurationEnabled and system_identity fields are optional items, as shown in the example below:
+
{
+"nodes":[
+{
+"type":"switch",
+"id":0,
+"mac":"00:00:00:00:02:01",
+"ptp_ports":[0,0,0,0,0],
+"externalPortConfigurationEnabled":1,// 1: Manually configure the master-slave relationship, 0: Configure the master-slave relationship through the master clock selection algorithm, if this item is not written, the default is 0, that is, configure the master-slave relationship through the master clock selection
+"system_identity":{// Clock node's clock parameters, used for comparison in the master clock selection algorithm, if this item is not written, the default is the configuration written below
+"priority1":254,// First priority
+"clockClass":248,// Clock level
+"clockAccuracy":254,// Clock accuracy
+"offsetScaledLogVariance":17258,// Clock variance
+"priority2":247,// Second priority
+"clock_identity":[0,0,0,0,0,0,0,0]// Clock identifier, different clocks should have different parameters
+}
+}
+],
+"links":[
+],
+"fwd":[
+]
+}
+
+
+
***-schedule.json: schedule file, contains each links’ schedule time interval & each CaaS switch’s computation time interval.
+
[
+{// All switches need to be listed to facilitate software recognition of configuration information
+"type":"switch",// Node type, divided into "switch" and "device"
+"id":10,// Node ID, corresponding to "src" and "dst" below
+"mac":"00:0a:35:00:00:10",// Node's physical MAC address
+"schedule":[
+]// Can be empty, not used
+},
+{
+"type":"link",// Type is link, used to describe scheduling information
+"from":14,// Source node ID of the link
+"to":10,// Destination node ID of the link
+"from_port":0,// Output port number
+"id":3,
+"schedule":[// Scheduling information
+{
+"period":2048,// Scheduling cycle
+"start":0,// Start time relative to the entire cycle
+"end":5,// End time relative to the entire cycle
+"job_id":0,// Job ID in CaaS, if not needed, it can be omitted
+"flow_id":0// Data stream ID
+
+}
+]
+},
+{
+"type":"link",
+"from":10,
+"to":15,
+"from_port":2,
+"id":0,
+"schedule":[
+{
+"period":2048,
+"start":1,
+"end":6,
+"job_id":0,
+"flow_id":0,
+"pkt_size":1500// Packet length, if not written, the default is 1500B, this item only exists on the path from Device to Switch
+}
+]
+}
+]
+
Start time synchronization and initialize GCL and MAC forwarding table according to the configuration (it is recommended to run the time synchronization program on a core (with taskset -c 1 command) to prevent kernel errors and crashes due to time synchronization):
+
+
taskset -c 1 ./time_sync
+
+
The log output level is categorized into three types: WARN, INFO, and TRACE. The default log output level is TRACE (the most comprehensive output information, including DEBUG logs). The log output level can be set with the -l parameter:
+
+
taskset -c 1 ./time_sync -l w # WARN level
+taskset -c 1 ./time_sync -l i # INFO level
+taskset -c 1 ./time_sync -l t # TRACE level
+
Notice that the time sync logic is supposed to run indefinitely as the node should sync to its neighbors again and again.
The CaaS/TSN Switch is developed based on the ZYNQ platform. The diagram below shows the composition of the ZYNQ chip. ZYNQ mainly consists of a Processing System (PS) and Programmable Logic (PL). The PS and PL mainly communicate with each other through the high-performance Advanced eXtensible Interface (AXI), which is more efficient than using FPGA directly as a peripheral. The PS contains an ARM-based processor suitable for running applications, drivers, and operating systems, while the PL contains FPGA suitable for running low-level hardware logic with high real-time performance requirements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
For the Switch, the PL part mainly implements:
+
+
the real-time clock module and timestamp cache module in time synchronization;
+
the basic forwarding function and traffic control function of the switch.
+
+
The PS part mainly implements:
+
+
the state machine logic related to time synchronization;
The TSN switch complies with IEEE 802.1AS standards. It synchronize neighbor clocks in a decentralized manner and achieves clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. For each pair of connected devices, their time synchronization state machine will measure link delay and update their local RTC (real-time clock) according to Master clock.
+
The overall design of the time synchronization module is shown in the diagram below. The PS mainly consists of time synchronization state machine modules, which mainly run the state machine logic defined in the 802.1AS standard. The PL mainly consists of real-time clock modules and timestamp cache modules, which are mainly responsible for running the real-time clock and recording the time when data frames enter and exit the switch port.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
After the data frame enters the PL from the input port of the switch, the timestamp cache module will record and cache the timestamp when the data frame enters the hardware. The switch’s exchange module will determine whether the data frame is related to time synchronization. Time synchronization data frames will be forwarded from the PL to the PS for processing through the Direct Memory Access (DMA) channel. In the PS, the time synchronization state machine module needs to obtain the real-time clock information of the underlying PL and the hardware timestamps corresponding to different data frames through the AXI4-Lite interface. When the switch needs to send time synchronization-related data frames, the PS is responsible for encapsulating the sent data frames and then forwarding them to the PL for processing through the DMA channel. Since time synchronization also needs to record the sending time of messages such as Sync and Pdelay_Req, the timestamp cache module will still cache the sending timestamp before the data frame is sent from the output port, so that the PS can use it later.
+
Switch Fabric & Gate Control
+
The overall design of the switch fabric and gate control module is shown in the diagram below. The PS part mainly includes a configuration module, which is used for software-level configuration of the switch’s Gate Control List (GCL) and MAC forwarding table; the PL part mainly consists of the switch fabric and the gate control module, which are responsible for port forwarding and real-time control of traffic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
After the data frame enters the PL from the input port, both ordinary traffic and key traffic will enter the switch fabric. The switch fabric will look up the corresponding output port based on the destination MAC address in the data frame, and then put the data frame into the priority queue in the gate module. The gate control module will control the gate state of each priority queue according to the pre-configured GCL, and then forward the data frame from the corresponding port. In the above process, the gate control module needs to obtain the globally synchronized time from the time synchronization module. The configuration module in the PS part mainly modifies the registers related to GCL (tsn_drivers\gcl.c) and MAC forwarding table (tsn_drivers\switch_rules.c) through the UIO driver and AXI4-Lite interface, thereby controlling the parameters in the switch fabric and gate module in the PL part.
+
Source Code Description
+
Time Sync State Machine
+
The main function for time synchronization is located in time_sync_main_loop.c. It is implemented based on IEEE 802.1AS 2020 standard. The following table introduces the relationship between the state machine code in the code and the state machine in the standard.
+
+
+
+
Code Filename (.c/.h)
+
Corresponding Section in 802.1AS-2020
+
+
+
+
+
site_sync_sync_sm
+
10.2.7 SiteSyncSync
+
+
+
port_sync_sync_receive_sm
+
10.2.8 PortSyncSyncReceive
+
+
+
clock_master_sync_send_sm
+
10.2.9 ClockMasterSyncSend
+
+
+
clock_master_sync_receive_sm
+
10.2.11 ClockMasterSyncReceive
+
+
+
port_sync_sync_send_sm
+
10.2.12 PortSyncSyncSend
+
+
+
clock_slave_sync_sm
+
10.2.13 ClockSlaveSync
+
+
+
port_announce_information_sm
+
10.3.12 PortAnnounceInformation
+
+
+
port_state_selection_sm
+
10.3.13 PortStateSelection
+
+
+
port_announce_information_ext_sm
+
10.3.14 PortAnnounceInformationExt
+
+
+
port_announce_transmit_sm
+
10.3.16 PortAnnounceTransmit
+
+
+
md_sync_receive_sm
+
11.2.14 MDSyncReceiveSM
+
+
+
md_sync_send_sm
+
11.2.15 MDSyncSendSM
+
+
+
md_pdelay_req_sm
+
11.2.19 MDPdelayReq
+
+
+
md_pdelay_resp_sm
+
11.2.20 MDPdelayResp
+
+
+
+
UIO addresses
+
The UIO driver is mainly used to map logical addresses to physical addresses, thereby controlling the registers of modules such as TSU, RTC, GCL, etc. The driver code is located in the tsn_drivers folder. The correspondence between the register addresses in the software part and the hardware are described in the header files.
+
For example, in the tsn_drivers\rtc.h file, the address of the RTC module is defined as follows:
The MAC address forwarding table configured in the switch_rules.c/h file actually operates the registers in swtich datapath and gate control list. These registers are in pairs, the first register represents the network byte order of the last 32 bits of the destination MAC address, and the second register represents the forwarding port.
+
The CaaS switch has 7 ports, of which 4 are external physical ports, and 3 are virtual ports inside the switch connecting PL and PS. The 3 internal virtual ports specifically include:
+
+
Time Synchronization DMA: Used for transferring time synchronization data frames between PS and PL.
+
PS ETH: Used for communication between PL’s physical network port and PS’s operating system (for example, using an SSH client to remotely log in and access the switch’s PS).
+
PLC DMA: Used in CaaS to transfer input and output of control tasks.
+
+
The following interface is provided to control the switch fabric’s forwarding rule:
+
intpush_switch_rule(char*mac_addr,intoutput_port){
+/*
+ Push a switch rule to the rule table
+ mac_addr: 6 byte destination mac address.
+ output_port: 0 -> to Port 0
+ 1 -> to Port 1
+ 2 -> to Port 2
+ 3 -> to Port 3
+ 4 -> to PLC DMA
+ The switch rule for PTP frames are fixed in hardware, no need to specify explicitly.
+ */
+...
+}
+
Gate Control
+
TSN critical traffic data frames adopt the standard VLAN data frame format, and the priority is defined in the VLAN tag. VLAN refers to Virtual Local Area Network technology, defined in the 802.1Q standard. As shown in the figure below, the standard VLAN data frame contains a 4-byte VLAN tag, the TPID field represents the VLAN data frame type (0x8100), and the priority of critical traffic is defined in the PRI field, with a value range of [0, 7], corresponding to 8 priority queues. The output queue module identifies the priority of data frames based on the VLAN field in the critical data frame, and then places the data frame in the corresponding output port’s priority queue waiting for transmission.
+
Notice: According to the IEEE 802.1Qbv standard, priority = 1 maps to priority 0; priority = 0 maps to priority 1; other priorities map to the corresponding queues. Therefore, normal traffic will default to entering priority queue 1 of the corresponding port.
+
The CaaS Switch’s gate control module implements the Time Aware Shaper defined by 802.1Qbv, which is used to execute hardware gate scheduling according to the TSN schedule table configured by PS, to ensure the deterministic transmission of critical traffic.
+Our GCL is represented by 9 bits, with the highest bit representing whether the Guardband is enabled, and the remaining 8 bits representing the gate switches. For example, 9'1_0000_0001 means that the Guardband is enabled, and only the gate switch of the first queue is open.
+
Notice that the time unit of GCL in hardware is 2^11 ns, while the time unit in the configuration file issued is 2^14 ns.
+
The following interfaces in gcl.c/h are provided to get/set the hardware GCL (set the gate state and time interval seperately):
+
/**
+ * @description: This function is used to get gcl values of the port [portNumber].
+ * @param {uint16_t} portNumber port's number.
+ * @return {*} 0 by default.
+ */
+intget_gcl(uint16_tportNumber){
+...
+}
+
/**
+ * @description: This function is used to set GCL's value, set port [portNumber] 's GCL[gcl_id] to [value].
+ * @param {uint16_t} portNumber port number, start from 0.
+ * @param {uint16_t} gcl_id GCL index.
+ * @param {uint16_t} value the GCL value to set.
+ * @return {*} 0 by default.
+ */
+intset_gcl(uint16_tportNumber,uint16_tgcl_id,uint16_tvalue){
+...
+}
+
/**
+ * @description: This function is used to get all GCL time intervals of port [portNumber]. Consider we get time interval is x, the real time interval is (x * 2^8 * 8) nanoseconds.
+ * @param {uint16_t} portNumber port number, start from 0.
+ * @return {*} 0 by default.
+ */
+intget_gcl_time_interval(uint16_tportNumber)
+{
+...
+}
+
/**
+ * @description: This function is used to set GCL's time interval, set port [portNumber] 's GCL time interval[gcl_id] to [value].
+ * @param {uint16_t} portNumber port number, start from 0.
+ * @param {uint16_t} gcl_id GCL index.
+ * @param {uint16_t} value the GCL time interval x to set. The real time interval is (x * 2^8 * 8) nanoseconds.
+ * @return {*} 0 by default.
+ */
+intset_gcl_time_interval(uint16_tportNumber,uint16_tgcl_id,uint16_tvalue)
+{
+...
+}
+
+ 
+ 
+
+ 
+ 
+
+ 
+ 
+ 
