The review of heterogeneous design frameworks/Platforms for digital systems embedded in FPGAs, and SoCs

Systems-on-a-chip integrates specialized modules to provide well-defined functionality. To guarantee its efficiency, designers are careful to choose high-level electronic components. In particular, FPGAs (field-programmable gate array) have demonstrated their ability to meet the requirements of emerging technology. However, traditional design methods cannot keep up with the speed and efficiency imposed by the embedded systems industry, so several frameworks have been developed to simplify the design process of an electronic system, from its modeling to its physical implementation. This paper illustrates some of them and presents a comparative study between them. Indeed, we have selected design methods of SoC (ESP4ML and HLS4ML, OpenESP, LiteX, RubyRTL, PyMTL, SysPy, PyRTL, DSSoC) and NoC networks on OCN chip (PyOCN) and in general on FPGA (PRGA, OpenFPGA, AnyHLS, PYNQ, and PyLog). The objective of this article is to analyze each tool at several levels and to discuss the benefit of each in the scientific community. We will analyze several aspects constituting the architecture and the structure of the platforms to make a comparative study of the hardware and software design flows of


INTRODUCTION
The automation of the design flow of electronic systems began in the eighties with the appearance of coding in VHDL and Verilog. EDA (electronic design automation) takes advantage of the different levels of abstraction offered by these two languages to make the engineers' work easier and more flexible. Over the years and the evolution of technology, new challenges and challenges provoke the birth of new HDLs, like SystemC and DSL (Domain Specific Languages). These new generations of co-design tools exploit socalled high-level languages like Scala, C, and Python. By exploiting their resources in terms of libraries and the characteristic of simplified handling, the design flow of electronic components has seen a great leap forward that has marked state-of-the-art technology and contributed to the realization of intelligent systems.
These tools not only improve the design methodology but also contributed to the evolution of the applications and algorithms to be implemented. Indeed, thanks to the exploitation of the parallelism of FPGAs, circuits can make huge calculations and process mega data. The design flow of quite complex systems such as ASICs, and even the reconfiguration and reprogramming of FPGAs, also benefits from the evolution of computer science, especially development and programming. Certainly, many tools are based on high-level computer languages such as Python. The DSLs that we present in this, paper illustrate this

AN OVERVIEW OF OPEN-SOURCE INTEGRATED CIRCUITS CO-DESIGN
The study concerns many heterogeneous codesign processes of digital systems, which we classified into two categories: ✓ Systems on Chip and their derivatives such as MPSOC (Multiprocessor SoCs), DSSoC (Domain Specific SoC), SoC centric and, NOC (Network on Chip). ✓ Field programmable gate arrays FPGAs Below is a definition of the main lines of the design flow of each.

LiteX
LiteX [1] [2] is a design tool for SoCs and FPGAs, using libraries developed by Migen/MiSoC. It provides blocks (IP) ready to be used in a circuit. It integrates different infrastructures that the user needs, to define his project. All the elements necessary to create a SoC are taken care of by LiteX, from modeling by a

Them definition
• heterogeneous design frameworks/Platforms for digital systems embedded in FPGAs, and SoCs

Main questions and objectives definition
• How evolved is the overall heterogeneous landscape of SoC development? • Has the multiplicity of available tools sufficiently addressed the needs of designers? • Have these platforms reached the stage of being commercialized or being involved in commercial projects?

References collection & data evaluation
• Several databases were used to collect the most recent and most relevant sources.

Interepting the finding
• The comparative study is based on different axes to evaluate each platform. The results are the subject of an analytical discussion to conclude the SLR. simple script written in Python, to simulation and synthesis. As a result, the design process becomes easier and does not require another compiler or HDL generator.

RubyRTL
RubyRTL [3], as its name indicates, through the Ruby language (web development language), generates the Register Transfer Language RTL. It is based on the MigenPython toolkit as well as MyHDL, to establish the internal embedded DSL that will lead to the construction of the electronic components.

PyMTL
PyMTL [4] [5]presents a modular methodology for the design of integrated circuits. In fact, by exploiting the Multi-Level Modeling MTL, different phases of abstractions are established independently. PyMTL is a result of the work done in 2014 [6], which proved the importance of HGSF (hardware Generation and Simulation Framework) based on Python, to increase the performance of such a tool.

PYOCN
PYOCN (or PyMTL3-net) [7] [8] is a more complete version of PyMTL and aims at modeling, evaluating, and testing OCNs. It integrates the libraries necessary for the realization of this type of system, which involves the combination of several tools and processes. This Framework provides a synthesizable RTL while ensuring performance in terms of energy, time, and space.
Its principle is to build interconnection networks vertically to optimize the design space. The modular architecture adopted in this platform allows modeling, testing, and simulation in different levels of abstraction.

PyRTL
PyRTL [9] is a tool for describing embedded digital hardware. It exploits the advantages of Python, the high-level language. It does not contain non-synthesizable hardware primitives. In addition, it allows the inclusion of instrumentations tools in the structure to be designed. PyRTL provides a very important feature that was not possible with traditional design methods.
The intermediate representation of PyRTL provides the various tools necessary for simplification, implementation, and efficiency in the modelling of complex digital systems. Indeed, the intermediate representation allows for the creation of an instrumentation platform and to transform better handling. To create these tools, several easy-to-use APIs allow modifying the hardware blocks and providing the necessary information. Binary instrumentation for embedded hardware design is a method developed by PyRTL.

System Python: SysPy
SysPy [10] (released in 2012) is one of the high-level co-design approaches. It provides a platform that allows the synthesis of hardware behaviors, and design SoC centric: ✓ Incorporate scripts developed in Python, with existing hardware blocks. ✓ Incorporate IP cores into a circuit and ensure the connection between them.
In addition, it performs the main tasks in the design of SoCs and MPSOCs. ✓ The hardware description of all components is attached to the processor. ✓ Incorporation of the modules into a synthesized design. ✓ Establishment of software development scripts for the core processor.
SysPy combines two essential processes for SoC design. Abstract hardware description and FPGA prototyping to synthesize the circuit. It supports the following processor cores: OpenRisc 32bit, AVR ATmega128 8bit, and Leon 3.

OpenESP
OpenESP [11] is an open-source, tile-based platform for implementing SoCs. It is intended for applications that develop and enhance accelerators. It also comes for the deployment of Network of Chips (NOC) and interconnecting their processors and accelerators. Its high-level modular architecture allows for a high degree of abstraction in the heterogeneous chip design flow. It allows automated agile system synthesis, expansion, and flexibility when compared to other SoC co-design tools.
OpenESP integrates RISC-V core and NVIDIA Deep-Learning Accelerator. It encompasses several hardware design methodologies such as Vivado HLS, Catapult HLS, Stratus HLS, HLS4ML, and RTL.
The ESP SoC architecture is a matrix of tiles of different types (processor tile, accelerator tile, memory tile, auxiliary tile). The connection between these different elements is ensured by a multi-plan NOC (Network on Chip).

PYNQ
PYNQ [12] (Python Productivity for Zynq) is an application made by Xilinx to make it easier for programmers and designers to handle the Zynq and Zynq Ultrascale + MPSoC (Multiprocessor SoC) + RFSoC [13] (Radiofrequency SoC). It is the first project that used Python as a high-level description language. In addition, it provides a resource-rich library that the design engineer needs. This library hardware and joint JUPYTER application and web architecture strengthen the structure of the PYNQ Framework. Indeed, it has been exploited to realize different projects in different fields.

DS3
DS3 [14] (system-level domain-specific SoC simulation) is a system-level domain-specific SoC simulation platform. It leverages Dynamic Power and Thermal Management (DTPM) methodologies to provide users with a tool for resource optimization including the SoC design space.
DS3 has implemented wireless and radar communication benchmark processes. It also allows the implementation of heuristic and tabular planning algorithms. A solution aims at improving the energy performance of DSSoCs.

HLS4ML
It is an electronic system-building platform for implementing machine learning algorithms on FPGAs and ASICs. HLS4ML [15] allows the design of low-power components and accelerates decision-making by ensuring the translation and processing of algorithms in real-time.

ESP4ML
ESP4ML [16], is a whole design process for SoCs used in the field of machine learning ML and signal processing. It aims at the hardware acceleration of ML, taking advantage of the work done and the results obtained in HLS4ML and ESP (Embedded Scalable Platforms).
However, it has been necessary to adapt these two systems with the goals underlined for the ESP4ML framework. Indeed, an HW/SW layer is developed to adapt the architecture of the accelerators, in addition, the interface libraries to successfully implement the algorithms realized with HLS4ML in the SoCs.

Princeton Reconfigurable Gate Array (PRGA)
PRGA [17] is a manufacturer of custom FPGAs and manipulates them in other systems as ASIC. Through Computer-Aided Design tools, it allows the synthesis of the generated RTL. It converted first in a Bitstream series by the PRGA Tool Chain part. The separation between the manufacturer and the toolchain gives the characteristic of modularity and flexibility. Indeed, the user can intervene to modify his system at any phase of the design.

PyLog
PyLog [18] is a focused algorithm that aims to simplify and optimize FPGA configuration. This scalable tool converts the script written in Python, into a synthesizable code via compilers and different passes, which completes the role of intermediate presentations PyLog IR generation and optimization.

AnyHLS
AnyHLS [19] has come to solve the problem that programmers have with hardware description whether it be by VHDL, Verilog, or System Verilog. It requires knowledge of FPGAs. This approach allows the design, by generating HLS synthesizable code.
It takes advantage of the already proven work in AnyDSL [20], as a high design compiler, using the Impala language and partial evaluation. AnyHLS has developed its library in the field of image processing.

OpenFPGA
OpenFPGA [21] is an approach for the design of custom FPGAs. This new methodology for building these components. It reduces the time needed to build their architectures, and even reconfigure them for a specific application.
OpenFPGA provides not only the ready-to-use Verilog coding and manufacturing (production flow) but also the Bitstream structure (end-user flow), which describes the designed FPGA in XML language, for digital use.

Comparison study
This section aims to develop a study and analysis of the Frameworks/platforms presented previously. We will dig into their architectures, and their design flows to identify the common and distinct points and the advantages of one over the others. Furthermore, we evaluate each platform, via enumerating hardware achievements, and completed projects. Table 1 below, samurize the highlighted lines of the comparative study.

HDL describes the structure of the design flow
Most of the design processes presented are based on Python as illustrated in Figure 2, a high-level programming language.

Figure 2. Python as an HDL for description behaviours of digitals circuits
OpenESP indirectly uses Python. It supports PyTorch as a language for designing SoCs. Furthermore, ESP can also be programmed with C/C++, SystemC, Keras Tensor Flow, ONNX, Chisel, SystemVerilog, and VHDL.
Also, HLS4ML [15] is programming with (Ǫ) KERAS, PyTorch and, ONNX. KERAS [22] is an application-programming interface API, based on Python and uses the TensorFlow ML platform as a software interface. Open Neural Network Exchange ONNX [23] provides the developers with a graphical presentation of the modeling of the Machine Learning elements Python allows both, the description of the behaviour of the system to be designed with a high level of abstraction and to model its hardware architecture using the tools offered by the components to be configured i.e., FPGAs. Hence, the unification characteristic of the digital platforms of the design flow of embedded systems is endowed.
On the other hand, the programming structure in Python facilitates the work of designers. It provides them with the different tools (functions and commands) they need, and with a syntax that is easy to learn and exploit.
Ruby as Python is a high-level language, contrary VHDL, Verilog, and SystemVerilog there allow an abstraction low level. Ruby is known as a web environment development language especially with the emergence of Ruby on rails (creation of web applications). It also offers many advantages for programmers from structuring to compilation. Impala [24] is a programming language that provides as a result the intermediate representation of Thorin. It is based on the continuation-passing style (CPS), and the syntax of Rust. It allows the specific description of such a domain [25]; hence, it does not support standard resources. The advantage of this language is that it can be interfaced with other programming languages like C and C++ [25].
Kernel [26] shared with C many features. Indeed, it is developed with it. The main advantage of the programming language Kernel is the orthogonality of the constructor.

Synthesis language
As shown in Figure 3 below, apart from the traditional HLS that dominated the automation of the synthesis of electronic components, VHDL, Verilog, and SystemVerilog, there appeared another python-based coding for the physical implementation of an architecture, and digital presentation of description hardware.   [11]. Hence, contributing to the evolution of the automation of the HW/SW design of electronic systems.

✓ Synthetized C++
The integration of an ML system in an ASIC chip is more complex than in FPGA. HLS4ML uses C++ to compile the designed model and generates the RTL code that will be physically implemented. This process respects the triple to optimize Power, Performance, and Area PPA.  [28] is the platform realized by Xilinx for adapting preliminary code (developed in a familiar C, C++, or SystemC language), and translating it into synthesizable code (VHDL, Verilog, or SystemC RTL). Two necessary steps are performed to properly carry out this task: -Firstly, model the architecture according to a clock cycle count.
-Secondly, convert the program elements into logic ports.
Vivado HLS also provides tools for the verification and simulation of the generated RTL model, in order to have a first validation of the elaborated system.
✓ AOCL AOCL (Altera SDK for OpenCL) [19] is leveraged by AnyHLS to ensure the portability of Intel FPGAs. OpenCL [29] is a platform developed in C and C++ that aims at the high-level synthesis of models with more speed while decreasing the Time to Market. AOCL completes the work of OpenCL by ensuring the verification and prototyping of circuits for a good imitation of the real system.
✓ Python HLS the intermediate representation of Pylog [18] (Pylog IR) allows for the generation of the HLS C code that can be synthesized by the compiler. The latter uses the HLS pragmas to transform the source code written in Python, into an HLS exploitable in the RTL-based design flow.
PYNQ does not generate an HLS [30]. It is necessary to use an FPGA fabric. However, it provides a PNQ Overlays platform which ensures the interfacing of the application developed in Python with the physical inputs and outputs.
These hardware libraries [31] allow the overlay and customization of physical circuits. In addition to API, PYNQ Python provides a tool for the control and configuration of overlays. So, designers are not required to create these libraries, but just write lines in Python to operate the management interface.

✓ Bitstream
OpenFPGA [21] offers hardware engineers the choice of FPGA binary configuration, via FPGA-Bitstream. This feature is only applicable for FPGA architectures supported by Versatile Place and Route VPR [32] (an open-source builder of CAD algorithms and structures for FPGA) whose role is to be a packaging engine [33].
Similarly, PRGA [17] uses the tool named PRGA Builder to generate the .xml extension files that will be processed by VPR to provide at the end of the bitstream.

✓ Yosys
PyRTL [9], PRGA [17], OpenFPGA [21] use an external tool to accomplish the task of establishing the synthesizable RTL model. Yosys [34] is an open source (ISC license) intended for generating synthesizable code via Verilog and implementing it on FPGAs or ASICs. It can be used for Xilinx 7 series, Intel, Lattice iCE40, Lattice ECP5, Silego GreenPAK4, Gowin, and Analogic. Yosys provides a code converter [35] generated in BLIF / EDIF / BTOR / SMT-LIB / simple RTL Verilog / etc. Its use in different projects is due to the synthesis methodologies offered for various applications.

Tools and libraries
The platforms that are the subject of this study differ in the methodologies and procedures employed in their process of building or simulating/emulating digital systems as shown in Figure 4 below. LiteX [1] and RubyRTL [3] use the libraries available in the Migen toolbox. Taking advantage of the benefits and features of the Python programming language, it provides a reliable procedure for designing complex electronic/computer systems [36]. Migen comes to fill the gaps left by software design based on traditional languages (VHDL and Verilog). Migen also uses the FHDL (Fragmented Hardware Description Language) module [37]. It provides a behavioral description with code written in Python so that it differentiates between combinatorial instructions, synchronous instructions, and reset values.
In 2018, an enhanced version of Migen was launched, nMigen [38]. It takes care of all the modeling that Migen supports. In addition, new libraries are integrated. Now it provides communication via I2C and SPI protocol, interconnection with configuration and state register (CSR), and compilation of Rust code on Minerva RISC-V.

✓ MiSoC toolbox:
To be able to synthesize systems on Chip, LiteX uses the MiSoC tool [36]. It is a complementary/extended solution to Migen, to provide the designer with an efficient and easy methodology for building SoCs. it integrates different processors, memory modules, additional peripherals. In addition, it allows resource optimization with high performance.

✓ Sexpir tools:
Sexpir [3] is an intermediate representation developed by the team that designed RubyRTL, but work is in progress for final validation. It is a bidirectional transformation of RTL code from Python (via Migen) to Ruby (via RubyRTL) [39]. It also allows the generation of VHDL code for physical implementation on FPGAs and ASICs.

✓ KERAS
The HLS4ML library [40] relies on two main tools [15], Keras and Pytorch which are developed in the following part. [22] This specific API for deep learning offers speed in obtaining results. It is executable on the end-to-end interface named TensorFlow. It allows to development of solutions for deep learning via different abstractions and the export of graphs to other tools. As a result, [41] the deployment of ML applications becomes easier. TensorFlow aims at accelerating the implementation of neural networks.
✓ Toolbox based on Python / C The process of PyMTL [6] consists of manipulating the instance model elaborated according to the specifications and configuration described by the programmer, by simulation, translation, and user tools to provide in the end a model that is consistent and faithful to the behavior of the physical circuit. The translation tools provide the Verilog code after processing PyRTL, analyzing its structure, and its connections. The PYOCN EDA script [7] for use in the EDA flow exploits this result. Then, the simulation tools, analyze the ports and logical blocks, to provide the operator with a powerful python simulator. Finally, the user tools are the custom methodologies created by the operator himself to ensure the scalability and flexibility of the Framework.
In 2020, researchers from Cornell University have released a recent version of PyMTL. Indeed, PyMTL3 [4] comes with new passes that improve the quality and performance of the models developed in the early design phases. The following table 2 illustrates these new features: As already mentioned, PYOCN [7] is based on PyMTL, being its modular architecture (modeling, testing, and evaluation). The same tools are used in the OCN construction process. Additional tools were needed for modeling the networks. Certainly, libraries specific to this type of chip have been integrated (InputUnit, SwitchUnit, RouteUnit, OutputUnit, Router, Channel, and Network).
The SysPy platform also includes methods written in Python for hardware description. [44] In its structure, we find a synthesizable Python to VHDL converter. Besides a GCC (GNU Compiler Collection) compiler that takes care of the management and control of the processors, there is also an XST synthesizer of the generated code.
Furthermore, SysPy allows synthesizing the CoreLib components describing the SoCs via netlist files, which will be input for the converter.
SysPy provides a communication interface between the SoCs, and the hot computer [10], through a HAL hardware abstraction layer. This gives access to the FPGA communication channels (GPIO, Ethernet), and the RAM.
An interface [10] has been realized, to communicate either with other SoCs or with a host computer. This window allows the controlling and exchange of data via communication protocols. Indeed, there is a channel for intra-chip communication and another for external systems. Then a designer can launch operations and treatments, as a command to be executed by the SoC processor or its peripherals. These features are due to the creation of a hardware abstraction layer HAL and software API. Python is always present in this design. The API is developed with Python classes and functions, which will allow the control of the designed SoC, via transmission and reception frames and data storage in memory.

✓ CAD tools
PyRTL [9] provides a very important feature that was not possible with traditional design methods. This is introspection, which allows the hardware behaviour or design pattern to be copied, using pipelines and the next_stage () function. The intermediate representation of PyRTL provides the various tools necessary for simplification, implementation, and efficiency in the modelling of complex digital systems. The logical operations create WireVectors with a bit number as input.
Binary instrumentation for embedded hardware design is a method developed by PyRTL. Indeed, the intermediate representation allows for the creation of an instrumentation platform and to transform better handling. To create these tools, several easy-to-use APIs allow to modify the hardware blocks and provide the necessary information.
The wires used in the circuit do not store the information of the network they belong to. So, to remedy this problem, net connections have been developed. This function establishes a dictionary that gathers all the Circuit changes are handled by two functions: wire_transform() and net_transform(). They support modification of the hardware design, either by adding additional instrumentation or just replacing a logic block. For the transformation to be effective it needs a well-ordered data flow that respects the iterator. This functionality is presented as a default iterator for a block. There are two types of transformation: i) Operation transformations: The function has an argument, a logical block, and a procedure that will be called on each LogicNet (the tool that stores the information related to a logical block: network and file) of the system. The result it provides is in the form of a Boolean, which will allow the operation transformer to know if the original LogicNet should be kept in the block. ii) Connection transformations: This time things are more complicated. The connection transformation function uses as input a WireVector which is itself a network, and returns two WireVectors, source, and destination, which correspond to a "slot" connection. So, this transformation is just another function that defines the wire information.
On the other hand, the operation of the PRGA platform requires the application of certain CAD tools [17] : -an RTL code synthesizer -port packer -configurable logic blocks (CLB) locator -bitstream generator The production flow includes the different methodical elements that the OpenFPGA framework exploits for the prototyping of custom FPGAs [33]. First, we have the SDC (Synopsys design constraint) which provides us with STA Tools necessary for time management and validation [33]. In addition, with the contribution of Fabric Verilog, SDC allows us to establish GDSII layout via Backend Tool. The HDL Simulator and Format Tool check the format and the functional aspect of the Verilog Testbench model.

✓ Tile's structure
The ESP SoC [11] architecture is a matrix of tiles of different types: -processor tile: Each tile includes a selected processor that is system independent, and it communicates on a local bus.
-accelerator tile: This tile follows a well-defined architecture. The sockets available on the platform make it easy to create accelerators by exploiting registers, addressing, and protocol.
-memory tile: The memory tile includes an LLC (last-level cache) partition that implements the MESI protocol.
-auxiliary tile: It gathers all the peripherals that complement the work of the processor. Its socket is the most complex, as it manages several services. The tile ensures the communication between its masters (Ethernet), and the slave devices.
The connection between these different elements is ensured by a multi-plan NOC (Network on Chip). The transparent communication layer uses multiple ports to exchange data. They include standard bus ports, bridges, interface adapters, and proxy components. The bus masters are the accelerators and processors, while the slave devices are any other system components such as memories, UART, and Ethernet.
The Application Programming Interface (API) of the ESP platform is a method of managing and executing accelerators from a user application using three programming functions. ESP_run for execution, ESP_alloc, and ESP_free for memory allocation.
For existing accelerators, ESP provides a third-party design flow (TPF) to integrate directly into the SoC. Simply fill in an XML file and provide the source file either coded in Verilog, VHDL, or SystemVerilog.

✓ Libraries
AnyHLS [19] uses AnyDSL as a library that the user uses in his configuration of the system architecture to be designed. It is a compiler based on the THORIN intermediate representation based on continuation-passing style (CPS IR Thorin) and partial online evaluation [20].
AnyHLS [19] also integrates a specific library for image processing. Indeed, the exploitation of the impala language and the architecture of this high programming tool allows generating all the abstractions (in the form of libraries) that the user needs to build his circuit. AnyHLS provides a whole set of tools like: -The make_local_op generator that ensures decoupling of the algorithm from the scheduling and memory operators -Libraries for the management of Processing System PS/ Programmable logic PL interfaces (Allocate, Interrupt, MMIO, PS GPIO).
-Libraries for the control of PS/PL interfaces (PMBus, Overlay Device and Bitstream classes, Microblaze Library).
-Hardware libraries [31] that aim to accelerate and/or personalize a digital application. it is simply the construction of programmable logic or a new configuration using a python interface [47].
PyLog [18] incorporates the existing HLS C library as well as additional features. Indeed, the functions offered by NumPy are available on the PyLog platform.
✓ Runtime System: ESP4ML [16] integrates a software tool for gas pedals. This API allows the configuration of data traffic on NOCs, as well as pipeline elements ✓ Job/Tasks generator: the task generator [15] used by DS3 allows the establishment of DAG (Directed acyclic graph) specific to a given application.
✓ Scheduling and DTPM Algorithms: DS3 [14] includes Dynamic Power and Thermal Management policies and scheduling algorithms, which will allow designers to model and implement new algorithmic procedures. It is thanks to the Scheduler class and the constructor functions that the user creates his algorithm. The platforms that are the object of this study have the same intentions of improving the performance of FPGA design whatever the field of application. Hence, the functionality of the simulator used in the design chain determines and evaluates the approach in the first place. Figure 5 above summarizes the different simulators used for each framework.

✓ GHDL
RubyRTL does not include its simulator; however, the results generated by RubyRTL can be simulated on GHDL [3]. It [48] is a VHDL code simulation tool that uses code generators such as LLVM and GCC to ensure a fast simulation cycle.

✓ LiteXSim
The Verilator simulator (released in 1994) inspires LiteXSim SoC Simulator [1]. [49] [50] this one allows converting a synthesizable RTL code developed in Verilog or SystemVerilog, into a script written in C++ or SystemC (.cpp and .h files). The Verilator compiler is characterized by its high performance. The speed, optimization, and partitioning of the RTL model allow them to outperform traditional compilers (for example, it is 100 times faster than Icarus Verilog).

✓ Python simulator
PyMTL [6] [5] unifies the advantages of python via PyPy System and those of HGSF (Hardwar Generation and Simulation Framework) to provide SimJIT (Just in time), a simulation approach that aims at optimizing RTL and CL (cycle level) modeling. The software architecture of SimJIT consists of converting the input code (either RTL or CL) into a wrapped C++ model, using the intermediate representation and the toolbox involved. The simulation passes for the improvement of the established PyMTL model [4] to enhance the performance of this tool.
In the same sense, the PyRTL simulator [9] synchronously interprets the initial C program, so that the states and calculations are returned to the user simultaneously. The simulator has approved its performance not only in terms of emulation cycle time but also in terms of the size of the code to be written.
PYNQ [51] also integrated a Python library for emulation of Xilinx Zynq systems generated by the PYNQ environment. Furthermore, the simulation is available on Vitis [52] (see next paragraph).
✓ Kernel simulation DS3 is a compiler/simulator based on the Kernel language as mentioned above. This simulator [15] allows the implementation of scheduling algorithms and machine synchronization. Thanks to the Kernel simulator [53] structure, it allows visualizing the progress and the future state of the simulated model.

✓ Merlin compiler
PyLog compiler [18] is the combination of two compilers Vivado HLS (see the previous section) and Merlin compiler.
[54] It is a solution dedicated to hardware acceleration especially for software developers who do not master traditional HLS (VHDL and Verilog). It facilitates computation and processing for cognitive applications such as machine learning and big data. The Merlin compiler from Flacon computing [55] (acquired by Xilinx) provides an executable model on FPGAs from a script written in C with all the design abstractions ✓ GCC Compiler SysPy generates the synthesizable code from the script established by the GCC compiler [44]. The GNU Compiler Collection GCC [56] is an optimized approach developed with multiple programming languages and integrates several hardware architectures.

✓ PyOCN Simulator
In addition to PyMTL's optimized approach to model evaluation, PyOCN [7] integrates a simulation process suitable for the OCN target. PyOCN Simulator is used at the cyclic level of network design. It does not apply to synthesizable RTL.

✓ Vivado Simulator
HLS4ML is a main component in the structure of OpenESP and ESP4ML [16] [11] [16] . These three platforms provide a code whose simulation is ensured by Vivado Simulator, also we can add in this category OpenFPGA [33] that uses HDL simulator as a tool for verification and evaluation. [57] This general environment reduces the execution time by detecting errors on the object code of behavioral, functional, and temporal simulation. The simulation can be run at any level of abstraction to verify the generated model. [58] The two interfaces DPI (direct programming interface) and XSI (Xilinx proprietary interface) for interaction between the simulation kernel and C scripts or HLS enrich the simulation tools and the co-simulation for better performance.

✓ AnyDSL compiler
AnyHLS use AnyDSL for the compilation of image processing via partial evaluation [19]. The partial evaluator [20] works with CPS style intermediate representation-based structures to generate CPU and GPU specific vectorization and parallelization code. This compiler is dedicated to the fields of image processing, ray tracing, and genomics.

✓ Synopsys VCS
The experiments carried out on PRGA uses Synopsys VCS as a simulator [17]. It [59] is a simulation engine based on the Fine-Grained Parallelism FGP methodology. This has allowed it to raise the performance in terms of time and bug checking to provide a high-quality design. VCS [60] integrates different technologies

Evaluation, and experimentations
In the field of electronics and especially embedded systems, the physical implementation of the programmed models is an essential step to evaluate the reliability and efficiency of the approach followed for the design of a circuit. Hence the importance of this section, which represents the achievements of each application, either as an experimental verification or even as a contribution to a project with industrial or academic stakeholders. Table 3 below provides more details. To be a teacher in two universities: Cornell University and Boston University.
PyRTL Most (except RubyRTL) of the studied frameworks are experimentally verified. Indeed, each of them proceeded to applications even at a small size to evaluate the developed tool and measure its performances to see the level of its competitiveness compared to the current tools in the field. Thus, highlighting the prospects and future work to be developed or the weak points to be improved, to build a solid approach at the level of architecture, handling, evaluation, and synthesis.
LiteX and PyMTL succeeded in this step and collaborated with other participants interested in the evolution of hardware and software design of systems. LiteX together with Enjoy-Digital [ academic cursus of two universities as an approach to be taught to students of different cycles. It constitutes a whole module with tutorials and practical works to validate for better learning of the tool.

DISCUSSION
In this article, we have tried to present a review of some methodologies for the heterogeneous design of electronic systems, namely FPGAs and SoCs. The different solutions are analyzed in several aspects.
First, the choice of the development language is linked to the objectives to be reached and also to the applications targeted by the manufacturer. The general-purpose platforms exploit the functionalities offered by Python, and Ruby as high-level languages, and yet the others dedicated to the domains of machine learning, image processing, and computer vision go to more specific and specialized languages in an activity like impala and Kernel.
Second, the generated synthesizable code. Each Framework incorporates a tool for generating or converting script initially written in a synthesizable RTL model. Some use traditional languages (VHDL, Verilog, and SystemVerilog) that have proven their reliability over the decades. Others have chosen more recent processes developed with techniques that are more advanced and procedures like Vivado and Yosys. In addition, some of them exploit object-oriented programming languages (Python and C++) to build their converters with additional options such as the digital synthesizer (BitStream).
Afterward, we dissected the toolbox of each approach. Again, the purpose of the work plays a role in the guideline to adopt. However, the libraries integrated into the packages used after LiteX, RubyRTL, AnyHLS, PYNQ, and PyLog are written in Python, and in addition, Pytorch and most of the computer-aided design tools are developed in Python. As a result, most platforms rely on Python to create a toolchain that is appropriate for their architectures. Obviously, due to the nature of the applications they were built for, it was necessary for HLS4ML, ESP4ML, and DS3 to add other additional mechanisms to complete their needs.
Subsequently, we have delved further into the structure of the studied Frameworks, discussing the methods of verification and evaluation of the functional or behavioral modeling. Except for LiteX, PYOCN, and PyMTL, all the procedures have integrated an existing simulator into their processes. Indeed, instead of building a new kernel, they benefited from the performance demonstrated by high-level simulation engines, for example, Synopsys VCS, Kernel simulator, GCC compiler, Merlin compiler, and Vivado simulator.
As far as PyMTL and PYOCN are concerned, we can say that the simulation between them is similar since the PYOCN simulator neither combines the passes of PyMTL and some libraries to make them suitable for running on-chip networks. However, LiteX takes advantage of Verilator to design and reconfigure a fast simulator of SoCs and IPs.
Finally, the most critical and definitive step in building a digital circuit is synthesis. It identifies the rational and pragmatic potential of such a platform. As we mentioned in the previous section, LiteX marks its strong presence in the industrial market. Not only one or two, but also several projects of highly sophisticated electronic components and boards have been established using this method. This shows the engineers' satisfaction with the features and benefits offered.

CONCLUSION
In this article we have illustrated the advancement of integrated circuits design flows, by presenting some platforms, most of which are recent (released in 2020, 2021). Each one has its methodology for the realization of a target component, but they share the concern of performance optimization. According to their application domains, each tool is privileged by one or several characteristics that distinguish it from the others.
The projects carried out and the experiments did show the maturity and the physical and even commercial handling of the platforms. Indeed, some of them are still underdeveloped (RubyRTL, PRGA), and others have already marked their presence in the market via the contribution to the realization of commercialized systems, or they are integrated and approved in an academic cursor (LiteX, PYNQ, PyMTL, SysPy). While OpenESP, ESP4ML, HLS4ML, AnyHLS, PyOCN, PyRTL, DS3, and PyLog have completed evaluation and verification experiments.
SoCs in general are now proposed as emerging and scalable solutions for intelligent applications. Hence, design methodologies must incorporate new functionalities satisfying the performance/power consumption/space/size challenges and dilemmas imposed by the evolution of advanced technology.