search

KLMTestBench / KLMTestBenchStatus

Tracking the Status of the KLM Test Bench at Hawaii
0 stars 0 forks source link

Programming TargetX and FPGA registers is confusing #12

Open cketter opened 5 years ago

cketter commented 5 years ago

The current method for programming registers is far too confusing. We build hex packets send them to the FPGA using python. Reading register numbers in hex and converting them to decimal in your head takes too much time, and then there is no knowledge of what the least-significant bits do without digging into the firmware source code. A cleaner methodology of programming registers is needed.

image

I already wrote a piece of code sometime ago which is a good start in the right direction. It is a function called KLMprint and lives in the cmd_lib.py library. The function decodes the target device and converts the least-significant bits to binary and to decimal them prints it all to the terminal.

image

We could expand on this. A python register map would be a good start.

Any thoughts?

RPeschke commented 5 years ago

There are two issue with the current code. The First one is that there is too much magic (magic numbers) going on. The second one is that it is completely imperative coding style. So the ideal would be to be more on the declarative side.

Step one Identify which variables belong to the configuration and which do belong to the generic communication with the device. For example "ASIC" is most likely a variable which belongs to the configuration. Also in the set win start I guess one of these numbers has something to do with configuring a start window. The parameter for the start window can go in the configuration data structure. The same goes for disable trigger mode. What you want is to have a function “set_trigger_mode” which get from the config data structure a disabled flag.

Every variable that somehow belongs to the generic asic control should go in its own generic asic control data struct. For example “AE000100” looks like a Delimiter.

Class genericASIC_parameter{ Delimiter =”AE000100”; … };

After this you can start with restructuring the control flow. The idea is to hide the imperative programming style as far away as possible. So for example you can create a function like:

Def set_asic_number(genericASIC_parameterl , conf.asicNumber)

And in this function you store all the magic.

If you do this for all the commands, the program already gets a lot more readable.

The next step is then to make the function memberfunction of a class which also contains the genericASIC_parameter class.

I am sorry I am a bit short on time. If you have more question, please let me know