simoneruffini / norm Goto Github PK

fsm_nv_reg_TB presents a strange behavior for task_value_tb = 38. This can be seen in the graphs at page 45.
Maybe this is regular and just a glitch in how the policy reacts to the voltage trace or it is a warning for some bug in the fsm or how values are acquired by the script.

Write a tcl script that will be able to generate the whole vivado project.

For this task this are candidate tcl script:

• write_proj_tcl: to generate source references, see this link
• write_ip_tcl [get_ips]: to generate ip scripts, see Tcl Command Reference
• write_xdc: to link/generate xdc file, see link above

The name of the script will be generate_proj_tcl.tcl

States: vol_cntr1_cmpt_s, vol_cntr2_cmplt_s, vol_cntr3_cmnplt_s that skip the fetching from v_reg when the task is complete

Use NVMEF_FPGA (non volatile memory emulation for fpga) as the Vivado project name.

In theory this can be done by setting the name in the generation script (see #3 ) and then delete and rebuild the vivado folder.

The code misses in code documentation.

The project contains 3 packages:
1)COMMON_PACKAGE.vhd for global and project common constants and functions
2)NVME_FRAMEWORK_PACKAGE.vhd for NVMEF specific constants
3)TEST_ARCHITECTURE_PACKAGE.vhdfor test architecture specific constants

Unfortunately the variables stored in these packages do not respect their definition, either because the distinction of this layers is not black or white or because some package includes caused recursive behaviour.

A different approach for constant and project values storing should be discussed, ex:

• just a file and different packages
• just a package
• refactor some entities so that the separation of these packages can be effective

rename vol_cntr instances (vhd,wfcg...) to vol_arc

This issue is directly linked to #3 .
Explenation:
After the Vivado project is exported as a tcl script it will be possible to autogenerate it after a git clone. What is missing, instead, is the ability to make changes to the local project and then reflect them onto the tcl script so others can use it too.

A method for doing that should be implemented, maybe it is just recompiling the script for code generation.

Write fsm_nv_reg task backup and test it

Change all Xiliinx IPs with opensource version of them

The volatile counter power approximator triggers improperly during runtime (only for fsmn_nv_reg_DB policy). This causes miscalculation of the power approximation visible in the report.

The bug is caused by the fact that:
1)vol_cntr1_pa_val triggers when fsm_nv_reg_state = do_operation_s
2) When the machine is in hazard state (voltage trace level below hazard threshold level) a data save is performed. But after that the machine goes back to do_operation_s even if the system is still in hazard.

Possible solution
Add an additional state to fsm_nv_reg_DB that precedes do_operation_s and that is in charge to check the voltage level against defined thresholds. This state will then direct the fsm to the right operation and will be the sink for all of them after completion.