Review initial state of pi_ctl_cdr

[sgherbst]

Based on our discussion today, we want to make sure that there is not a start-up issue here (x's or values that prevent proper starting of clk_adc)

[sgherbst]

This is the code snippet showing how the PI code is set:

dragonphy2/vlog/new_chip_src/digital_core/digital_core.sv

Lines 163 to 171 in 2d280b9

	genvar j;
	generate
	for (j=0; j<Nout; j=j+1) begin
	assign scale_value[j] = (ddbg_intf_i.en_ext_max_sel_mux ? ddbg_intf_i.ext_max_sel_mux[j] : adbg_intf_i.max_sel_mux[j])<<4;
	assign unscaled_pi_ctl[j] = pi_ctl_cdr[j] + ddbg_intf_i.ext_pi_ctl_offset[j];
	assign scaled_pi_ctl[j] = unscaled_pi_ctl[j]*scale_value[j];
	assign int_pi_ctl_cdr[j] = scaled_pi_ctl[j] >> Npi;
	end
	endgenerate

Since en_ext_max_sel_mux currently defaults to 0, it relies on the analog core to have a reasonable value for max_sel_mux. The analog core, in turn, computes max_sel_mux from Qperi, which currently defaults to int_Qperi. Finally, int_Qperi is computed from combo logic on arb_out, which is all x's on startup.

At a minimum, I think we should change the default for en_ext_max_sel_mux to 1. But we might also consider solving through #62 (be able to set PI codes directly from the outside), and default to external codes on startup.

Last thing -- why does this currently work in simulation? The reason has to do with the way that Verilog simulators handle x's in conditional statements. Consider this code that computes int_Qperi:

dragonphy2/vlog/new_chip_src/analog_core/PI_local_encoder.sv

Lines 84 to 92 in 2d280b9

	always_comb begin
	for (int i=1; i<Nunit;i++) begin // thm to bin (it is not a regular thm)
	if (arb_out[i-1]&~arb_out[i]) begin
	int_Qperi = unsigned'(i);
	break;
	end
	else int_Qperi = Nunit-1;
	end
	end

When the boolean condition evalues to x, the simulator evaluates the the else condition, setting int_Qperi to Nunit-1. So x's are blocked at this point, resulting in a misleading sense of security...

[sgherbst]

I'll assign this @zamyers since it seems both solutions mentioned above involve updates to digital_core or its register defaults. But it would be good to get some feedback from @sjkim85 on this too.