Skip to content
GitLab

OpenLab_osci_FPGA_imp1 · Changes

Page history
added content to 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 @ b94e716a
......@@ -138,6 +138,159 @@ generating reply messages and prevents corrupted data during the power up phase.
values of the two dummy bytes are considered as don't care. This state is only reached
once during power up and cannot be reached during normal operation.
* IDLE
This state is reached after successfully transferring the dummy message. It is used to
initialize internal signals and variables to prepare the process for the next incoming command.
During this state no data is send by the transfer entity. The IDLE state listens
to the PACKET_AVAILABLE flag. If a valid packet was received by the Command Interpreter process, the IDLE state will change the state to CHECK_DATA. If no command
was received the IDLE state will switch to the REPLY_SD state in order to continue
any current sample data transfer. Therefore, the IDLE state will be left immediately after
execution. The IDLE state can also be reached by the WAIT_PC_REC state after
PACKET_AVAILABLE was set. REPLY_SD will switch to the IDLE state if no channel is
active and therefore data transmission is undesired. The IDLE state is also reached if any
of the following states successfully complete execution: REPLY_HWV, REPLY_SWV and
ACK.
* CHECK_DATA
After a new command was received, this state will change the next state depended on the
value of the command code. It detects if a non-supported command was received.
In this case, CHECK_DATA will change the error code to NOT_SUPPORTED and
switches to the NACK state in order to generate the error message. Currently the loop
back command of the OpenLab project is not supported by the FPGA based oscilloscope.
If the command code is not equal to any valid code, this state will set the error code to
UNKNOWN_COMMAND and changes the next state to NACK. CHECK_DATA is reached
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
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
to the REPLY_SD state. This will continue the transmission of sample data. This wait
procedure can be interrupted by any incoming command.
* WAIT_NACK_FIN
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
state machine will stay in this state as long as no new valid command was received by the
Command Interpreter.
* CMD_STS
This state gets activated by the CHECK_DATA state only. It will be reached after receiving
the SET TRIGGER SETTINGS command from the GUI. The state reads the payload data
of the received command and applies any changes to the trigger system. Settings like the
current active trigger channel, the trigger type and the trigger level are extracted from the
payload data. After completion the next state changes to the ACK state.
* CMD_SCS
After the command SET CHANNEL SETTINGS is received by the Command Interpreter,
the CHECK_DATA state of the state machine will switch to the CMD_SCS state. This state
extracts the payload data of the command and applies changes to the amplification-stage
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
the next state to ACK.
* CMD_STB
The state machine will switch to the CMD_STB state if the SET TIME BASE command
was received. The switching itself is done by the CHECK_DATA state. This state will
extract the sample rate settings from the payload data of the received command. The
value of the sample rate received from the GUI is already prepared to be used by the
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
state changes to the ACK state.
* CMD_SSM
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
the ACK state.
* REPLY_SD
This state is responsible for reading the sample data provided by the sampling-data-andtriggering
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].
{empty} +
This state is active if no command was received by the Command Interpreter. If all channels
are turned off, the REPLY_SD state will stop the transmission and switch to the IDLE
state. If a new command was received during the sample data packet transfer, the current
packet will be completed and transmitted. This is necessary to prevent any corrupted
data and possible de-synchronization of the GUI. However, the state machine will still
be informed about the new arrived command. Immediately after the current packet was
transferred, the transmission will stop and the pending command will be executed. If both
channels are activated, the REPLY_SD state will alternate between them. This is done to
provide a consistent amount of sample data of each channel for the GUI.
{empty} +
The whole sample data packet is stored in a std_logic_vector array. Each std_logic_vector
of this array is 1 byte in size. This storage can be used to generate every reply message
of the OpenLab protocol. The maximum size of one sample data packet is exactly 532
bytes. The header of the message reserves 7 bytes including the header checksum. The
payload of the sample data packet consists of a fixed and a variably field. The fixed payload
consists of the current packet number, the sample rate at which the samples were
taken, number of bits per sample and the number of samples in this packet. The fixed
payload field is 11 bytes in size. The variable field includes the sample data itself and the
payload checksum. The size of the variable payload depends on the amount of sample
data inside the packet. A maximum of 512 samples can be transferred within one message.
{empty} +
The size of one sample data packet can be calculated by the following formula:
{empty} +
image::https://es.technikum-wien.at/openlab/openlab_wiki/wikis/img/OpenLab_osci_FPGA_imp/osci_FPGA_imp_proto_formula.PNG[caption="Formula 1: ",title="Formula for calculating the total size of one sample data packet",align="center"]
{empty} +
* REPLY_HWV
This state creates the answer for the GET HARDWARE VERSION command. The state
is activated by the CHECK_DATA state. The generated message will include the actual
front-end hardware version of the OpenLab oscilloscope. This message is also used to
identify the device as a FPGA-based oscilloscope. This is necessary for calibrating some
functions of the GUI.
* REPLY_SWV
This state is similar to the REPLY_HWV state. The only difference is that the current
version number of the FPGA design is sent instead of the hardware version.
* ACK
The ACK state is reached every time a command of the OpenLab protocol needs confirmation.
For example, if parameters of the trigger settings or channel settings are changed.
After complete execution of this state, the next state will be the IDLE state.
* NACK
This state is reached if a received command cannot be further processed by the FPGA.
The NACK state will be activated if a header or payload CRC error occurred. This is
also the case if a not supported or unknown command was sent by the GUI. The NACK
message also includes an error code which helps to identify the cause of the problem.
== https://es.technikum-wien.at/openlab/openlab_wiki/wikis/home[Home] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/board_TIVAC[<Microcontroller-based TIVAC] | https://es.technikum-wien.at/openlab/openlab_wiki/wikis/sig_proc_osci_hardware[Signal Processing Front-End (XMC,TIVAC,DE0-Oscilloscope)>]