... | ... | @@ -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)>] |