Skip to content

[DOC] Usb compound ip architecure doc - #14

Open
ugomari-nxp wants to merge 17 commits into
chipsalliance:mainfrom
ugomari-nxp:usb_compund_ip_architecure_doc
Open

[DOC] Usb compound ip architecure doc#14
ugomari-nxp wants to merge 17 commits into
chipsalliance:mainfrom
ugomari-nxp:usb_compund_ip_architecure_doc

Conversation

@ugomari-nxp

Copy link
Copy Markdown
Collaborator

USB Two-Port Compound Device IP architectural document

@linux-foundation-easycla

Copy link
Copy Markdown

CLA Not Signed


The following diagram provides a detailed view of the USB compound device architecture, including its functional partitioning, internal connectivity, and main interfaces.

![USB Two-Port Compound Device Block Diagram](USB_uArch_Detailed_Block_Diagram.svg)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ugomari-nxp : can we please break down the picture to a top level flow, followed by one click down of each stage. Currently its unreadable and doesn't present well


### Interface Overview

The JANUS top-level exposes interfaces for:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to remove all references to Janus since this is a public doc


- system clock, reset, and power-management coordination;
- connection to an external USB 2.0 PHY through UTMI or ULPI;
- independent AHB control of the embedded Hub, DEV0, and DEV1;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should correct AHB references because we are going to have only AXI at the top of this block.

category. Input groups are shown on the left side of the IP boundary, while
output and mixed-direction interface groups are shown on the right side.

images/janus_top_level_interface.png

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. some picture is missing and 2) we shld remove any janus references

| USB PHY | UTMI and ULPI | Connects the shared USB PIE to an external USB 2.0 PHY. |
| Host control | Hub, DEV0, and DEV1 AHB register-control interfaces | Allows an external system master to configure and monitor the three USB functions. |
| External memory access | Hub Descriptor RAM and DEV0/DEV1 Endpoint RAM AHB interfaces | Allows an external system master to initialize, inspect, and update the USB memories. |
| Native memory | Hub Descriptor RAM and DEV0/DEV1 Endpoint RAM native interfaces | Connects JANUS to the three external RAM macros or memory models. |

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be good to remove hub descriptor RAM references since we are making this update anyways, and spec can reflect the design even before design is done

- AHB slave front-ends and AHB-to-memory adapters are reset by
`ahbs_resetn`.
- USB functional logic in the system-side clock domain is reset by
`hresetn`.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clayton8 when we do the AXI and create the top level wrapper around this logic, we need a better name to standout than hreset; may be something like usb_reset_n or something of that nature that shows this is a whole module reset

to remain active while clock shutdown or wake-up handling is still in
progress.

#### Vendor-Specific UTMI Register Access

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we define what vendor-specific UTMI register access means?


---

## Host-Control AHB Interfaces

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clayton8 - this section needs an overhaul once we have AXI because AHB is not going to be publicly visible. If there are any specifical properties that SRAMs need to carry, like byte addressing we probably need to ensure that the AXI2AHB bridge supports that. Not sure if there is any other place where we support byte addressing. It might actually be easier and safer to make FW do RMW and do any byte stuff as a future enhancement if the AXI2AHB doesnt support it. Most last min bugs come from this type of logic.


The common behavior is:

- byte-addressed AHB transfers;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clayton8 here is the reference to the statement. We probably need to check if AXI2AHB supports it and need to fix this. I dont think we support byte addressing anywhere today and this might not be the time we want to start adding this support, this late

The common behavior is:

- byte-addressed AHB transfers;
- byte, half-word, and word access support;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as above @clayton8

@calebofearth calebofearth changed the title [DOC] Usb compund ip architecure doc [DOC] Usb compound ip architecure doc Sep 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants