rajesh-s

Delving into the why's of AXI

**Note: In all below, slave can also mean interconnect

• Do we really need back-pressure?
  • Yes, you absolutely need backpressure. What happens when two masters want to access the same slave? One has to be blocked for some period of time. Some slaves may only be able to handle a limited number of concurrent operations and take some time to produce a result. As such, backpressure is required.
  • B and R channel backpressure is required in the case of contention towards the master. If a master makes burst read requests against two different slaves, one of them is gonna have to wait.
    • Shouldn't a master be prepared to receive the responses for any requests it issues from the moment it makes the request? Aside from the clock crossing issue someone else brought up, and the interconnect issue at the heart of the use of IDs, why should an AXI master ever stall R or B channels?
• The master should be prepared, but it only has one R and one B input, so it can't re

erincandescent

Foreward

This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.

It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.

Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2

Original Foreword: Some Opinion

The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and

shapr

[alias]
	# Checkout a pull request branch on an upstream project. It
	# handles PRs that get rebased as well.
	#
	# git pr 3
	pr = "!f() { git checkout master; git branch -D pr/$1 || true; git fetch origin refs/pull/$1/head:pr/$1 && git checkout pr/$1; }; f"

	dpr = "!f() { git checkout develop; git branch -D pr/$1 || true; git fetch upstream refs/pull/$1/head:pr/$1 && git checkout pr/$1; }; f"

	pur = "!f() { git checkout master; git branch -D pr/$1 || true; git fetch upstream refs/pull/$1/head:pr/$1 && git checkout pr/$1; }; f"

HexiDave

using System;
using System.Collections.Generic;
using ProtoBuf;
using UnityEngine;
using UWE;

// Token: 0x02000202 RID: 514
[ProtoContract]
public sealed class CrafterLogic : MonoBehaviour, IProtoEventListener
{

robey

desires

• 16 registers -- 8 might be sufficient with rotating registers
• 24-bit addressing = 16MW memory max
• all code addresses relative (PIC)
• memory protection table: readable, writable, executable
• no "status" register: flags that can be set by comparisons, and used for conditions, and which are pushed during a call
• rotating register space and spill, instead of a stack
• real register space of (64?) registers treated as a ring