Giter Club home page Giter Club logo

axi-crossbar's Introduction

AMBA AXI Crossbar

GitHub license Github Actions GitHub issues GitHub stars GitHub forks

Overview

An AXI4 crossbar implemented in SystemVerilog to build the foundation of a SOC.

A crossbar is a circuit connecting multiple master and slave agents, mapped across a memory space. The core consists of a collection of switches, routing the master requests to the slaves and driving back completions to the agents. A crossbar is a common piece of logic to connect in a SOC the processor(s) with the peripherals like memories, IOs, co-processors...

    ┌─────────────┬───┬──────────────────────────┬───┬─────────────┐
    │             │ S │                          │ S │             │
    │             └───┘                          └───┘             │
    │ ┌───────────────────────────┐  ┌───────────────────────────┐ │
    │ │      Slave Interface      │  │      Slave Interface      │ │
    │ └───────────────────────────┘  └───────────────────────────┘ │
    │               │                              │               │
    │               ▼                              ▼               │
    │ ┌──────────────────────────────────────────────────────────┐ │
    │ │                         Crossbar                         │ │
    │ └──────────────────────────────────────────────────────────┘ │
    │               │                              │               │
    │               ▼                              ▼               │
    │ ┌───────────────────────────┐  ┌───────────────────────────┐ │
    │ │     Master Interface      │  │     Master Interface      │ │
    │ └───────────────────────────┘  └───────────────────────────┘ │
    │             ┌───┐                          ┌───┐             │
    │             │ M │                          │ M │             │
    └─────────────┴───┴──────────────────────────┴───┴─────────────┘

Features

  • 4x4 master/slave interfaces
  • Master/slave buffering capability, configurable per interface
    • Outstanding request number and payload configurable
    • Seamless support of AXI4 vs AXI4-lite
  • CDC support in master & slave interface, to convert an agent clock domain from/to the fabric clock domain
  • Round-robin arbitration
    • Non-blocking arbitration between requesters, with fait-share granting
    • Priority configurable per master interface, up to 4 different levels, for request and completion stages
  • AXI or AXI4-Lite mode:
    • LITE mode: route all signals described in AXI4-lite specification
    • FULL mode: route all signals described by AXI4 specification
    • The selected mode applies to the global infrastructure
  • Routing table can be defined to restrict slaves access
    • Easily create enclosed and secured memory map
    • Dedicate sensitive slaves only to trusted master agents
  • USER signal support
    • Configurable for each channel (AW, AR, W, B, R)
    • Common to all master/slave interfaces if activated

Implementation Details

  • Interfaces share the same address / data / ID width
    • Address width configurable, any width
    • Data width configurable, any width
    • ID width configurable, any width
  • Advanced clock/reset network
    • Support both asynchronous and synchronous reset policies
    • Can handle clock domain crossing if needed, the core being fueled by its own clock domain
  • Route read/write requests by address decoding. All slave agents are mapped into the memory space across a start/end address range.
  • Route read & write completion by ID decoding. All master agents have an ID mask used to identified the route to drive back a completion
  • Configurable routing across the infrastructure
    • A master can be restricted to a memory map subset
    • An access to a forbidden area is completed by a DECERR
  • Switching logic IO interfaces can be pipelined to achieve timing closure easier
  • Don't garantee completion ordering when a master targets multiple slaves with the same AXI ID (!). A master should use different IDs and reorder the completion by itself

Further details can be found in:

Verification environment

The core is verified with a testbench relying on pseudo-random driver and monitor to inject some traffic and verify its correctness. Please refer to the dedicated chapter for futher details and find hints to integrate the core in your own development. The flow relies on:

Development plan

Core features:

  • Full AXI ordering support: put in place multiple queues per ID and manage reordering to master interfaces
  • Read-only or write-only master to save gate count
  • Address translation service to connect multiple systems together
  • Timeout support in switching logic
  • Debug interface to steam out events like 4KB crossing or timeout
  • New Checkers:
    • Check address overlap (start+end vs next slave start address)
    • ID overlap: mask ID + OR number supported up to next slave ID

Wizard:

  • Number of master and slave agents configurable
  • RTL generator

AXI Goodies:

  • Interface datapath width conversion
  • AXI4-to-AXI4-lite converter
    • split AXI4 to multiple AXI4-lite requests
    • gather AXI4-lite completion into a single AXI completion
  • 4KB boundary crossing checking, supported by a splitting mechanism

Simulation:

  • Support Verilator
  • Error injection in the core and tesbench
  • Implement statistics in testbench to track misrouting, address distribution, master granting, ...

License

This IP core is licensed under MIT license. It grants nearly all rights to use, modify and distribute these sources.

However, consider to contribute and provide updates to this core if you add feature and fix, would be greatly appreciated :)

axi-crossbar's People

Contributors

dpretet avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

axi-crossbar's Issues

Feature: Provide a RTL generator

In order to widely support feature #12 easily, a basic RTL generator must be developed to drop the top level code. It must generate the top level with any number of slave and master interface, and drop the switch stage with the correct parameter specifying the number of agents.

Feature: Support Early Write Response

To improve overall system performance, an AXI intermediate component can issue a write response before the request reaches the destination. From AMBA AXI specification:

Response before the endpoint
To improve system performance, it is possible for an intermediate component to issue a response to some transactions. This action is known as an early response. The intermediate component issuing an early response must ensure that visibility and ordering guarantees are met.

Early write response
For Bufferable write transactions, an intermediate component can send an early write response for transactions that have no downstream observers. If the intermediate component sends an early write response, the intermediate component can store a local copy of the data, but must propagate the transaction downstream, before discarding that data.
An intermediate component must observe ID ordering rules, that means a write response can only be sent if all earlier writes with the same ID have already had a response.

After sending an early write response, the component must be responsible for ordering and observability of that transaction until the write has been propagated downstream and a write response is received. During the period between sending the early write response and receiving a response from downstream, the component must ensure that:
• If an early write response was given for a Normal transaction, all subsequent transactions to the same or overlapping Memory locations are ordered after the write that has had an early response.
• If an early write response was given for a Device transaction, then all subsequent transactions to the same Peripheral region are ordered after the write that has had an early response.

When giving an early write response for a Device Bufferable transaction, the intermediate component is expected to propagate the write transaction without dependency on other transactions. The intermediate component cannot wait for another read or write to arrive before propagating a previous Device write.

A possible implementation could be to forward the write request to the switch stages from the slave interface, but keep internally a FIFO to forward back-to-back the early response to the master agent. Must take in account the ordering rules, if the same ID could be used among several slaves, and also the nature of the destination described by ACACHE.

Must be study and defined carefully.

Feature: Timeout Events Handling

Timeout detection and management can be enabled and configured by interface.
This avoids any deadlock if a slave doesn't respond to a request, or if a
master doesn't accept a completion.

The timeout management is done on slave interface (connected to a master agent)
and on master interface (connected on a slave agent). The timeout circuits run in
the clock domain of the switching logic, not on the master pr slave agent clock. So the
timeout counters never require any CDC stages.

The timers could be implemented in different manners:

  • With a shared counter implement millisecond or microsecond time reference,
    configurable based on the platform clock speed, spreading all the master and slave interface.
    Then all the master / slave interfaces would also implement a (small) local counter to measure
    timeout. This solution allows a compact implementation but is not very precise.
  • With a (wide) local counter in each master/slave interface. This solution will be very precise but require
    more area.

Time out events may occur on slave interface (connected to a master agent)
and on master interface (connected on a slave agent). Timeout events can occur
only inside the core (on switching logic) and/or with slave agents. The interconnect
will always accept new request if internal buffer are not full.

Timeout events can occur:

  • between slave interface and master interface for address/data channels (internal)
  • between master interface and slave interface for write completion channel (internal)
  • between master interface and slave interface for read data channel (internal)
  • between master interface interface and a slave agent for address/data channels (external)
  • between slave agent and a master interface for write completion channel (external)
  • between slave agent and a master interface for read data channel (external)

A timeout event must:

  • be marked with SLVERR in completion channel
  • drives a request / completion interface to free it

The core's behavior ensures the agents can continue to operate, but can't ensure
the whole system will still be operational. The user needs to correctly manage
these situations by communicating with a defecting slave or master and reboot it.

It would be suitable the axe-interconnect core implements a debug interface to stream
such event and inform the SOC's root master. In critical issue, the root master may reboot
the system.

duplicated identifier defined

in rtl/axicb_round_robin_core.sv:
line 114 and line 176, There are two defines of REQ_8
compiler will give error on this

AXI-4 Lite transfer fail (Master write)

The testbench could work on previous code (when not swap the name of mst_ and slv_ )
when I check the result on latest code
Master read function is correct, but it will fail when master write
From waveform. I can see o_wch is 0 in module: axicb_mst_switch, even i_wch have data
it's due to wch_empty signal is always 0

Remove base address in master interfaces

Till now, the master interfaces ADDR signal still transmit the absolute address (SLVx_START_ADDR + targeted address). Now the base address is removed by default, but it can be kept by setting up the SLVx_KEEP_BASE_ADDR parameter > 0.

compile error using xcelium

xmvlog: *E,DLYSYN (./rtl/axicb_round_robin.sv,90|17): Event control illegal within an always_latch construct.
module worklib.axicb_round_robin:sv
errors: 1, warnings: 6

need to remove (*) after always_latch

Manage request targeting unspecified address mapping

Today, if a master agent tries to access a memory map not assigned to a slave agent, the core will stall and goes to deadlock. The slave switches needs to decode address and handle this scenario to return a completion with DECERR status. This request can't be driven to a slave to avoid any memory corruption, but needs to be released (handshake necessary with the requester to empty eventual internal buffer).

Feature: Read-only or write-only interfaces

In order to save area, a master or slave interface could be write-only or read-only. If all the masters agents are write-only or read-only, the switches and masters interfaces can be generated as write-only or read-only.

Feature: Debug interface

In order to help debugging and tracing, the core could embed a queue, fed by the master and the slave interfaces, to stream out some events like:

  • 4 KB boundary crossing if uses AXI4 protocol
  • request / completion timeout
  • xRESP with value equals to EXOKAY if uses AXI4-lite protocol
  • xRESP with value equals to SLV_ERR
  • xRESP with value equals to DEC_ERR

The debug stage must have an input to connect each interface, with a FIFO to store the events, and routing stage to stream the event for instance with an AXI4-stream interface.

The debug could be actionable per interface.

A message / event format must be specified

Feature: Support any number of slave / master interfaces

Today, the core supports 4 slave and 4 master interfaces. The arbiter has been designed to support up to 8 agents. The top level could be rewritten to support any number of interfaces, and a top level per different configuration (TBD).

multi master transfer discussion

I have a scene when connecting 2 masters and 1 slave to crossbar, I need to config MST1_ID_MASK = h'00 and MST2_ID_MASK = h'10, and I see you judge the reture rch to which master based on IDs,so master 1 can only use ID: 0~15 and master 2 can only use 16 to 31.
but based on my understanding, each master can specify different IDs and several masters can using same ID, is this correct?

Feature: Implement AXI completion queue per ID to ensure ordering rules

The core currently doesn't support correctly AMBA completion ordering rules if a master issues multiples outstanding requests with the same ID among different slaves.

To address the limitation, an axicb_slv_switch must embed multiple FIFOs (queues) to store incoming read/write completions and a FIFO to store the AID order transmitted to the slaves, used to follow the correct order when emptying the queues and serving the completions.

In order to save area, this new feature should be deactivatable if a system doesn't need this strong ordering. In some situation, solution may be to use a different ID or ID mask per slave and manage the ordering inside the master issuing the request.

For AXI4 read completion, the completion queues should store RLAST along RDATA to detect the end of packet and switch to the next completion routing. This will consume 1 bit along each data, but another solution could be to store ARLEN along ARID and use a counter to track the completion until the last data phase.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.