open-source-silicon.dev

<@U016EM8L91B> In the new caravel version, the outputs from `mgmt_protect` to the `user_project_wrapper` seems to have an extra `buf_2` compared to the previous version
For example the `mgmt_protect.user_clock` output port was  driven by an `einvp_8` . Now it's driven by a `buf_2` (that in turn is driven by an `einvp_4` )
Is that ok? Is there a reason for that extra buffer? My doubt come up because I'm trying to do some STA tests on the whole chip including our user project area, and that extra buffer would translate in a less powerful driving cell for our inputs

Thanks for pointing this out.  Tristate buffers should _never_ be followed by regular buffers.  If so, it's a bad error.

<@U01HBEED5T8>:  FYI, there is a step that needs to be done in digital circuits to buffer outputs with a buffer of known drive strength;  this prevents various timing issues if the output drives a long line which may have a large capacitive load, especially if the same wire feeds back into the circuit somewhere.  BUT when that's done it should NEVER be done to a tristate buffer, since a tristate buffer followed by a normal buffer just completely undermines the function of the tristate buffer.  We have encountered that problem before and I am now very irritated at certain people. . . but thank you very much for discovering this, as I would not want to tape out the Caravel chip with that error in it (the error also occurs once in the gpio_control_block circuit).

I do recall a resizer issue a while back where this was fixed in OR

FWIW, CVC should detect a single tristate buffer output into an inverter.

<@U016EM8L91B> Just to clarify your previous comment, you're stating that a single tristate output should not be followed by an inverter, correct? Multiple tristates with a common output can be followed by inverters as long as one of the tristates is always on, right?

<@U017X0NM2E7>:  To a point, yes, or rather, a single tristate output should not be followed by any other gate at all.  Specifically, the problem is with tristates placed at the output of a module, where there isn't anything downstream, and there are tools in the synthesis flow that are adding circuit components on the periphery of the module.  Generally speaking, tristate circuits don't occur in the middle of a circuit because they're optimized out by synthesis (there are hand-designed exceptions, of course, and my own digital locked loop on Caravel is one).

Thanks for the explanation. I was thinking of the case where I've seen a tristate output into a NAND gate where other input to the NAND gate was also the input to the tristate clock. So when the tristate output was Hi-Z the NAND output would always be high with no leak.

Yes, that works, and I've done it myself, but it's not really best practice.  The problem comes when there are tools in the toolchain that manipulate the logic (for timing closure, for instance).  Depending on the situation, you may not always be guaranteed that the NAND is still there at the end of the toolchain.