Remote Laboratory Based on FPGA Devices Using the e-Learning Approach

1. Introduction

The COVID-19 pandemic was caused by the coronavirus known as SARS-CoV-2, with the first human cases reported in Wuhan, China, in December 2019 [1]. In March 2020, the WHO declared the COVID-19 pandemic, urging countries to adopt urgent and aggressive measures [2]. This situation drastically changed all our daily activities (work, education, family, etc.), in which we were immersed, and we had to adapt to all these changes within a few days.

To prevent the spread and contagion of COVID-19, educational institutions worldwide began closing, affecting over 1.5 billion learners globally [3]. In Mexico, academic activities were specifically suspended on March 23, 2020 [4]. As a result, the entire in-person teaching-learning model had to be completely transformed into a distance learning model, in which both learners and teachers had to adapt in a very short time. In this context, digital technologies such as Learning Management Systems (LMS) [5], native cloud storage applications [6,7], platforms for videoconferencing and virtual meetings [8,9], social media [10,11], and mobile instant messaging applications [12,13] were employed. All these technologies served as a means for transmitting information and connecting and communicating people, primarily learners and teachers, achieving Technology-Mediated Learning [14].

One of the major challenges in engineering university programs was the development of remote practical sessions. The practical activities conducted in each undergraduate program are highly varied due to the diversity of courses offered. Each course utilizes different elements depending on the field to which it belongs.

Courses related to the area of Digital Logic Design (DLD) use FPGA for conducting practical sessions. An FPGA allows the synthesis of digital logic designs using a Hardware Description Language (HDL). Programming an FPGA requires the use of a development board that contains the FPGA and all the necessary peripherals for conducting lab exercises.

Since it was not possible to use these development boards in person, some alternatives emerged, such as using simulators in class and creating videos by teachers to demonstrate the operation of the lab exercises to learners. However, none of these options provides learners with an adequate solution for conducting practical activities, as they do not allow physical interaction with the development boards. Another option is to create a remote laboratory.

A remote laboratory is a technological environment that enables remote access, programming, manipulation, interaction, and visualization of physical equipment available in educational laboratories at any level. This technological environment is implemented using a computational system through an embedded system based on SoC technology.

The remote laboratory offers the entire infrastructure necessary for learners to test their lab exercises from a distance. This infrastructure includes servers for transferring files to the physical equipment, remote access, applications to interact with and manipulate the physical equipment, as well as the use of cameras to stream video that allows visualization of the lab exercise results, and of course, a network connection for Internet access. This infrastructure enables remote laboratories to create the technological environment known as the IoT [15,16,17].

With the remote laboratory, learners can interact with the development boards located in the in-person laboratory from anywhere (home, office, university), at any time, and from any device (laptop, desktop computer, mobile device). This allows them to gain meaningful teaching and learning experiences by conducting lab exercises for the DLD area, making remote laboratory an accessible, available and usable technological environment. This allows them to acquire what is known as ubiquitous learning [18,19], or u-learning. They only need a computing system (personal computer, laptop, tablet, mobile, etc.) with computer-aided design and electronic design automation (CAD-EDA) tools and an internet connection.

The remote laboratory presented consists of twelve development systems that are currently operational at School of Computing Science of the National Polytechnic Institute, Mexico. Learners in the DLD and Computer Architecture courses are conducting various lab exercises using the remote laboratory with the e-learning approach. This approach is defined as the transfer of knowledge and skills through intelligently designed educational materials with the help of electronic media such as the Internet, Web 4.0, intranets, and extranets [20]. This approach enhances the accessibility and availability of educational materials for people without age, time, or learner limits. The Learning Management System (LMS) is a platform used in the e-learning approach and, therefore, in the presented system [21].

The paper is organized as follows: Section 2 describes the literature review on in-person and remote laboratories. Section 3 introduces the research methodology. Section 4 describes the analysis and design stage of the research methodology. Section 5 describes the implementation stage of the research methodology. Section 6 describes the results of the remote laboratory. Section 7 provides the Discussion and the section 8 concludes the paper.

2. Literature Review

The development of laboratories has been carried out in in-person, virtual, or remote modalities. In the in-person modality, they have been oriented towards various areas such as Control [22] and Robotics [23].

In the remote modality, several works have also been conducted by different researchers in various fields. Jonathan Alvarez and Sergio Gonzalez in [24] propose a remote laboratory to learn programming and physical computing through Python and Raspberry Pi. Chevalier and other researchers in [25,26] propose a remote laboratory used in Control engineering studies. Aditionally, Krishnashree Achuthan and other researchers in [27] propose a remote laboratory that operates a Universal Testing Machine (UTM). The researchers use the Transactional Distance Theory (TDT) to compare physical laboratory platforms and remotely triggerable platforms. Also, Zhiyun Zhang and others researchers in [28] present a Software-Defined Radio remote lab, which permit learners to experiment with real wireless communication, designing Radio Frequency systems with minimal code adjustments.

Particularly in the area of DLD, various remote laboratories based on FPGAs have been reported. Navas-González and other researchers in [29] present examples of practices sessions to teach and learn digital electronics using an FPGA-based remote laboratory. The remote laboratory allows for design verification, but there is no video transmission to view the results. A server is implemented on a SoC, which communicates serially with a Nexys3 board. The board sends the status of the peripherals to the SoC to update their state on the user’s screen. To carry out this communication, a module called RLAB Plant must be implemented in the learners’ practices. Additionally, Naoki Fujieda and Atsuki Okuchi in [30] propose a remote FPGA laboratory platform using a PIC18F4450 microcontroller-based board that communicates with FPGA devices remotely via commands. This is intended to give learners the sensation of interacting with the hardware in a remote laboratory environment. Besides, Michal Melosik and other researchers in [31] propose a remote laboratory focused on FPGA devices for the remote design and testing of electronics circuits. The laboratory hardware consists of an application server on a personal computer and Open Broadcaster Software (OBS) environment for streaming. Two cameras are used, one to visualize the FPGA board and another to monitor instruments like an oscilloscope. Two tasks are performed: using a temperature and humidity sensor and designing a sine wave generator. Also, Han Wan and other researchers in [32] propose a remote laboratory with an FPGA for a Computer Organization course using a web system. The laboratory hardware uses one FPGA for the practices and another FPGA as a monitor. Both FPGAs belong to the Spartan 6 family from Xilinx. A personal computer handles the remote connection to a cloud server. There is a web interface where the practice results are displayed. The researchers report that 50.9% of learners completed Practice 8 in 2017 with the remote laboratory, compared to 21.3% of learners who completed the same practice in 2016 without the remote laboratory. On the other hand, Yuxiang Zhang and other researchers in [33] propose a remote FPGA experiment for experiments of Computer Systems curriculum. The laboratory hardware uses an Artix-7 FPGA for the practices and a Zynq-7 SoC from Xilinx as a controller to program the FPGA’s binary file through serial slave configuration. The researchers test the platform with the implementation of a 32-bit MIPS architecture processor capable of running a modified version of the Linux kernel.

Thang Manh Hoang and other researchers in [34] propose a remote laboratory for teaching FPGA and HDL. The laboratory hardware uses an Altera Cyclone II 2C20 FPGA for the practical exercises, which is controlled through a PIC16F877A microcontroller. Additionally, Toyoda and other researchers in [35] propose an FPGA-based remote laboratory implemented in a hybrid cloud for semi-automatic FPGA runs experiments. The laboratory consists of development systems from Altera. The user only needs to prepare their HDL code and FPGA configuration parameters, which are then sent to the laboratory. Finally, Aramburu and other researchers in [36] propose a cross-national remote laboratory based on FPGAs, implemented by the universities UPNA in Spain and UNIFESP in Brazil. The laboratory consists of 14 Altera development systems from both universities. They use a Raspberry Pi 3 B+ SoC to install the server and a Logitech webcam for video streaming.

Muhammad Alhammami in [37] outlines the development of a Hardware Development Kit (HDK) for a remote training platform based on FPGA. The HDK is equipped with a Raspberry Pi, a screen, a camera, LEDs, and the EP3C16Q240 FPGA chip from Altera. The raspberry Pi is to run a service as a loading or programming server for the FPGA. They present the design of a mechanical enclosure. To interact with the HDK, the VNC Viewer is used. Additionally, Rithea Sum and other researchers in [38] proposes a remote embedded system design approach utilizing Zynq 7000 FPGA, providing a web-based platform for learners to remotely test and debug their designs, with a focus on efficient signal acquisition and effective debugging and analysis. The methods used in the study include the implementation of a lab module with adaptive run-length-encoding data compression with an average compression ratio of 2.90 across three benchmark signals. Also, Carlos Cruz and others researchers in [39] proposes a remote laboratory using a a Nexys 4 FPGA Board. The designed remote setup allows learners to reserve laboratory time by creating customized environments for a wide range of experiments across different subjects. They use a remote computer, camera, sensors and motor for the development of experiments. There is one lab exercise reported. The study used a questionnaire with 17 questions to gather learners’ perceptions of the remote lab. The results were derived from the Electronic Design course with over 70% of learners preferring to combine real lab with remote lab. On the other hand, Guerrero-Osuna and others researchers in [40] presents a remote laboratory based on a Basys 3 FPGA Board, a Raspberry Pi 5, Google Firebase services and a web platform called UAZ Labs. They used a waterfall methodology integrating IoT and Cloud Computing technologies to facilitate close interaction between hardware and software. There are 3 lab exercises reported focuses on controlling DC, servo, and stepper motors. The testing phase involved 50 robotics and mechatronics engineering learners who participated in hands-on sessions for one month, followed by a structured survey evaluating their experience, interaction, and the educational relevance of the platform. Finally, Ballina and other researchers in [41] describe a remote laboratory with a cluster of an AMD Zynq UltraScale and a multiprocessor systems-on-chip (MPSoC) based on FPGA technology. The cluster is used for teach the concepts of data transfer and parallel processing across CPU and FPGA. The laboratory is used in a parrallel and heterogeneous computing course or in a the development of accelerators for ad-hoc computing course. The autors present 5 exercises for heterogeneous computing.

3. Research Methodology

In this paper, a quantitative research approach with an exploratory and explanatory scope is used. The research methodology is shown in Figure 1.

Figure 1 shows three different stages: Analysis and Design, Implementation, and Evaluation and Results. These stages are explained below:

4. Analysis and Design Stage of the Research Methodology

4.1. General Architecture

In this stage, the General Architecture of the remote laboratory for the DLD area is presented, using reconfigurable technology based on FPGA, a connectivist model based on Connectivism Learning Theory, and an embedded system based on IoT for implementation. Figure 2 shows the general architecture.

The general architecture consists of two important components, which are:

• On-site implementation of lab exercises.
• Use of remote laboratories based on IoT.

These components are described below:

4.2. On-Site Implementation of Lab Exercises

In this first component, the learner performs the analysis, design, implementation, simulation, constraints assignment, and BitStream file generation of the lab exercises to be developed using a CAD-EDA tool (ISE or Vivado by Xilinx) [42]. In this development environment, a project is created by selecting the FPGA of the Nexys 4 development board [43]. The sequence of actions for the on-site implementation of lab exercises is shown in Figure 3 and described below:

• Design procedure of the digital logic lab exercise: The Digital Design methodology is used to obtain the entity, the Algorithmic State Machine (ASM), the functional blocks, the datapath and the control unit for the lab exercise.
• Project creation with CAD-EDA tool: In the development environment, a project is created by selecting a target device, which can be either a Complex Programmable Logic Device (CPLD) or FPGA.
• Lab exercise programming with HDL: A program is written using an HDL, such as VHDL [44] or Verilog [45]. All functional blocks, the datapath, and the control unit of the design are programmed.
• Lab exercise simulation with HDL testbench: The HDL program is simulated to verify its correct operation according to the exercise specifications using a set of test vectors with a Test Bench file. For this, the ISE simulator integrated into the CAD-EDA tool is used.
• Pins assignment in constraint file: Pin assignment in the constraint file (.xdc) is performed using a virtual connector created within the technological architecture, which is called LAB REMOTE. This connector contains 24 virtual switches for assigning input pins. The output pin assignment is done through the peripherals on the development board.
• BitStream file generation: Finally, the syntheses, mapping, place and route and BitStream file (.bit) generation is performed.

4.3. Use of Remote Laboratories Based on IoT

In this second component, the learner accesses to the remote laboratory to interact, program, manipulate, visualize, and verify the results of the lab exercise on the FPGA using the Nexys 4 development board. The remote laboratory is implemented on an embedded system with SoC technology. The sequence of actions for using the remote laboratory is shown in Figure 4 and is described below:

• BitStream and constraints files transfer: To achieve this, an SSH server is used for file transfer from a terminal on any operating system (Windows, Linux, MacOS) executing the scp command. In addition, an SSH client for desktop or mobile devices can be used.
• Access to video server: A video web server allows visualization of the results from each lab exercise performed on the Nexsys 4 development board.
• SSH connection to remote laboratory: Remote access to the remote lab is achieved through the SSH server using the username and password provided by the instructor.
• FPGA programming with BitStream file (.bit): The BitStream file is programmed in the FPGA device using an application developed for the SoC.
• Lab exercise verification with constraints file: The lab exercise is verified through an application developed for the SoC.

5. Implementation Stage of the Research Methodology

In this stage the following modules are explained:

• Technological Architecture of the Remote Laboratory.
• Sequence of lab exercises for a DLD course.
• Connectivist Model based on Connectivism Learning Theory.

5.1. Technological Architecture of the Remote Laboratory

To implement the general architecture shown in Figure 2 a technological architecture for the development of the remote laboratory is proposed. Figure 5 shows the main components of the technological architecture.

Three important components shown in Figure 5 are explained below:

• V-Model methodology.
• Embedded System Based on IoT.
• SoC-FPGA Interface.

5.1.1. V-Model Methodology

For the analysis, design, and implementation of the remote laboratory using an embedded system, an adaptation of the V-Model Methodology proposed by Coop [46] was used for the development of SoC-based embedded systems. This methodology is shown in Figure 6.

Figure 6 shows the stages of the V-model methodology, from the specification of requirements to the operational testing of the system. This methodology allows returning to previous stages to make the necessary adjustments and ensure that the established requirements are met. In addition, the methodology supports the use of Unified Modeling Language (UML) in each stage [47], enabling a detailed description and a standardized design.

5.1.2. Embedded System Based on IoT

An embedded application was developed using SoC technology and a Linux-based operating system, specifically Raspberry Pi OS Lite (64-bit), which has an image size of 423 MB [48]. The SoC consists of a Raspberry Pi 3 Model B+, which has the following features [49]:

• 64-bit Cortex A53 Processor, with four cores, in Broadcom BCM2837B0 SoC.
• 1GB LPDDR2 SDRAM, Gigabit Ethernet over USB 2.0.
• 2.4GHz and 5GHz IEEE 802.11.b/g/n/ac wireless LAN, Bluetooth 4.2, BLE.
• Peripherals: SPI, I2C, UART, I2S, USB, GPIOs.

Although a Raspberry Pi 3 Model B+ SoC was used, it could be replaced by a Raspberry Pi 4 Model B or a Raspberry Pi 5. The SoC uses a Camera Module V2 for Raspberry Pi [50], based on Sony’s IMX219 8-megapixel sensor [51]. This camera communicates with the SoC via the MIPI CSI-2 protocol [52] for live video streaming.

Besides, two servers were configured on the embedded system, as described below:

• SSH server. This server uses the Secure Shell protocol for encrypted communication and is managed by the systemd initialization system.
• Video web server. This server is implemented using motion, which is used through a web application, so a browser is used for access. Motion is a configurable program that monitor video signals from many types of cameras and perform actions when movement is detected [53].

Additionally, two Linux shell applications were programmed and implemented on the embedded system to interact with the Nexys 4 FPGA development board, as described below:

• FPGA programming application. An application called progFPGA is used to program the FPGA device and relies on the drivers for the Advanced RISC Machine (ARM) architecture provided by Digilent Inc. These drivers are managed through the Join Test Action Group (JTAG) standard.
• Virtual switches application. An application called inputFPGA is used to verify the lab exercise and relies on the GPIOs of the SoC. This application allows the manipulation of up to 24 virtual switches which are labeled with the input port names defined in the user constraints file.

5.1.3. SoC-FPGA Interface

This manipulation interface is an electronic circuit that connects the SoC’s 40-pin connector to the Nexys 4 development board through the PMOD connectors. The block diagram of this interface is shown in Figure 7.

The functions provided by the SoC-FPGA Interface shown in Figure 7 are as follows:

• Create virtual switches. A connector referred to as "LAB REMOTE" is created, which supports the operation of up to 24 virtual switches. These virtual switches are shown in Table 1
• Configure a Real-Time Clock/Calendar (RTCC). The SoC lacks an integrated Real-Time Clock Calendar (RTCC) for system date and time configuration; instead, it relies on a Network Time Protocol (NTP) server to synchronize the system clock. When an RTCC is required, it must be implemented as an external peripheral to the SoC. The SoC–FPGA interface provides a connector compliant with the IIC bus specification [54], enabling the integration of external devices. Consequently, a custom electronic board was designed to incorporate an external RTCC, model DS1338, from Analog Devices [55] into the SoC.
• Configure a Crypto-Authentication device. These devices feature a cryptographic coprocessor that performs hardware-based encryption algorithms for IoT applications. A custom electronic board was designed for the connector compliant with the IIC bus specification of the SoC–FPGA interface to integrate an external Crypto-Authentication device, model ATECC608, from Microchip Inc [56].
• Provide an USB to serial UART interface. The SoC–FPGA interface provides a connector compliant with the UART interface. It enables the interconnection of external peripherals such as an USB to serial UART interface (FT232R) [57]. The FT232 device allows a console access to the SoC operating system and access to programming, configuration, updating, and maintenance tasks for the embedded system applications.

5.2. Sequence of Lab Exercises for a DLD Course

The remote laboratory has been used in the DLD courses since 2021 to date, with nine lab exercises covering the course content. The lab exercises are shown in Table 2.

Lab exercise 1 through 8 are explained in general terms, while lab exercise 9 is explained in detail as it encompasses the full thematic content of the course.

Lab exercise 1 involves integrating different combinational logic circuit elements such as the multiplexer, comparator, and code converter into an application that allows the use of various HDL structures, including concurrent, sequential and conditional. In this lab exercise, learners review and/or acquire the foundational knowledge needed for the course.

In lab exercise 2, learners design, implement and test an SR Flip-Flop (FF), JK-FF, T-FF and D-FF based on the equations obtained from their extended truth tables. The implementation is carried out using the D-FF and HDL on an FPGA. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on Latches and FF’s.

In lab exercise 3, learners design, implement and test a circuit that performs the functions of a register, including load, hold, shift-left, and shift-right operations. The implementation is carried out at different levels of abstraction using HDL on an FPGA. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on registers: architectures and applications.

In lab exercise 4, learners design, implement and test a 4-bit sequence detector without overlap using HDL on an FPGA. The sequence to detect is 1101 where the methodology for designing sequential circuits is applied. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on Deterministic Finite Automaton (DFA) with output called Mealy Machines.

In lab exercise 5, learners design, implement, and test a multiplexed message using HDL on an FPGA. The message has four symbols and is displayed on a module of four multiplexed common anode displays. Also, the methodology for designing sequential circuits is applied. The implementation is carried out in two ways: a static message without movement and a moving message in marquee mode. Through this lab exercise, learners apply and reinforce the theoretical knowledge acquired on DFA with output called Moore Machines.

In lab exercise 6, learners design, implement and test counters using HDL on an FPGA. They analyze an up-counter with Enable for obtaining a generic equation using a Moore Machine and applying the methodology for designing sequential circuits. Additionally, they implement counters using high-level operators + and −. Through this lab exercise, learners apply and reinforce the knowledge acquired on counters.

In lab exercise 7, learners design, implement and test BCD, ring and Johnson counters using HDL on an FPGA. They analyze these counters through their Mealy and Moore Machines and implement them using packages and components. Through this lab exercise, learners apply and reinforce the knowledge acquired on special counters.

In lab exercise 8, learners design, implement and test an application that determines whether a person enters or exits a room and counts the number of people in the room using two optical sensors and BCD counters. The application is implemented using a Mealy Machine analyzed with high-level HDL. Packages and components are used for the implementation. Through this lab exercise, learners apply and reinforce the knowledge acquired on Mealy Machines and special counters.

Practice 9 is described in detail below:

5.2.1. Algorithmic State Machine Lab Exercise

ASM are used to model dedicated cores through a flowchart that represents the state transitions and outputs generated by Mealy and Moore machines. The resulting digital logic design enables the execution of a specific algorithm in hardware.

In this lab exercise, a digital logic system is designed, implemented, and tested using HDL on an FPGA to determine the number of 1-bits in a 22-bit register through an ASM.

The design begins with the analysis of the algorithm to be implemented, which is shown below:

From Algorithm 1, the ASM is obtained, which contains the actions to execute the practice’s algorithm. The ASM is shown in Figure 8.

Algorithm 1 Pseudocode algorithm of the ASM lab exercise

countBitsInOne$\left(\mathbf{A}\right)$     $//\mathbf{A}=\mathbf{22}\mathbf{bits}\mathbf{number}$     $\mathbf{B}=\mathbf{0}$     $whileA\ne 0do$        $if{a}_0=1do$            $B=B+1$        $endif$            $A=Ashift\_right1$     $repeat$     return $\mathbf{B}$

From the ASM in Figure 8, the microarchitecture shown in Figure 9 is obtained. This microarchitecture is known as the datapath.

In this Microarchitecture, the Data Path of the design is shown, where the following functional blocks are presented:

• Register A. This register contains the 22-bit number to be analyzed.
• BCD Counters. They count the number of 1-bits contained in Register A. The algorithmic diagram of the BCD counters is shown in Figure 10.
• Ring Counter. Performs the multiplexing of the digits from the BCD counters on the 4 multiplexed common anode displays.
• ROM Memory. Performs the decoding of the 4 bits from the BCD counters to the 7 segments of the display. For a ROM memory with an organization of $m\times n$ bits, a data bus called $Data$ with n bits, and an address bus called $BCD$ with $lo{g}_2\left(m\right)$ bits, its equation is given by:

  $$Dat{a}_i=ROM{\left(BC{D}_j\right)}_i$$

  (1)
  Where:

  $$\begin{array}{cc}\hfill i& =0,1,...,n-1\hfill \end{array}$$

  (2)

  $$\begin{array}{cc}\hfill BC{D}_j& =0,1,...,m-1\hfill \end{array}$$

  (3)
• Control Unit Here is the automaton of the control unit obtained by replacing the actions of the ASM in Figure 8 with the control signals of each element of the Data Path shown in Figure 9. This automaton is shown in Figure 11.
  The automaton of the control unit is defined by the 9-tuple:

  $$M=(Q,\Sigma ,\Delta ,\delta ,\alpha ,\beta ,{\lambda }^1,{\lambda }^2,q_0)$$

  (4)
  Where:

  $$\begin{array}{cc}\hfill Q& =\left\{q_0,q_1,q_2\right\}\hfill \end{array}$$

  (5)

  $$\begin{array}{cc}\hfill \Sigma & =\left\{0,1\right\}\hfill \end{array}$$

  (6)

  $$\begin{array}{cc}\hfill \Delta & =\left\{0,1\right\}\hfill \end{array}$$

  (7)

  $$\begin{array}{cc}\hfill \alpha & =\left\{INI,Z,Q{A}_0\right\}\hfill \end{array}$$

  (8)

  $$\begin{array}{cc}\hfill \beta & =\left\{SHE,LA,IB,LB,SEL\right\}\hfill \end{array}$$

  (9)

  $$\begin{array}{cc}\hfill q_0& =Initialstate\hfill \end{array}$$

  (10)
  For each state $\left\{q,p\right\}\in Q$, each input symbol $a\in \Sigma$ and each input signal $s\in \alpha$, the transition function $\delta$ is defined as follows:

  $${\delta }_s(q,a)=p$$

  (11)
  For the automaton of the control unit in Figure 11, the transition function $\delta$ is defined as follows:

  $$\begin{array}{cccc}\hfill {\delta }_{INI}(q_0,0)& =q_0\hfill & \hfill {\delta }_{INI}(q_0,1)& =q_1\hfill \end{array}$$

  (12)

  $$\begin{array}{cccc}\hfill {\delta }_Z(q_1,0)& =q_1\hfill & \hfill {\delta }_Z(q_1,1)& =q_2\hfill \end{array}$$

  (13)

  $$\begin{array}{cccc}\hfill {\delta }_{INI}(q_2,0)& =q_0\hfill & \hfill {\delta }_{INI}(q_2,1)& =q_2\hfill \end{array}$$

  (14)
  The output function ${\lambda }^1$ represents the Mealy-type outputs of the ASM. Additionally, for each state $q\in Q$, each input symbol $a\in \Sigma$, each input signal $s\in \alpha$, each output signal $b\in \beta$, and each output value $d\in \Delta$, the function ${\lambda }^1$ is defined as follows:

  $${\lambda }_{s,b}^1(q,a)=d$$

  (15)
  For the automaton of the control unit in Figure 11, the output function ${\lambda }^1$ is defined as follows:

  $$\begin{array}{cc}\hfill {\lambda }_{INI,LA}^1(q_0,0)& =1\hfill \end{array}$$

  (16)

  $$\begin{array}{cc}\hfill {\lambda }_{Q{A}_0,IB}^1(q_1,1)& =1\hfill \end{array}$$

  (17)
  The output function ${\lambda }^2$ represents the Moore-type outputs of the ASM. Additionally, for each state $q\in Q$, each output signal $b\in \beta$, and each output value $d\in \Delta$, the function ${\lambda }^2$ is defined as follows:

  $${\lambda }_b^2\left(q\right)=d$$

  (18)
  For the automaton of the control unit in Figure 11, the output function ${\lambda }^2$ is defined as follows:

  $$\begin{array}{cc}\hfill {\lambda }_{LB}^2\left(q_0\right)& =1\hfill \end{array}$$

  (19)

  $$\begin{array}{cc}\hfill {\lambda }_{SHE}^2\left(q_1\right)& =1\hfill \end{array}$$

  (20)

  $$\begin{array}{cc}\hfill {\lambda }_{SEL}^2\left(q_2\right)& =1\hfill \end{array}$$

  (21)

With this lab exercise, learners apply and reinforce the knowledge acquired in the theoretical topics of special and applications counters, Memories, and ASM. Additionally, the learner applies the digital systems design methodology using ASM symbols for the implementation of the lab exercise.

Each element shown in Figure 9 is implemented using VHDL. Specifically, the learners apply the design using packages and components in VHDL, utilizing component parameterization. Furthermore, the control unit in Figure 11 is implemented using functional description by specifying states through the TYPE directive in VHDL. Functions, procedures, and file reading in VHDL are also implemented.

5.3. Connectivist Model Based on Connectivism Learning Theory

To conduct theoretical topics, learning activities, and the development and assessment of lab exercises for the DLD course, the Connectivism Learning Theory was applied. This theory is one of the most relevant frameworks in smart e-learning environments [21].

The Connectivism Learning Theory is the thesis that knowledge consists of sets of connections between entities, such that a change in one entity can result in a change in the other, and that learning is the growth, development, modification, or strengthening of those connections [58]. Connectivism is the integration of principles explored by chaos, network, complexity, and self-organization theories [59].

Siemens defines the principles of connectivism in [59]. Under the principles of connectivism, Siemens and Downes [58] proposed, in 2008, a connectivist learning activity environment, non-formal, called a Massive Open Online Course (MOOC). In this type of environment, there is no predefined content or thematic sequence. The learner makes decisions regarding the selection of thematic content and learning objectives. This approach gives the learner independence to establish a personal learning path based on informal learning [60]. This allows learners to acquire connective knowledge, which is distributed knowledge resulting from the connections formed by the properties of various entities included in the MOOC and their interaction [61].

In this paper, a novel connectivist model was developed for the DLD course using remote laboratories, which we have called as a Massive Open Online Laboratory (MOOL). The MOOL is described through different models, two of them are derived from the Unified Modeling Language (UML). UML is a diagram-based modeling language for the specification, visualization, construction, and documentation of any complex system [62]. It has been used to model software engineering systems as well as other types of systems [63,64,65,66,67]. In this paper, UML is used to model the connectivist environment. The models used are as follows:

• Entity model.
• Use case diagram.
• Activity diagram.

5.3.1. Entity Model

This model shows the functionality, connections and interactions of each entity. The model is shown in Figure 12.

Figure 12 shows the different entities of the connectivist model, each of them is explained below.

• Learning Management System (LMS) for DLD course. A LMS is designed to enable educators to manage, measure, and enhance learning experiences. Learning activities and didactic resources in LMS are lecture notes, instructional design documents, class videos, assignment and exercises. The LMS is shown in Figure 13.
• Cloud Storage. In this entity a native application is used for storing the content of the DLD course.
• Video conferences. This entity utilizes a platform that allows scheduling and initiating video conference sessions. In these sessions, participants can join to collaborate through voice, video, and screen-sharing functions. This platform is used to deliver synchronous theoretical class sessions, which are recorded for later storage in the cloud. This is done so that the videos can be accessed asynchronously by learners. During these sessions, learners’ questions regarding the covered topics are clarified and addressed.
• Virtual meetings. This entity utilizes a video communication service to conduct video conferences and virtual meetings. This service is used to hold synchronous class sessions for the review of lab exercises via the remote laboratory. During these sessions, learners demonstrate the functionality of each lab exercise to the instructor by implementing their VHDL program, running simulations via test bench file, and verifying the design on the FPGA through the remote laboratory. Learners’ questions related to the lab exercises are also clarified and addressed in these sessions.
• Platform for video storage. This entity uses a social media platform that allows hosting and sharing videos showcasing the remote laboratory’s operation. These videos can be accessed online asynchronously by the learners.
• Instant messaging application for mobiles devices. This entity uses a platform to communicate with all learners in the course for the activities shown in Figure 9. In addition, this node enables academic interaction among learners.
• Remote Laboratory. This entity uses the remote laboratory, where learners test lab exercises by programming the FPGA, interacting with it and manipulating it.

5.3.2. Use Case Diagram

Within the structural view is the use case diagram, which models the functionality of a system as perceived by the actors interacting with it [71]. The use case diagram of the connectivist model is shown in Figure 14.

Figure 14 shows the different use cases of the connectivist model, each of them is explained below.

• Deliver synchronous classes. In this use case, the professor and learner actors interact during synchronous classes. The participating entities are an instant messaging application for mobiles, video conferences, the LMS, and cloud storage.
• Generate didactic resources. In this use case, the professor actor generates didactic resources throw the editing in the LMS. The participating entities are the LMS, platform for video storage, and cloud storage.
• Review didactic resources. In this use case, the learner actor reviews didactic resources from the LMS. The participating entities are the LMS, platform for video storage, an Instant messaging application for mobiles, and cloud storage.
• Conduct learning activities. In this use case, the learner actor conducts learning activities from the LMS. The participating entities are the LMS, platform for video storage, an Instant messaging application for mobiles, remote laboratory, and cloud storage.
• Lab exercise assessment. In this use case, the professor, learner, and embedded system actors interact during the lab exercise assessment. The participating entities are an instant messaging application for mobiles, virtual meetings, the LMS, and remote laboratory.

5.3.3. Activity diagram

The dynamic behavior of the connectivist model can be analyzed through the activity diagram view [71]. These diagrams show the flow control of the activities performed by the learner, professor, and embedded system actors from de use case diagram, and each entity within the connectivist model. In the Figure 15 the activity diagram of the “Lab Exercise Assessment” use case is shown.

Figure 15 shows the interactions involved between the professor and learner actors and the instant messaging application for mobiles, virtual meetings, the LMS, and remote laboratory entities.

6. Results

The tests performed on the proposed system, as well as the evaluation of the results obtained, are divided into the following sections:

• Testing and results of server’s performance on the SoC.
• Testing and results of the ASM lab exercise conducted in the remote laboratory.
• Testing and results of the Technology Acceptance Model (TAM)
• Learning outcomes and assessment.

These tests were carried out using the remote laboratory, which consists of twelve development systems that have been used in the DLD courses of the Computer Systems Engineering program at the Higher School of Computing of the National Polytechnic Institute located in Mexico City.

Figure 16 shows the physical implementation of a system used in the remote laboratory, which consists of a System On Chip, SoC-FPGA interface, the FPGA development board, and power supply.

6.1. Testing and Results of Server’s Performance on the SoC

Figure 5 shows the video server and the SSH server implemented on the SoC used in the remote laboratory. Their testing and evaluations are described below:

6.1.1. Testing and Results of Video Server’s Performance no the SoC

The video server uses a Raspberry Pi Camera v2 [50] based on Sony’s IMX219 sensor [51]. This server allows a maximum of 10 users to connect. The server was tested with a program that displays the message "Lab-rEnnoto-ESCOnn-IPN!" in marquee mode using a 4-digit multiplexed common anode display module. The camera resolution is 1024x768 pixels at 20 frames per second. The Linux operating system command $top$ was used to obtain the CPU and memory usage percentages, which are shown in Table 3.

Table 3 shows that the maximum CPU usage percentage is 85.1, which corresponds to a single core of the processor. The remaining three cores are used for running other system processes. The percentage of memory used in the SoC is only 5.2% for 10 connected users.

6.1.2. Testing and Results of SSH Server’s Performance on the SoC

To test the SSH server, the JMeter application [72] was used. With this application, load tests were performed with a range of 5 to 50 users in time intervals between 1 second and 60 seconds. The results obtained are shown in Table 4.

In Table 4, it is shown that the system can handle up to 15 users within 1 second of response time. Additionally, it is observed that a maximum of 19 users can connect starting from 3 seconds of response time. This allows the connection of up to 6 groups of 3 learners each, along with one instructor.

6.2. Testing and Results of the ASM Lab Exercise Conducted in the Remote Laboratory

Each practice shown in Table 2 is analyzed, designed, and implemented using the Vivado v2022.2.2 tool from Xilinx [42] and the Nexys 4 development board [43] with the XC7A100TCSG324 FPGA [73]. The testing and evaluation of ASM lab exercise results is reported below.

Each element of the microarchitecture shown in Figure 9 is implemented using VHDL. Figure 17 shows the implementation of the control unit.

After the implementation of the lab exercise using VHDL, a simulation was performed using a Testbench file with the test vector $DA=0x3AAAAA$, which contains 12 bits set to one. This vector allows for verifying the correct operation of the lab exercise. Figure 18 shows the simulation result.

Figure 18 shows the right-shift operation in the $QAS$ register’s output and the increment in the BCD counters from 00 to 12. The result is finally displayed on the common anode displays.

Next, the input and output terminal assignment is performed using the constraints file and the virtual switches from the Remote Lab connector. In this moment, the synthesis, place and route, and generation of the BitStream file for the ASM lab exercise are carried out. After this process, the FPGA resources used are obtained, as shown in Table 5.

Timing information is also obtained, which is shown in Table 6. The maximum frequency of the design is obtained using equation (22).

$$Fmax={\displaystyle \frac{1}{T-WSN}}$$

(22)

Finally, the testing and evaluation of the ASM lab exercise is carried out using the remote laboratory and the connectivist model, as shown in Figure 19.

6.3. Testing and results of the TAM

The TAM is a theoretical framework developed by Fred Davis [74] in the 1980s to understand and predict user acceptance and adoption of technology. The model uses the following variables:

• Perceived Usefulness - PU.
• Perceived Ease of Use - PEU.
• Intention to Use - IU.

In this paper, the TAM is adapted with three additional variables, which are shown in Figure 20.

• Technology Application - TA Refers to the extent to which a learner utilizes foundational knowledge from areas related to the technology being used. This allows the learner to both apply previously acquired knowledge and learn new topics.
• Support Digital Resources - SDR Refers to the digital resources available to the learner for managing and using the technology. These resources include online user manuals, videos, supporting software, and Learning Management Systems.
• Acquired Digital Skills - ADS Refers to the acquired knowledge through learning digital technologies necessary for using the new technology. These digital technologies include CAD-EDA tools for managing and programming the physical device of the remote laboratory and applications for remote interaction.

Derived from the different variables of the TAM adapted shown in Figure 20, a data collection instrument was designed, consisting of a survey with 20 items. These items are shown in Table 7.

The items shown in Table 7 were applied the form of a self-administered survey applied to 28 learners from group 2CM16 of the DLD course taught during the 2021-2 semester, using a Likert scale. The Likert scale consisted of the values: totally disagree (td), disagree (d), neutral (n), agree (a), and totally agree (ta). Regarding item SP1, the surveyed learners were between 19 and 24 years old, with 46.4% being 20 years old. Regarding item SP2, 75% of the surveyed learners were male. The results obtained from the remaining items are shown in Table 8.

To determine the reliability of the data collection instrument, Cronbach’s alpha coefficient was used [75,76], which is obtained by calculating the variances of the responses given by the sample for each item. Its equation is given by:

$$\alpha ={\displaystyle \frac{k}{k-1}}\left(1-{\displaystyle \frac{{\sum }_{i=1}^k{\sigma }_i^2}{{\sigma }_T^2}}\right)$$

(23)

The Cronbach’s Alpha Coefficient was calculated over all the items in the survey. This was done using a program developed with the Pandas library [77] and the Jupyter Notebook development environment [78]. The calculated value of the Cronbach’s alpha coefficient is 0.77 , which indicates that the data collection instrument has good internal consistency [75].

6.4. Learning Outcomes and Assessments

To evaluate the remote laboratory, a quasi-experimental field design was employed [79], with the experimental group 2CM16. In this course, the connectivist learning model proposed in Figure 12 was used, and the course followed an e-learning approach. The learners were assessed using the rubric shown in Table 9.

The evaluation results of the experimental group 2CM16 are presented alongside the evaluation results of three control groups from the same course in the years 2017, 2018, and 2019, where the courses were taught in person. Each group consists of 33 enrolled learners, whose grades are used for the descriptive statistical analysis. The sample mean $\left(\overline{x}\right)$ was calculated as a measure of central tendency. In addition, the sample variance $\left(s^2\right)$, standard deviation $\left(s\right)$, and coefficient of variation $(CV=s/\overline{x})$ were calculated as measures of dispersion. This was done using a program developed with the Pandas library [77] and theJupyter Notebook development environment [78]. The results are shown in Table 10.

In Table 10, it can be observed that the grades’ sample mean $\left(\overline{x}\right)$ of the experimental group 2CM16 from the year 2021 is higher than the average in the groups from 2017, 2018, and 2019.

7. Discussion

7.1. Discussion of Server’s Performance on the SoC

As for the servers implemented on the embedded system, the video server supports up to 10 connected users, depending on the configured camera resolution, the number of frames transmitted per second, and the available network bandwidth. For 10 users, the video server on the embedded system shows a CPU usage of 85.1% on a single core and 5.2% RAM usage, indicating that the processing and memory resources provided by the embedded system are sufficient for the remote laboratory’s operation. Furthermore, an embedded system with fewer processing and memory resources could also be used, resulting in lower power consumption and reduced costs.

The SSH server can connect up to 19 users simultaneously, allowing up to 6 groups of 3 learners each, along with one instructor per remote laboratory. This is due to the maximum number of connections allowed by the network manager.

7.2. Discussion of the ASM lab Exercise

The ASM lab exercise illustrates the different stages of the DLD methodology, as shown in Figure 3, as well as the stages for using the remote laboratory, shown in Figure 4. The utilization of LUT and FF resources in this lab exercise is less than 1%, demonstrating the high availability of FPGA resources. Furthermore, the maximum frequency achieved is 452 MHz for this lab exercise; however, the other lab exercises use different FPGA resources, with maximum frequencies of at least 400 MHz. Additionally, further lab exercises can be proposed beyond those presented here.

7.3. Discussion of the TAM

The TAM adapted is applied, using six variables, to assess learners’ acceptance of the proposed technological architecture and connectivist model. The Likert scale survey conducted with learners shows a percentage greater than 92.9% for the totally Agree response in the Perceived Usefulness variable for all items, indicating that the RL supports the completion of DLD lab exercises.

For the variable of Perceived Ease of Use, the percentage exceeds 89.3% for the totally Agree response across all items, indicating that the applications developed on the SoC allow effective interaction and manipulation of the remote laboratory through the FPGA-based development board.

Furthermore, for the variable of Technology Application, the percentage exceeds 89.3% for the totally Agree response across all items, suggesting that knowledge acquired in other courses is applied and/or learned in the use of the remote laboratory.

Besides, for the variable of Support Digital Resources, the percentage exceeds 92.9% for the totally Agree response across all items, indicating that the support materials provided follow an appropriate techno-pedagogical design for using the remote laboratory.

Additionally, for the variable of Acquired Digital Skills, the percentage is over 85.7% for the totally Agree response in all items, suggesting that learners learned to use the Xilinx CAD-EDA tool for DLD.

Finally, for the variable of Intention to Use, the percentage is over 85.7% for the totally Agree response in all items, indicating that learners would use the remote laboratory in future courses or academic projects.

These results show a very high acceptance rate among learners. Additionally, learners provided further comments in the survey, some of which are:

• Learner 1: "The remote laboratory was a great support, bringing the lab exercise to our homes in a simple way, without the need to purchase extra materials for each of the lab exercises."
• Learner 2: "Completely an innovative tool and one of the most helpful while we were taking online semesters."
• Learner 3: "I think the use of a remote laboratory is excellent, as it extends the time for learners to test their lab exercises, and is not limited to available spaces or restricted usage time."

7.4. Discussion of Learning Outcomes and Assessments

In Table 10, it can be observed that the sample mean $\left(\overline{x}\right)$ of the grades for group 2CM16 in 2021 is the highest, with a value of 9.777, compared to previous years. This suggests that academic performance improves with the proposed system. Furthermore, the coefficient of variation, with a value of 6.49 %, indicates the lowest relative variability, suggesting a high and consistent performance among the learners of group 2CM16 when the proposed technological architecture and connectivist model were applied through the remote laboratory.

7.5. Discussion of Laboratory Modalities

Although this COVID-19 pandemic period motivated the development of the proposed technological architecture and connectivist model with an e-learning approach to solve the challenge of conducting distance lab exercises, it is not exclusive to this period. In fact, the remote laboratory has multiple advantages compared to the laboratory used in in-person classes, which are shown in Table 11.

7.6. Discussion of Comparison with Papers in the Literature Review

Finally, the main differences between this paper and the papers reported in the literature review is shown in the Table 12.

The evolution of emerging technologies such as the Internet of Things, mobile and ubiquitous computing, artificial intelligence, and embedded systems has enabled the Industry 4.0 [80] and the development of disruptive technological environments such as remote laboratories that allow remote experimentation, fostering the consolidation of knowledge and the reinforcement of theoretical concepts introduced in the classroom. The proposed architecture makes it possible to advance teaching and learning processes in various courses across different educational levels toward Education 4.0 [81] through the use of highly efficient, low-cost technologies.

8. Conclusions

The IoT applications implemented through various technologies have enabled the development of remote laboratories in different fields. The technological architecture and the connectivist model of the remote laboratory presented is a solution for the remote management of DLD physical equipment. The technological architecture is implemented using embedded systems based on SoC technology and applying the V-Model Methodology. This allows the development of highly efficient remote laboratories at a very low cost. The Systems on Chip (SoC) used in the implementation of the remote laboratory cost only $40.00 USD [82].

Furthermore, the remote laboratory allows learners to interact from anywhere (home, office, university, etc.), at any time with the FPGA-based development boards located in the institution’s laboratory and from any device (PC, laptop, mobile device, et.). This allowed learners to successfully complete 100% of the practices and reinforce the theoretical knowledge received during the semester. With this technological architecture, learners do not need to purchase these development boards, which have a high cost, $349.00 USD [83].

This paper presents a sequence of nine proposed lab exercises that cover the thematic content of the DLD course. With the implementation of the applications for programming the FPGA (progFPGA) and manipulating inputs through virtual switches (inputFPGA), leaners can program, manipulate, and interact with each lab exercise to verify its functionality.

The learning theory based on connectivism has enabled the creation of connectivist learning environments such as MOOCs. However, implementing these environments with a new technological platform like remote laboratories allows for the creation of a new connectivist environment, which we can refer to as a MOOL. This MOOL is designed using the UML for describing the entities, the functionality of the system and the flow control of the activities.

The MOOL contains the theoretical elements necessary for learning the course content, similar to a traditional MOOC. In addition, it includes the components for conducting lab exercises with real physical equipment. In the MOOL presented, the learners carried out the actions sequence for the on-site implementation of lab exercises and subsequently the actions sequence to use of remote laboratories.

The experimental group, where the proposed technological architecture and connectivist model with an e-learning approach were applied, has a group mean of 9.777 in their evaluation, which is higher compared to the control groups, where the traditional in-person teaching approach was used. This suggests that academic performance improves when the remote laboratory, the connectivist learning theory, and the e-learning approach are applied.