Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #4

Merged
merged 1 commit into from
Sep 6, 2023
Merged

Update README.md #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,10 @@

This repository is a collection of designs I have created and tested in complete systems using the RI5CY subset of the OBI (Open Bus Interface) memory bus. The standard is maintained by the OpenHW group, and its full definition can be found [here](https://github.com/openhwgroup/obi).

Because there are so many useful tools that do not support various features of SystemVerilog, the devices have been written in a basic subset of verilog and work with even the most restrictive open source tools. There is an included makefile to verify the compatibility of all modules against some popular open source tools.
Because there are so many useful tools that do not support various features of SystemVerilog, the devices have been written in a basic subset of verilog and work with even the most restrictive open source tools. The CI tests in this repository and the provided Makefile test the strictest compatability subset.

## OBI Subset Pins

I have opted for the minimal "RI5CY" implementation in all of the designs in this repository. The pins used in the interface are described briefly here. To get the full definition, these pins adhere to the specification set forth in the [OBI spec](https://github.com/openhwgroup/obi).

| Pin Name | Pin Count | Direction | Description |
Expand All @@ -23,7 +25,7 @@ I have opted for the minimal "RI5CY" implementation in all of the designs in thi

The MUXes connect multiple OBI master devices to a single slave device. These MUXes all support only a single outstanding read transaction, meaning that once a read has been accepted on one device, the MUX does not allow any new requests through until the read has been completed for at least one clock posedge.

The MUXes currently used fixed priority arbitration. This results in starvation of the lower priority masters if the higher priority master is in use. For some designs this is desireable, such as an instruction and data port on a single issue, pipelined CPU when yielding the data port to the instruction port might cause a deadlock. In situations like a multicore CPU, however, this is not a good solution.
The MUXes currently used fixed priority arbitration. This results in starvation of the lower priority masters if the higher priority master is in use. For some designs this is desirable, such as an instruction and data port on a single issue, pipelined CPU when yielding the data port to the instruction port might cause a deadlock. In situations like a multicore CPU, however, this is not a good solution.

The MUXes **do NOT** validate that the masters are requesting an address in the slave device's address range, it is assumed that the request is valid by the time it reaches the MUX.

Expand Down
Loading