ANAndrey_Filippov·Apr 1, 2016
Yes, I'm guilty in DRY violation and I mentioned it in the post - I still manually translate Verilog to Python when go from simulation/debugging to hardware testing/debugging. And we are looking to use a more productive way to do this - write the simulation code (that replaces the CPU activity of the real hardware) in the programming language (Python) rather than switching to System Verilog that is somewhat in between the hardware description language and a software programming one. That is in our future plans, not there yet.
Other than that - DRY is always in our agenda, and there is only one place that holds the parameters/ preprocessor macros that define the hardware and its software interface. Python code reads Verilog files and extracts all the parameter names and values (names/types are automatically added to the Python source to al
Read the rest
low checking). That Python code allows to run tests on the target system, do some calibration and save results in the same Verilog parameters format (same as here https://github.com/Elphel/x393/blob/master/includes/x393_cur... , just no header). Same program uses Verilog data to export C files, it uses hand-crafted code to allow flexibility - it is not always possible to fit everything in the same format, but here the focus is again on the DRY - new code to do what is different, and use common code that processes multiple data items as much as possible. And when it is not - provide checks to catch differences when you do have to repeat yourself.
Only part of the Python code is a "translation" of the Verilog tests (and this we plan to eliminate in the future), the rest is just a continuation of the project, and when writing (not just running) that code I'm re-using data exported from the Verilog (and re-exported when there are changes that influence data). Same with C - code continues the project, re-using Verilog+Python data.