For more detailed information, please refer to the PDF documentation.
The power supply was never installed in the actual tube amplifier and the original repository was lost at some point when changing computers hence this repository picks up at the point which was recovered from some old copy that I happened find from my old hardrive.
As of writing AMD Vivado, Efinix Efinity and Lattice Radiant with Synplify Pro (and Altera Quartus Pro which only supports mid to high end FPGAs) tools has support interfaces that is most important rtl enchancement of VHDL2019, hence the project will be refactored to use this fantastic feature of VHDL. This allows specifying in and out directional signals in a record, hence prevents the need to have two records for each entity. This feature can also be simulated using open source NVC simulator.
package boost_rtl_entity_interface_pkg is
type boost_model_interface_record is record
bus_to_boost_model : fpga_interconnect_record;
bus_from_boost_model : fpga_interconnect_record;
end record;
view boost_model_interface_view of boost_model_interface_record is
bus_to_boost_model : in;
bus_from_boost_model : out;
end view boost_model_interface_view;
end package boost_rtl_entity_interface_pkg;
This allows us to use only one signal of a record type with a view to connect to an entity
u_boost_model : entity work.boost_model
generic map(boost_model_parameters => init_parameters, initial_voltage => 150.0)
port map(
clock => system_clocks.core_clock ,
boost_model_bus => boost_model_bus,
-- bus_to_boost_model => bus_from_communications , vhdl2008 style
-- bus_from_boost_model => bus_from_boost_model , vhdl2008 style
rtl_current => rtl_current ,
rtl_voltage => rtl_voltage ,
program_ready => processor_ready);
The greater implications of the use of interfaces come from being able to use mode views with procedures and functinos. This allows using same overloaded subroutines for records and entities, which makes code refactoring substantially easier. I will expand on this once I start to further refactor the tube amp code.
hvhdl project on GitHub has the required fixed and floating point math libraries and microcode processor libraries so we will refactor the old control code to use them. The hVHDL libraries come with VUnit tests hence the code is easier to refactor to use the existing tested libraries than to simulate the functionality with the implementations that are present in this repository.
Since the system is relatively complicated, a HIL simulation will be created to test overall control and trip functionality with target control hardware. The VHDL HIL simulation models are verified by comparing the HIL simulation results with same simulations run using QSPICE. QSPICE allows us to write the control and modulation code in C++ which are compiled to DLL and run inside the spice simulation.The HiL simulation will be done using the hVHDL microcode processor libraries in order to run the simulation in floating point. There are various versions of the control hardware available so we will at least run it using Spartan 7 and Cyclone 10 LP.
The HiL simulation is implemented in floating point and calculations are run using microprogramming. The design of the microprogram processor is documented in a series of blog posts about processor and its software design in VHDL
The C++ sources for QSPICE model verification requires CMake and the .dll needs to be generated with 32bit platform. Example using Visual Studio compiler
cmake -G "Visual Studio 17 2022" -DCMAKE_GENERATOR_PLATFORM=Win32 ..
the project can be built then using
cmake --build .
how to run build
- mkdir build
- cd build
- cmake -G "Visual Studio 17 2022" -DCMAKE_GENERATOR_PLATFORM=Win32 ..
- cmake --build .
after running cmake --build . all dll will be built and copied to the folders where the qspice simulations hence the simulations can be run with either the included plot_.py or directly using qspice ide.
The QSPICE simulations can be found in hil_simulation/qspice_ref_models/
The rtl simulation results can be using open source NVC simulator. This can be installed with
winget install NickGasson.NVC
NVC needs to be run in MSYS2 environment. To run vunit with NVC in MSYS2, three environmental variables need to be set, PATH for python which has vunit installed, VUNIT_NVC_PATH to the NVC/bin folder and VUNIT_SIMULATOR to tell vunit to use NVC
example script is provided for the authors machine with the msys2_script.sh found in the root of this repository.
The models are done individually and the combined model can be found in the guitar_power_supply