[Libre-soc-dev] Unexpected clock connexions.
Jean-Paul.Chaput at lip6.fr
Thu Jun 3 14:33:30 BST 2021
Ha. You may have got a wrong impression about clock tree & H-Tree due
to a trick I used to cut corners.
Previously, H-Tree where automatically created for nets flagged as "clock"
and only for them, creating a wrong sense of association between those
two properties. And, to cut corners, I did declare signals like "reset"
as clocks so that an H-Tree would be built for them.
Now, I did the right thing and H-Tree are no longer related to being
a clock. You can build an H-Tree on any nets.
Nest thing to consider, is the degree of synchronicity (skew) required
for a signal, for low skew, H-Tree is mandatory.
So we have the following choices :
* Signal with huge number of sinks more or less evenly spread over
the whole surface with low skew. Typically clock.
==> Use H-Tree
* Signal with huge number of sinks, widespread.
==> H-Tree or HFNS (implicit)
* Signal with medium / high number of sinks
==> HFNS (implicit).
If you don't use a H-Tree, any nets with more than 20 sinks will be
have a HFNS synthetized (High-Fanout Net Synthesis) which is a kind
of buffered tree, but with the positions of the nodes left free,
so no warranty on the skew or optimal clustering (will improve that
in the future).
So for the non-clock signals, we could do whatever we want.
For the clock signals, do I read correctly that some components with
run at *external* clock speed (DEBUG & DMI) ? I would like to have
the Staf's advice about that. If it is really needed, we may need
for the tool's sake, make two input clocks (even if they are connected
to the same external signal).
On Thu, 2021-06-03 at 13:47 +0100, Luke Kenneth Casson Leighton wrote:
> * debug DMI and JTAG need to run at PLL clock but use *GLOBAL EXTERNAL
> * all parts of TestIssuerInternal EXCEPT debug and DMI need to run at PLL
> clock and
> have a RESET that is *DRIVEN BY debug DMI* (which, in turn, is driven by
> * TestIssuer is combinatorial and simply contains PLL and
> the reason why Debug / JTAG drives the TestIssuerInternal RESET signal
> be obvious / clear: the processor and all components needs to be resettable
> therefore, i imagine, it is not sys_rst that must be an H-Tree, it is the
> Debug DMI
> reset_output signal that must be an H-Tree.
> summary again:
> * TestIssuer runs at sys_clk, receives sys_rst
> - sends sys_clk to PLL, receives coresync_clk_o
> - sends coresync_clk_o to TestIssuerInternal
> - sends sys_rst to TestIssuerInternal
> * TestIssuerInternal receives sys_rst and coresync_clk_o
> - sends coresync_clk_o to ALL components
> - sends sys_rst to JTAG and Debug/DMI
> - RECEIVES reset_output from Debug / DMI
> - SENDS reset_output to all components (SRAM, Core)
> Jean-Paul: is this practical?
> if not, then i will *DISABLE* DMI/JTAG reset - which will be a damn
> nuisance - the only
> way to reset the processor will be a hard external sys_rst line.
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
.-. J e a n - P a u l C h a p u t / Administrateur Systeme
/v\ Jean-Paul.Chaput at lip6.fr
/(___)\ work: (33) 01.44.27.53.99
^^ ^^ cell: 06.66.25.35.55 home: 09.65.29.83.38
U P M C Universite Pierre & Marie Curie
L I P 6 Laboratoire d'Informatique de Paris VI
S o C System On Chip
More information about the Libre-soc-dev