Skip to content
GitLab

OpenLab_osci_FPGA_imp1 · Changes

Page history
updated bib of OpenLab_osci_FPGA_imp1.asciidoc authored by Patrick Schmitt's avatar Patrick Schmitt
Hide whitespace changes
Inline Side-by-side
OpenLab_osci_FPGA_imp1.asciidoc
View page @ 602ef0c6
......@@ -11,10 +11,10 @@ The following sub-chapters will describe the functionality of the OpenLab commun
== OpenLab communication protocol
The interpreter is based on the communication protocol described in [21]. This protocol standardises the way of communication between a OpenLab device and the OpenLab GUI.
The interpreter is based on the communication protocol described in [1]. This protocol standardises the way of communication between a OpenLab device and the OpenLab GUI.
This ensures that the OpenLab GUI is able to connect to, and communicate with, any OpenLab device. Regardless if it is microcontroller-based, FPGA-based or soundcard-based.
The protocol was written from the OpenLab device perspective. This means that every command that is declared by the protocol is sent by the GUI.
On the other hand, every reply is sent from the OpenLab device. Two versions of the OpenLab communication protocol are described by [21].
On the other hand, every reply is sent from the OpenLab device. Two versions of the OpenLab communication protocol are described by [1].
{empty} +
......@@ -35,7 +35,7 @@ Table 1 shows the layout of the binary protocol, including the command- and repl
{empty} +
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_binarytable.PNG[caption="Figure 1: ",title="Binary-Mode command- and reply-structure, modified (21)",height=600,align="center"]
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_binarytable.PNG[caption="Table 1: ",title="Binary-Mode command- and reply-structure, modified (1)",height=600,align="center"]
{empty} +
......@@ -60,7 +60,7 @@ Every command sent by the GUI is analyzed by the corresponding process. Dependin
{empty} +
Figure 39 shows a diagram of the structure of this entity. Each process is dedicated to a specific function.
Figure 1 shows a diagram of the structure of this entity. Each process is dedicated to a specific function.
{empty} +
......@@ -85,11 +85,11 @@ After a command was successfully received by the Command Interpreter, the proces
{empty} +
Figure 40 illustrates the flow diagram of the Command Interpreter - process.
Figure 2 illustrates the flow diagram of the Command Interpreter - process.
{empty} +
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_cmd_flow.PNG[caption="Figure 1: ",title="Flow diagram of the command interpreter process as part of the FPGA design",align="center"]
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_cmd_flow.PNG[caption="Figure 2: ",title="Flow diagram of the command interpreter process as part of the FPGA design",align="center"]
{empty} +
......@@ -117,15 +117,15 @@ In order to inform the Command Execution State Machine, the Command Interpreter
This process is responsible for executing the command received from the GUI. The process continuously listens to the Command Interpreter to instantly execute a new available command.
If a new packet was received, the state machine will first check the command code.
According to the value of the command code, the next state will execute the command and generate the corresponding reply.
The structure of the state machine is described by the following diagram seen in figure 41.
The structure of the state machine is described by the following diagram seen in figure 3.
{empty} +
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_proto_SM.PNG[caption="Figure 1: ",title="Diagram of the command execution state machine",align="center"]
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_proto_SM.PNG[caption="Figure 3: ",title="Diagram of the command execution state machine",align="center"]
{empty} +
As shown in figure 41, the state machine itself can reach the following states:
As shown in figure 3, the state machine itself can reach the following states:
{empty} +
......@@ -171,7 +171,7 @@ every time a new command was received.
* WAIT_PC_REC
Every time a sample data packet was send by the FPGA, the actual state switches to
Every time a sample data packet was sent by the FPGA, the actual state switches to
the WAIT_PC_REC state. This state is used as a wait state. The state waits a defined
number of clock cycles in order to prevent the receiving buffer of the PC from overflowing.
After completing execution of the WAIT_PC_REC state, the current state switches back
......@@ -180,7 +180,7 @@ procedure can be interrupted by any incoming command.
{empty} +
* WAIT_NACK_FIN
* WAIT_NACK_FIN (deprecated)
This state is reached after a NACK message was sent by the FPGA. It resets some
internal signals and variables to prepare the state machine for any new command. The
......@@ -208,8 +208,7 @@ selection and the sample acquisition system.
CMD_SCS decides which channel is turned on or off depended on the payload data.
This state is also responsible for correctly setting the amplification-stage. This is done by
setting a bit pattern to the input of the de-multiplexer. This bit pattern is directly extracted
from the SET CHANNEL SETTINGS message. The amplification-stage selection process
is described in chapter 4.2.3 of this thesis. After execution, the CMD_SCS state will set
from the SET CHANNEL SETTINGS message. After execution, the CMD_SCS state will set
the next state to ACK.
{empty} +
......@@ -223,7 +222,7 @@ value of the sample rate received from the GUI is already prepared to be used by
sampling-data-and-triggering entity of the FPGA design.
This means that the value already represents the amount of clock cycles the FPGA has
to wait before storing a new sample. So complex mathematical operations are not necessary.
The sampling procedure will be discussed in chapter 5.4. After completion, the next
The sampling procedure will be discussed in chapter https://es.technikum-wien.at/openlab/openlab_wiki/wikis/OpenLab_osci_FPGA_imp3[Sampling data and triggering]. After completion, the next
state changes to the ACK state.
{empty} +
......@@ -233,20 +232,20 @@ state changes to the ACK state.
This state gets activated by the CHECK_DATA state if the SET SAMPLING MODE command
was received by the Command Interpreter process. The CMD_SSM state reads
data from the received payload and sets settings for the ETS sampling mode. A general
description of ETS can be found in chapter 6. The implementation of the ETS sampling
mode is described in chapter 7. Again, after completion, the next state will be changed to
description of ETS can be found in chapter https://es.technikum-wien.at/openlab/openlab_wiki/wikis/ETS_theory[Equivalent Time Sampling - Theory]. The implementation of the ETS sampling
mode is described in chapter https://es.technikum-wien.at/openlab/openlab_wiki/wikis/SETS_FPGA[Sequential Equivalent Time Sampling - FPGA Implementation]. Again, after completion, the next state will be changed to
the ACK state.
{empty} +
* REPLY_SD
This state is responsible for reading the sample data provided by the sampling-data-andtriggering
This state is responsible for reading the sample data provided by the sampling-data-and-triggering
entity of the FPGA design.
The REPLY_SD state prepares every sample data packet and starts their transmission.
Regardless of the selected sampling mode, the REPLY_SD state will handle the data collection.
This state prepares the Extended-Sample-Data packet as described by the binary
protocol in [21].
protocol in [1].
{empty} +
......@@ -326,7 +325,7 @@ OpenLab device and the OpenLab GUI is considered as non-critical.
{empty} +
The paper "A Tutorial on CRC Computations" [26] is concerned to CRC algorithm and how
The paper "A Tutorial on CRC Computations" [2] is concerned to CRC algorithm and how
they are structured. The CRC16 calculation consists of two processes. One process is responsible
for calculating the CRC of the header of a message. The other process calculates the
payload CRC.
......@@ -344,4 +343,11 @@ flag is set by the Command Execution State Machine.
{empty} +
== Bibliography
. Schloffer Harald: _Development of a low-cost micro-controller based oscilloscope including equivalent time sampling_, University of Applied Sciences FH Technikum Wien, 2016
. TEMLASO V. RAMABADRAN, S. S. G.: A Tutorial on CRC Computations. Iowa State University, 1988.
{empty} +
== https://es.technikum-wien.at/openlab/openlab_wiki/wikis/home[Home] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/OpenLab_osci_FPGA_imp[<OpenLab Oscilloscope FPGA IP-Core] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/OpenLab_osci_FPGA_imp2[Data communication between FPGA and PC>]