Improve Language of Documentation

docs/controller/protocol.md

@@ -1,7 +1,7 @@
 # Protocol
 
-This page documents the data model/protocol used by VILLAScontroller to control and monitor infrastructure components (IC).
-The protocol uses AMQP to transport JSON encoded objects which are specified in the following document.
+This page documents the data model/protocol used by VILLAScontroller to control and monitor infrastructure components (ICs).
+The protocol uses AMQP to transport JSON-encoded objects, which are specified in the following document.
 
 VILLAScontroller is implemented in Python and using the [Kombo messaging package](https://kombu.readthedocs.io).
 
@@ -64,7 +64,7 @@ The exchange is named `villas`.
 
 The following headers are used to identify and route messages to the recipients:
 
-- `realm` describes the entity which is responsible for operating the equipment.
+- `realm` describes the entity that is responsible for operating the equipment.
   The realm should be a fully qualified domain name (FQDN) in reverse order.
   - Examples:
     - `de.rwth-aachen.eonerc.acs`

docs/controller/usage.md

@@ -1,9 +1,9 @@
 # Usage
 
-VILLAScontroller consist of two parts:
+VILLAScontroller consists of two parts:
 
- - A daemon which listens for control commands from an AMQP broker and controls the simulator.
- - A CLI tool for sending commands to the broker
+ - A daemon that listens for control commands from an AMQP broker and controls the simulator.
+ - A command-line tool for issuing commands to the broker.
 
 Both parts are accessible from the `villas-controller` command.
 
@@ -62,7 +62,7 @@ villas-controller --config config.json daemon
 villas-controller monitor
 ```
 
-**Note:** If you have `jq` installed, you might want to add `| jq .` to the end for pretty printing the JSON messages.
+**Note:** If you have `jq` installed, you might want to add `| jq .` to the end for pretty-printing the JSON messages.
 
 5. Discover / ping simulators:
 

docs/fpga/configuration.md

@@ -4,41 +4,41 @@
 This section is outdated!
 :::
 
-VILLASfpga is configured via the standard VILLASnode configuration file.
-Unlike the other node-types, the [VILLASfpga node-type](../node/nodes/fpga.md) requires settings in two places:
+VILLASfpga is configured using the standard VILLASnode configuration file.
+Unlike other node types, the [VILLASfpga node type](../node/nodes/fpga.md) requires settings in two places:
 
 - [Configuration of the FPGA](../node/nodes/fpga.md#config)
 - [Configuration of the VILLASnode / VILLASfpga interface](../node/nodes/fpga.md)
 
 ## FPGA Card {#card}
 
-This section is a group (like `nodes`) which allows the user to use multiple FPGA devices at the same time.
-Like nodes, each FPGA has it's own name:
+This section is a group (similar to `nodes`) that allows the user to use multiple FPGA devices simultaneously.
+Similar to nodes, each FPGA has its own name:
 
 ### id (string: "vendor:product") {#card-id}
 
-A string containing the vendor and product of the FPGA card as shown by `lscpi`.
+A string containing the vendor and product ID of the FPGA card, as shown by `lspci`.
 
 ### slot (string) {#card-slot}
 
-The slot in which the FPGA card is located as shown by `lspci`.
+The slot in which the FPGA card is located, as shown by `lspci`.
 
 ### intc (integer: base address) {#card-intc}
 
-The AXI4-Lite base address used to access registers of the interrupt controller.
+The AXI4-Lite base address used to access the interrupt controller's registers.
 
 ### reset (integer: base address) {#card-reset}
 
-The AXI4-Lite base address used to access registers of the reset controller.
+The AXI4-Lite base address used to access the reset controller's registers.
 
 ### do_reset (boolean) {#card-do_reset}
 
-Should VILLASnode perform a reset of the FPGA board when started?
+Should VILLASnode perform a reset of the FPGA board on startup?
 
 ### paths (array of groups) {#card-paths}
 
-A list of connections within the FPGA fabric which should be configured.
-This is analog to the [`paths` configuration section](../node/config/paths.md) of VILLASnode.
+A list of connections within the FPGA fabric that should be configured.
+This is analogous to the [`paths` configuration section](../node/config/paths.md) of VILLASnode.
 
 ### Example
 
@@ -65,8 +65,8 @@ fpgas = {
 
 ## FPGA IP core {#ip}
 
-Each FPGA IP core requires at least the following setting.
-Depending on the [VLNV](https://www.xilinx.com/support/answers/50478.html) of each IP core, additional settings can be configured.
+Each FPGA IP core requires at least the following setting:
+Depending on the [VLNV](https://www.xilinx.com/support/answers/50478.html) of each IP core, you can configure additional settings.
 
 ### vlnv (string: "vendor:library:name:version:) {#ip-vlnv}
 
@@ -78,7 +78,7 @@ The base address for register access.
 
 ### port (integer) {#ip-port}
 
-The port number of a switch to which this IP core is connected.
+The port number of the switch to which this IP core is connected.
 
 ### Example
 

docs/fpga/index.md

@@ -6,9 +6,9 @@ sidebar_label: Overview
 
 # VILLASfpga <img src="/img/logos/villas_fpga.svg" width="100" align="right" />
 
-VILLASfpga interconnects simulators and devices under test (DUT) for hardware-in-the loop simulation using hard real-time capable interfaces.
+VILLASfpga interconnects simulators and devices under test (DUT) for hardware-in-the-loop simulation using hard real-time-capable interfaces.
 VILLASfpga can guarantee fixed latencies in the nanosecond range.
-VILLASfpga is using Xilinx' FPGA evaluation boards to interfaces such devices to each other and to the Linux host system via PCIexpress.
+VILLASfpga uses Xilinx FPGA evaluation boards to interface such devices with each other and with the Linux host system via PCI Express.
 
 It implements intellectual property (IP) cores for connecting:
 
@@ -23,15 +23,15 @@ It implements intellectual property (IP) cores for connecting:
   - Simulink by using [Xilinx' System Generator](https://www.xilinx.com/products/design-tools/vivado/integration/sysgen.html).
   - C / C++ by using [Xilinx' High Level Synthesis](https://www.xilinx.com/products/design-tools/vivado/integration/esl-design.html).
 
-VILLASfpga can be configured to connect these interfaces in an arbitrary fashion without the need of generating a new bitstream. This is realized by using [a software configurable switch](https://www.xilinx.com/products/intellectual-property/axi4-stream_interconnect.html) in the FPGA fabric.
+VILLASfpga can be configured to connect these interfaces in an arbitrary fashion without the need to generate a new bitstream. This is realized by using a [software-configurable switch](https://www.xilinx.com/products/intellectual-property/axi4-stream_interconnect.html) in the FPGA fabric.
 
-VILLASfpga is based on ARM's [AXI-4 Stream](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0051a/index.html) interfaces and therefore relying on Xilinx's Vivado toolchain. This limits the the range of supported FPGA families to Virtex 6, 7 and the newer Ultrascale devices.  Bitstreams for the [Xilinx VC707 FPGA evaluation board](https://www.xilinx.com/products/boards-and-kits/ek-v7-vc707-g.html) are available upon request.
+VILLASfpga is based on ARM's [AXI-4 Stream](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0051a/index.html) interfaces and therefore relies on Xilinx's Vivado toolchain. This limits the range of supported FPGA families to Virtex 6, 7, and the newer Ultrascale devices. Bitstreams for the [Xilinx VC707 FPGA evaluation board](https://www.xilinx.com/products/boards-and-kits/ek-v7-vc707-g.html) are available upon request.
 
 ## Repositories
 
-The VILLASfpga project is splitted into two Git repositories:
+The VILLASfpga project is split into two Git repositories:
 - [VILLASfpga](https://github.com/VILLASframework/fpga) contains the C++ driver library and a few example applications
-- [VILLASfpga-hardware](https://github.com/VILLASframework/fpga-hardware) contains the Xilinx FPGA design based on the Vivado
+- [VILLASfpga-hardware](https://github.com/VILLASframework/fpga-hardware) contains the Xilinx FPGA design based on Vivado
 
 ## Building
 
@@ -59,7 +59,7 @@ Check that system is booted with IOMMU support:
 find /sys | grep dmar
 ```
 
-If not add `intel_iommu=on` to the kernel commandline and reboot.
+If not, add `intel_iommu=on` to the kernel command line and reboot.
 
 ```shell
 sudo modprobe vfio

docs/fpga/setup.md

@@ -7,20 +7,20 @@
 
 Identify the bus/device/function (BDF) identifier of the Xilinx Evaluation board:
 
-In the following example the BDF of the Xilinx evaluation board is `88:00.0 `:
+In the following example, the BDF of the Xilinx evaluation board is `88:00.0`:
 
 ```shell
 lspci | grep Xilinx
 88:00.0 Memory controller: Xilinx Corporation Device 7021
 ```
 
-Please remember the BDF as it is required for the VILLASfpga configuration later.
+Please remember the BDF, as it is required for the VILLASfpga configuration later.
 
 ## Kernel
 
 ### Version
 
-VILLASfpga requires a recent Linux kernel with version > 4.18.0
+VILLASfpga requires a recent Linux kernel with a version greater than 4.18.0.
 
 ```shell
 uname -a
@@ -30,7 +30,7 @@ uname -a
 
 VILLASfpga uses the VFIO subsystem to access the FPGA hardware.
 
-VFIO requires an IOMMU:
+VFIO requires an IOMMU.
 
 - [Enable IOMMU](https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Setting_up_IOMMU)
 
@@ -42,7 +42,7 @@ cat /proc/cmdline
 
 ### Modules
 
-VILLASfpga requires the following kernel modules to be loaded:
+VILLASfpga requires that the following kernel modules be loaded:
 
 - `vfio`
 - `vfio_pci`

docs/index.md

@@ -73,7 +73,7 @@ The source code of all open source components is available via [GitHub](https://
 
 ## Copyright
 
-2014-2024, Institute for Automation of Complex Power Systems, EONERC
+2014-2025, The VILLASframework Authors
 
 ## Licensing
 

docs/installation.md

@@ -41,7 +41,7 @@ minikube addons enable ingress
 
 ## Helm Chart
 
-To deloy the Helm chart you must first add the FEIN e.V. chart repository:
+To deploy the Helm chart you must first add the FEIN e.V. chart repository:
 
 ```shell
 helm repo add fein https://packages.fein-aachen.org/helm/charts/
@@ -64,12 +64,12 @@ web:
       mail: [email protected]
       username: admin
 
-      # please to change to a secure password
+      # please change to a secure password
       password: VillasTest1234
 
 ingress:
   port: 8080
-  host: villas.192-168-1-100.nip.io 
+  host: villas.192-168-1-100.nip.io
 
 broker:
   auth:

docs/node/clients/rtds_gtnet_skt.md

@@ -15,7 +15,7 @@ This raw format does not include any meta-data such as the timestamps or sequenc
 To work around this limitation, the `fake` option of the `raw` format can be set.
 This will cause the first three 3 signals to interpreted as sequence no, timestamp seconds and timestamp nanoseconds.
 A timestamp can be added by using the GTSYNC card with a GPS source in the draft file.
-Alternatively, if no timestamp is provided (value set to 0), VILLASnode will add a timestamp and thereby overriding replacing the 0 value.
+Alternatively, if no timestamp is provided (value set to 0), VILLASnode will add a timestamp, thereby replacing the 0 value.
 
 ## Common Problems
 

docs/node/clients/rtds_ml507_gtfpga.md

@@ -32,10 +32,10 @@ To generate the software binary "Xilinx SDK 12.4" **must** be used. Please make
 
 #### Generate SystemACE images for the CompactFlash card
 
-The Xilinx ML507 board supports to load it's initial configuration (hardware and software) from a Compact Flash memory card.
+The Xilinx ML507 board supports to load its initial configuration (hardware and software) from a Compact Flash memory card.
 This is an easy way to get the GTFPGA card running without using the Xilinx tools to program the FPGA.
 
-By default, the GTFPGA will load it's default configuration (IP address, port, rate) from above.
+By default, the GTFPGA will load its default configuration (IP address, port, rate) from above.
 
 #### Manually programming the GTFPGA by using a Xilinx Platform USB Cable
 

docs/node/development/contributing.md

@@ -29,7 +29,7 @@ PRs that update the style of existing code should be made separate from PRs that
     /* This is a short description of what this file does.
     *
     * More detailed description expanding on the previous one.
-    * This can also containt information about how to use the code,
+    * This can also contain information about how to use the code,
     * some design decisions or other information that is not
     * obvious from the code.
     *

docs/node/formats/villas_human.md

@@ -22,7 +22,7 @@ The columns are defined as follows:
      A valid timestamp can be generated by the following Unix command: `date +%s.%N`.
      *Important:* The second field is not the fractional part of the second!!!
 
- 2. Maximum `MSG_VALUES` floating point values per sample. The values are seperated by whitespaces as well.
+ 2. Maximum `MSG_VALUES` floating point values per sample. The values are separated by whitespaces as well.
 
 ## Implementation
 

docs/node/guides/lab13.md

@@ -67,5 +67,5 @@ paths = (
 
 <figure align="center">
     <img alt="RSCAD runtime of GTNET interface to VILLASnode." src="/img/screenshots/rscad/rscad_gtnet_skt_udp_loopback_rtt_runtime.png" width="100%" />
-    <figcaption>RSCAD runtime of GTNET interface to VILLASnode..</figcaption>
+    <figcaption>RSCAD runtime of GTNET interface to VILLASnode.</figcaption>
 </figure>

docs/node/guides/lab8.md

@@ -190,7 +190,7 @@ echo "123.456(1) 1.2 3.4 5.6" | villas hook ts
 
 <AsciinemaPlayer src="/recordings/terminal/villas_hook_ts.json" rows={25} cols={120} idleTimeLimit={3} preload={true} />
 
-There is another related hook function called `fix_ts` which will only overwrite the the timestamp if the source has not provided one (timestamp must is `0.0`).
+There is another related hook function called `fix_ts` which will only overwrite the timestamp if the source has not provided one (timestamp must be `0.0`).
 
 ```shell
 echo "0.0(1) 1.2 3.4 5.6" | villas hook fix_ts

docs/node/index.md

@@ -20,42 +20,42 @@ The project consists of a server daemon and several client modules which are doc
 ## Features
 
 - Wide selection of [interface types](nodes/index.md)
-- Statistic collection quality of service of the interfaces
+- Statistic collection for the quality of service of the interfaces
 - Web interface for live monitoring and control using WebSocket streams
 - [Remote API](development/api.md) for control via HTTP
-- Lua script-able hook functions
-- Network emulation using the Linux's [netem queuing discipline](https://wiki.linuxfoundation.org/networking/netem)
-- Multicast addressing for [Socket node-type](nodes/socket.md)
-- Deterministic and low jitter due to low level C/C++ implementation
-  - Using the latest C11/C++17 standards
-  - Easily extensible with new interface types, hook functions and payload formats
-- Released as open source software under the GPLv3 license
-- Easily deployable via [Precompiled standalone binaries](./installation.md#standalone), [Docker image](./installation.md#docker) or from [source](./installation.md#source)
-- Only relies on open source software libraries and the Linux kernel
-- Follows the Unix philosophy by providing a set of smaller command line tools
+- Lua-scriptable hook functions
+- Network emulation using the Linux [netem queuing discipline](https://wiki.linuxfoundation.org/networking/netem)
+- Multicast addressing for the [socket node type](nodes/socket.md)
+- Deterministic and low jitter due to a low-level C/C++ implementation
+  - Uses the latest C11/C++17 standards
+  - Is easily extensible with new interface types, hook functions, and payload formats
+- Is released as open-source software under the GPLv3 license
+- Is easily deployable via [precompiled standalone binaries](./installation.md#standalone), a [Docker image](./installation.md#docker), or from [source](./installation.md#source)
+- Relies only on open-source software libraries and the Linux kernel
+- Follows the Unix philosophy by providing a set of smaller command-line tools
 
 ## Daemon
 
 The server simply acts as a gateway to forward simulation data from one client to another.
-Furthermore, it collects statistics, monitors the quality of service and handles encryption or tunneling through VPNs.
+Furthermore, it collects statistics, monitors the quality of service, and handles encryption or tunneling through VPNs.
 
-For optimal performance the server is implemented in low-level C and makes use of several Linux-specific realtime features.
+For optimal performance, the server is implemented in low-level C and makes use of several Linux-specific real-time features.
 The primary design goal was to make the behavior of the system as deterministic as possible.
-Therefore, it's advisable to run the server component on a [PREEMPT_RT](https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch) patched version of Linux. In our environment, we use a Fedora-based distribution which has been stripped to the bare minimum (no GUI, only a few background processes).
+Therefore, it is advisable to run the server component on a [`PREEMPT_RT`](https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch)-patched version of Linux. In our environment, we use a Fedora-based distribution that has been stripped to the bare minimum (no GUI, only a few background processes).
 Have a look at [Tuning](tuning.md) for ways to improve the real-time performance of your system.
 
 ## Clients
 
 There are two types of interfaces to VILLASnode:
 
 1.  The server handles different types of nodes.
-    The most commonly used node-type is the [Socket node-type](nodes/socket.md) which allows communication over network links (UDP, raw IP, raw Ethernet frames).
-    But there are also other specialized node types to retrieve or send data to equipment, which is directly connected to or running on the server itself.
-    An example for such a node is the  [VILLASfpga node-type](nodes/fpga.md) which directly fetches and pushes data to a PCIe card.
-    Or the [File node-type](nodes/file.md) which logs or replays simulation data from the hard-disk.
+    The most commonly used node type is the [socket node type](nodes/socket.md), which allows communication over network links (UDP, raw IP, raw Ethernet frames).
+    However, there are also other specialized node types to retrieve or send data to equipment that is directly connected to or running on the server itself.
+    An example of such a node is the [VILLASfpga node type](nodes/fpga.md), which directly fetches and pushes data to a PCIe card.
+    Or the [file node type](nodes/file.md), which logs or replays simulation data from the hard disk.
 
-2. An other way to connect simulation equipment is by using a client-application which itself sends the data over the network to VILLASnode.
-    In this scenario, VILLASnode uses the [Socket node-type](nodes/socket.md) to communicate with the client-application.
+2. Another way to connect simulation equipment is by using a client application that sends the data over the network to VILLASnode.
+    In this scenario, VILLASnode uses the [socket node type](nodes/socket.md) to communicate with the client application.
 
-Usually, new clients / equipment should be implemented as a new node-type as part of VILLASnode.
-Using a dedicated client-application which communicates via the 'socket' type is deprecated because it leads to code duplication.
+Usually, new clients or equipment should be implemented as a new node type as part of VILLASnode.
+Using a dedicated client application that communicates via the 'socket' type is deprecated because it leads to code duplication.