diseño de IP: maestro y esclavo

Sí, creo que todos tus comentarios son correctos. Un maestro solicita datos (o envía datos) a los esclavos.

Un esclavo no puede originar una transacción de bus. Debe esperar hasta que el maestro se comunique con él. En un autobús con muchos esclavos, el maestro puede comunicarse con todos ellos, pero los esclavos no pueden comunicarse entre ellos.

Para muchos casos, esto está bien, ya que los esclavos ni siquiera saben de la existencia de otros esclavos. Cuando los esclavos tienen que comunicarse entre ellos, generalmente se implementa un sistema de buzón de correo donde un esclavo que desea comunicarse con otro esclavo lo indica al maestro. Pero no puede originar transacciones en el bus.

Un 'maestro' realiza solicitudes y un 'esclavo' responde a las solicitudes. Del mismo modo, un esclavo no puede realizar solicitudes y el maestro no puede responder a las solicitudes. El dispositivo maestro puede controlar (posiblemente compartido) el control (reloj, selección de chip, habilitación de lectura, habilitación de escritura, habilitación de bloqueo de dirección, etc.) y líneas de dirección. Por lo general, tanto el maestro como el esclavo pueden manejar datos (maestro para escrituras, esclavo para lecturas). Para algunas interfaces, es posible que un dispositivo implemente las funciones 'maestra' y 'esclava'; en este caso, los dispositivos esclavos pueden realizar solicitudes al asumir la función de maestro de bus. Y para algunas interfaces, es posible tener varios maestros en el bus con algún tipo de arbitraje. Los buses como PCI y PCI Express admiten esta funcionalidad para permitir el acceso directo a la memoria.