> Turiu galvoj, kuriu galu sistemini CLK signala kisti tiesiai i I2C magistrales CLK signala ir po to galvoti, kaip sita reikala
> multipleksuoti...

   "Sudėtingumą" tikriausiai galima motyvuoti štai kuo.
   Kai svetimas clock ateina tiesiai į trigerį, kuris apdoroja svetimus
duomenis, tai turime minimalų neapibrėžtumą, didžiausią galimą greitį,
energijos taupymą ("fully static operation"). Slave-only realizacija _be_
_sisteminio_clocko_ gautųsi visai elegantiška.
   O sisteminis clockas neišvengiamas, jei norim master režimo. Generuojant
clock output, šis turės būti vienu iš baigtinio automato išėjimų. Sisteminio
kombinavimas su tais išėjimais ir neleidžiamas architektūros, ir apsunkina
hold laiko kontrolę. Vadinasi, kiekviena automato būsena skaidoma į dvi
fazes: pirmoje paruošiami duomenys, iki antros jie nusistovi, antros
atsiradimo momentas (neišvengiamai vėluoja sisteminio clocko atžvilgiu)
yra clock output frontas, o duomenys lieka stabilūs iki kitos pirmos fazės.
Vienžo, master-only atrodo irgi gražiai.

   Bet kai slave'ui privalome naudoti sisteminį clock, tada tasai svetimas
gali tapti nebent vienu iš baigtinio automato įėjimų. Vadinasi, reaguojama
nebe į jo frontą, o lygį sisteminio clock fronto metu -- jis faktiškai
tampa "enable" tipo signalu. Pamirškim apie visus setup/hold, kuriuos
užtikrino masteris, frontai gi nebesutampa. Įmanomas nebent "fronto
detektavimas" sisteminio clocko raiška: jei dažnis pakankamai aukštesnis,
gal ir sugaudysi juos laiku.
   Manau, Tomas D. turėjo omeny tą patį :)

-- 
  saimhe