Code generation from a model with nested subsystems.
This example logically continues the previous demonstration. Its purpose is to show the capabilities of the Verilog code generator, namely various approaches to structuring the final project through the use of atomic subsystems.
The figure below shows the implemented model. It contains the configuration "Treat as atomic unit" applied to only one of the two blocks, which allows you to visually compare the generation results.
Now let's move on to code generation and comparing the results with the original model. First, let's declare an auxiliary function that will run our model.
function run_model( name_model)
Path = (@__DIR__) * "/" * name_model * ".engee"
if name_model in [m.name for m in engee.get_all_models()] # Проверка условия загрузки модели в ядро
model = engee.open( name_model ) # Открыть модель
model_output = engee.run( model, verbose=true ); # Запустить модель
else
model = engee.load( Path, force=true ) # Загрузить модель
model_output = engee.run( model, verbose=true ); # Запустить модель
engee.close( name_model, force=true ); # Закрыть модель
end
sleep(0.1)
return model_output
end
Now let's configure the model for code generation on Verilog.
We will perform code generation directly from the model interface (at the click of a button), so as not to overload the already voluminous script.
Next, we declare an auxiliary function for reading the generated Verilog files. How the function works read_v it consists of the following. First, it checks the existence of the specified file in the file system. If the file is not found, a corresponding message is displayed. Upon successful detection, the function reads the entire contents of the file as a string and visually outputs it to the console, framing it with a header and delimiters for ease of perception.
function read_v(filename)
try
if !isfile(filename)
println("Файл $filename не найден!")
return
end
println("Содержимое файла $filename:")
println("="^50)
content = read(filename, String)
println(content)
println("="^50)
println("Конец файла")
catch e
println("Ошибка при чтении файла: ", e)
end
end
Now let's move on to comparing the implementation of subsystems. The key difference is in the organization of the output code.
In the case of implementation without the use of atomic subsystems, the head project file includes all the logic of the system, presented as a single monolithic module. This module contains numerous registers and complex combination chains combined in a single namespace.
read_v("$(@__DIR__)/model_RX.v")
The atomic subsystem approach demonstrates the modular principle of project construction. The head file acts as a top-level wrapper that instantiates and connects individual functional blocks: a data generator, a modulator, and a filter. Each of these blocks is an independent module (Gen_data, QPSK_modulator, fir) with its own clear I/O interfaces. This structure not only reflects the logical division of the system into components, but also significantly improves the readability, maintainability and reusability of the code.
read_v("$(@__DIR__)/model_RX_atomic_code/model_RX_atomic.v")
It also follows from the comparison that writing a test environment (testbench) is a simpler task specifically for the project version without atomic subsystems. Since the generated code in this case is a single module, its connection and monitoring of outputs does not require a description of a complex hierarchy. In this example, all the logic of the system is contained within a single block, which allows you to directly monitor the output signals.
We will use this advantage to carry out verification. Since the functional behavior of both versions of the project is identical, we will check the correctness of the work on a monolithic implementation.
This testbench performs two main functions:
- Clock and reset generation: A periodic clock signal (clock) and a reset control signal (reset) are generated to initialize the device.
- Logging of output signals: all device outputs (io_Out3, io_Out1, io_Out2) are written to a text file "output.txt " on each positive edge of the clock signal after the reset signal is removed.
read_v("$(@__DIR__)/tb.v")
Now let's run the initial model and test the generated code. This will allow us to verify the correctness of the generator by comparing the behavior of the source system in the Engee simulation environment with the results obtained when executing the generated Verilog code in the simulator.
run_model("model") # Запуск модели.
run(`iverilog -o sim tb.v model_RX.v`)# Компиляция
run(`vvp sim`)# Запуск симуляции
For subsequent analysis, a parsing function of the text file generated by the testbench is required. Implemented function parse_simulation_data converts the raw logged data into a format suitable for analysis, the function itself returns three arrays ready for analysis and plotting.
The algorithm of operation:
- Reading data: The function reads the file, separating the lines by spaces (timestamp, valid signal, hexadecimal values of quadrature components)
- Format Conversion: Hex strings are converted to UInt8 numbers by parsing from hexadecimal representation
- Normalization: The key step is the conversion of numbers through an additional code (twos complement) followed by normalization to the range [-1.0, ~0.992] by dividing by 128
using DelimitedFiles
function parse_simulation_data(filename)
data = readdlm(filename, ' ', skipstart=0)
valid = Int.(data[:, 2])
re_hex = string.(data[:, 3])
im_hex = string.(data[:, 4])
Re_u8 = [parse(UInt8, h, base=16) for h in re_hex]
Im_u8 = [parse(UInt8, h, base=16) for h in im_hex]
function twos_complement_to_float(x::UInt8)
x_signed = reinterpret(Int8, x)
return Float64(x_signed) / 128.0
end
Re = twos_complement_to_float.(Re_u8)
Im = twos_complement_to_float.(Im_u8)
return valid, Im, Re
end
Val, Im, Rm = parse_simulation_data("output.txt")
Re_sim = collect(simout["model/RX.Out1"]).value
Im_sim = collect(simout["model/RX.Out2"]).value
Val_sim = collect(simout["model/RX.Out3"]).value;
Now let's move on to comparative analysis. The graphs below show: a constellation diagram, graphs of the real and imaginary parts of the signal, and a diagram of the validity signal.
function plot_iq_constellation(Re, Im; title="", color=:blue)
scatter(Re, Im,
aspect_ratio=:equal,
markersize=2,
markerstrokewidth=0,
alpha=0.6,
title=title,
xlabel="In-phase Component (I)",
ylabel="Quadrature Component (Q)",
legend=false,
grid=true,
color=color)
end
valid_indices_sim = findall(Val_sim .== 1) # Индексы где Val_sim == 1
valid_indices = findall(Val .== 1) # Индексы где Val == 1
p1 = plot_iq_constellation(Re_sim[valid_indices_sim], Im_sim[valid_indices_sim],
title="Созвездие модели", color=:blue)
p2 = plot_iq_constellation(Rm[valid_indices], Im[valid_indices],
title="Созвездие Verilog", color=:red)
plot(p1, p2, layout=(1,2), size=(800,400))
plot(Re_sim, label="Re_sim", seriestype=:steppost)
plot!(Rm, label="Rm", seriestype=:steppost)
plot(Im_sim, label="Im_sim", seriestype=:steppost)
plot!(Im, label="Im", seriestype=:steppost)
plot(Val_sim, label="Valid_sim", seriestype=:steppost)
plot!(Val, label="Valid", seriestype=:steppost)
Visual analysis of these graphs allows you to verify that the generated code fully matches the behavior of the original model. The shape of the signals, the nature of the constellation, and the time parameters are completely identical, which confirms the correct functioning of the automatically generated Verilog code and its exact equivalence to the original mathematical model.
Conclusion
This work clearly demonstrates the effectiveness of using automatic Verilog code generation from Engee models. The complete functional equivalence between the initial mathematical model of the system and its hardware implementation obtained through code generation has been experimentally confirmed.
A comparative analysis of two approaches to project structuring - monolithic and modular using atomic subsystems - showed their fundamental differences in code organization while maintaining identical behavior. The modular approach provides better readability, maintainability, and reusability of the code, while the monolithic implementation simplifies the creation of a test environment.
Verification of the results through a comparison of time diagrams and constellation diagrams confirmed the exact correspondence of all output signals, which indicates the correct operation of the code generation tool and the possibility of its practical application for the design of digital systems.