Skip to content

PZCOREBUS Protocol Specification

Jump to bottom
Taichi Ishitani edited this page Feb 17, 2023 · 14 revisions

PZCOREBUS Protocol Specification

Overview

PZOREBUS is a bus protocol designed for use in a SoC design to connect master and slave components. PZCOREBUS has following features:

  • supports both of high-performance memory access and registrer access
  • uses burst based transactions
  • supports issuing multiple outstanding accesses
  • supports out-of-order transaction completion
  • supports read data interleaving

Architecture

Channels

PZCOREBUS is burst-based and defines three independent channels.

  • mcmd channel
    • transmits a set of request information such as command type, address, length, etc
  • mdata channel
    • transmits write data
  • sresp channel
    • transmits read data response and acknowledgement response

Profile

PZCOREBUS defines three profiles according to usage.

  • PZCOREBUS_MEMORY_H
  • PZCOREBUS_MEMORY_C
  • PZCOREBUS_CSR

PZCOREBUS_MEMORY_H

This profile is for high-performance memory access and has following features.

  • supprots multi-burst access
  • supports narrow access
  • supports read data interleaving
  • supports data bus width conversion

PZCOREBUS_MEMORY_L

This profile is limitaed version of PZCOREBUS_MEMORY_H profile. For simplification, Following limitations are introduced.

  • not supports narrow access
  • not supports read data interleaving
  • not supports data bus width conversion

PZCOREBUS_CSR

This profile is for register access. Following limitations are introduced for simplification.

  • supports single burst access only
  • transmits write data via mcmd channel
    • not uses mdata channel
  • not supports byte eanble
  • supports following commands only
    • PZCOREBUS_READ
    • PZCOREBUS_WRITE
    • PZCOREBUS_WRITE_NON_POSTED
    • PZCOREBUS_BROADCAST

Interface Descriptions

Handshake Process

All three channels use the valid/accept handshake process to transfer information attached to each channels. The source component drives the valid signal high to indicate when information being transfered is active. The destination component the accept signal high to indicate that it can accept the information. Information transfer is completed only when valid and accept signals are high. When the source component asserts the valid high, it must keep the valid signal and the related information stable until a handshake process is completed.

In addition, to prevent a deadlock situation, there are dependencies between valid and ready signals:

  • the source component must not wait for the ready signal to be asserted high before asserting the valid signal high
  • the destination component can wait for the valid signal to be asserted high before asserting the ready signal high
Clone this wiki locally