[tlgen] Do not enforce a minimum region size

[msfschaffner]

This addresses #15182. I ran the chip_tl_errors test with 200 different seeds and did not see any failures.

Note that only the last two commits are relevant. Others will be rebased away.

Fix #15182 #14200

[msfschaffner]

@tjaychen @arnonsha @Jacob-Levy FYI.
With this set to 0 we get many errors in the chip_tl_errors test since the CSR node does not error back.

[arnonsha]

I see that all other modules indeed have devmode=1, which means they report errors when illegal transaction occurs. From security point of view, isn't this what we're looking for ? I don't see the value of devmode = 0, can you explain why when masked errors can/should be used ?

[Jacob-Levy]

@msfschaffner The value or .devmode_i ( 1'b0 ) was given by Google in the past for the AST... what changed?
Should the change apply to the close source as well?
The ast.sv is an A U T O - G E N E R A T E D C O D E !! file!

[eunchan]

Let me explain the history of devmode=0. The feature is not fully baked into OT design yet. But the intention is to not disclose which address space is unmapped or mapped but all 0 for security sensitive modules. So, for the security sensitive modules should have devmode tied to 0 regardless of LC states. Other peripheral should have devmode controlled by life cycle state. @tjaychen may comment more in detail.

[arnonsha]

Thanks @eunchan
This makes sense, however all modules that I can see are connected to 1'b1, including keymgr, kmac, lc and otbn.

[tjaychen]

this was indeed the original intent. However we decided (somewhere along the line) that debuggability trumps security, at least for this first generation.

So we have tied everyone to 1'b1 for now. In the future we may tie it back to 1'b0.

This whole thing though requires a higher level discussion, because there are a lot of architectural inconsistencies in how we include the process in the security envelope.

[arnonsha]

That makes sense for the 1st gen. Thanks @tjaychen

[Jacob-Levy]

@eunchan Thanks for explaining!
@msfschaffner is asking to set devmode=1 that is why I asked "what changed"..

[msfschaffner]

For reference, this has been discussed in these issues: #14063, #10311

[vogelpi]

Thanks for giving this a try @msfschaffner. Do you know if this has an impact on timing?

[tjaychen]

this looks good to me. I raised the question in the issue also, but do we expect a timing issue? Because it looks like you're still rounding up to the closest power of 2, so it's not going we're going to a bounds comparison right? it's still mostly address bits. Just fewer of them.

[msfschaffner]

Thanks for giving this a try @msfschaffner. Do you know if this has an impact on timing?

I haven't run this through ASIC synthesis, but as @tjaychen points out, the address routing is still done by masking off the relevant bits and does not require full comparisons.

[msfschaffner]

I have added an additional address alignment / overlap check that uses 0x1000 as before so that we can still enforce this at the system level (see last commit). The check does not alter any of the existing config, but just goes over the base addresses and throws an error if anything is amiss.

[weicaiyang]

LGTM