Какова цель метода makeSink в создании операций ввода-вывода для периферии

Question

Я следовал за некоторыми примерами добавления периферии к ракетному чипу.Я использовал sifive-блоки в качестве ссылки.

ниже приведен пример из их примера I2C (я надеюсь, что это можно опубликовать здесь)

case object PeripheryI2CKey extends Field[Seq[I2CParams]]

trait HasPeripheryI2C { this: BaseSubsystem =>
  val i2cNodes =  p(PeripheryI2CKey).map { ps =>
    I2C.attach(I2CAttachParams(ps, pbus, ibus.fromAsync)).ioNode.makeSink()
  }
}

trait HasPeripheryI2CBundle {
  val i2c: Seq[I2CPort]
}

trait HasPeripheryI2CModuleImp extends LazyModuleImp with HasPeripheryI2CBundle {
  val outer: HasPeripheryI2C
  val i2c  = outer.i2cNodes.zipWithIndex.map  { case(n,i) => n.makeIO()(ValName(s"i2c_$i")) }
}

Я понимаю шаг makeIO, который предпринятьпакет и применить IO к нему, но не понимаю шаг makeSink.Почему они делают этот шаг, недостаточно makeIO?

Answer 1

Я не эксперт в дипломатии ракетных чипов, но, взглянув на код, я думаю, makeIO и makeSink делают принципиально разные вещи.

makeIO принимает BundleBridgeSourceи материализует порты в реализации модуля Chisel для управления этим источником.На BundleBrigeSink есть такой же метод.Я полагаю, что этот метод - способ, которым вы берете любую сторону моста Bundle и взаимодействуете с ним в фактической долотной части генератора (в отличие от дипломатической части).

makeSink превращается BundleBridgeSourceв BundleBridgeSink.Он не материализует порты долот и остается в мире дипломатии, а не в мире долот.

В приведенном вами примере из I2C обратите внимание на то, как часть с makeSink является особенностью, которую нужно смешивать вчто-то, что расширяет BaseSubsystem, это дипломатично.С другой стороны, HasPeripheryI2CModuleImp, который имеет makeIO, расширяет LazyModuleImp, который является частью долота.Один из способов думать об этом - два разных «взгляда» на одно и то же.Долото и Дипломатия используют разные предметы, таким образом i2cNodes (дипломатический) против i2c (Долото).