Re-generating `RndCnst` for each build

[msfschaffner]

Similarly to the OTP images, we recently enabled re-generation of random netlist constants for the life cycle state and top-level RndCnst parameters.

For the latter, we ran into CI issues, since in-tree modifications made in the build phase do not persist into the run phase on all platforms, since the two phases can be scheduled as separate jobs. As explained in #16699, software tests relying on scrambled ROM images fail because the ROM scrambling step executed in the run phase through bazel is using the wrong RndCnst for the scrambling key.

In the short term, rerunning top-gen in the run phase with the correct build_seed would be a workaround to enable this flow. Long term, we should add a mechanism to pass the build_seed into the ROM generation step in bazel, similarly to how OTP images are generated.

[msfschaffner]

@sriyerg @timothytrippel @tjaychen @weicaiyang @cindychip

[moidx]

@vogelpi should this be part of the RndCnst efforts? Moving to M2.5. Please move to Backlog if it makes sense. Thanks.

[cdgori]

It's fairly important to have a way to test this re-generation over a number of iterations, in case there is some issue, so I wouldn't suggest backlog here.

[timothytrippel]

After discussion with @msfschaffner

• [x] the build seed is now available in the dvsim run stage via the envar build_seed; so that part is solved
• [ ] passing the ROM scrambling key material into the ROM generation step in bazel still needs to be done; I will work on that and we can then turn on RndCnst regeneration in the nightlies

[cdgori]

I don't know what everyone would consider an appropriate number of nightlies to exercise this seeding/regeneration process to be, but something like a ~month's worth feels correct to me.

[timothytrippel]

Moving this to M2.5.2 as we discussed.

[msfschaffner]

Moving into the next milestone since we did not have time for doing this. We do however run regressions on the closed source side with regenerated constants - so this is covered to some extend (although not in the public facing nightlies).

[vogelpi]

@moidx has impact on manufacturing testing to align scrambling config.

[vogelpi]

@moidx and I discussed that enabling this in CI is most likely going to trash the buildsystem caching. Thus, it would be better to setup a weekly test run for this or so.

[rswarbrick]

Could we do it more simply, by checking in a "base" build constant and then adding the week number to it on the fly? That would avoid having to do a "weekly bump".

[andreaskurth]

By @moidx: Problem is understood. Only applicable to DV flow. Integrating it will be painful. Given the timeline we'll probably not be able to address this before closed source. Recommendation is to put into backlog and address any closed source issues if and when they come up. @timothytrippel and I can help with this.

By @vogelpi: Agreed.