Separate common time from a data-link rate
A shared time base lets network participants refer to events using a common notion of time. TI's CPSW architecture guide describes gPTP distributing time and correcting local clocks. The central subject is the relationship between those clocks. It differs from the rate at which an Ethernet link carries data or the interface connecting a PHY to a MAC.
The guide distinguishes time-transmitting, time-receiving and relay roles. Those roles describe how a device participates in the time-distribution arrangement. A clock can need correction because its local progression differs from the shared reference. The account therefore includes continuing clock alignment rather than treating synchronization as merely attaching a time label to a received message.
This also separates shared time from wake-event detection. Detecting particular traffic and notifying a controller answers whether a qualifying event occurred. Distributing a common clock answers how participants relate their local time references. Both can appear in an Ethernet system while remaining different functions. Naming them separately makes a requirement for coordinated time understandable before considering how queued traffic will use that reference. Thus the first distinction concerns the reference shared between participants, while the later traffic mechanisms describe service at individual queues. Keeping that order makes their separate responsibilities easier to follow.
Locate timestamp capture in the MAC path
A frame timestamp needs a defined event reference. TI describes hardware capture when a timing-event frame is transmitted or received in the MAC path. The timestamp refers to that event, rather than the later instant at which application code observes the information. These are different locations in the event chain even though software ultimately consumes the captured value.
The guide's transmission description pairs packet metadata with the hardware event timestamp. Software can then associate the saved timestamp with the relevant message. In the described two-step arrangement, a synchronization frame leaves first and a later follow-up communicates the captured transmission time. The later communication does not change which earlier event the timestamp describes.
This explains the architectural distinction without assigning an achieved synchronization error. A timestamp captured at transmission and a software observation made afterwards answer different timing questions. Knowing where the value originates is therefore part of understanding the time-distribution mechanism. It also differs from allocating an MCU timer's input-capture channels: this account concerns network-message events in the documented MAC path and their role in communicating a common time reference.
Distinguish queue scheduling from clock synchronization
Clock synchronization does not by itself decide which traffic class may transmit. TI describes Enhancements for Scheduled Traffic as opening and closing traffic-class gates according to a repeating schedule anchored to the time base. The clock supplies the reference for interpreting the schedule, while the gate state controls the service opportunity for the relevant queue.
These are complementary responsibilities. A common notion of time makes schedule instants comparable across participants. The schedule separately describes when a traffic class is permitted to receive service. Knowing that clocks are aligned does not identify the gate pattern; knowing that a gate repeats does not explain whether its time reference is shared with the other participants.
The guide ties the schedule to the gPTP domain, which makes that dependency explicit. It should remain part of a functional description of scheduled traffic rather than being shortened to a general fast-Ethernet claim. Link speed describes a different attribute. The architecture explains how time and queue permission relate, while a specific transmission schedule and a customer's resulting delay remain separate implementation and assessment subjects.
Separate preemption and credit shaping from schedule gates
Frame preemption and credit shaping describe further traffic-service functions. TI's introductory Interspersing Express Traffic prose describes an express frame interrupting a lower-priority preemptable transmission, with the interrupted transmission resumed afterwards. This concerns how transmission can be interrupted and continued. It is different from a gate schedule deciding whether a traffic class currently has permission to transmit.
Credit-based shaping instead governs service through a credit mechanism associated with bandwidth. The relevant distinction is credit-governed eligibility rather than a shared-clock correction or a repeating gate opening. A traffic description can therefore need separate statements about scheduling, interruption and shaping, even when the mechanisms are discussed within one Ethernet architecture guide.
Retaining these separate functions makes the architecture comparison precise. Shared time relates clocks; hardware capture identifies event time; gates organize scheduled queue opportunities; preemption changes interruption behavior; and credit shaping governs another aspect of service. The guide introduces these mechanisms together without making them synonyms. Their explanation does not assign an exact feature set to an orderable device or establish an actual network's interoperability or latency result.
Sources and further reading
TI CPSW TSN Architecture Guide, bounded saved gPTP/MAC-event and EST/IET/CBS introductory prose. This is an architectural explanation without current-standard compliance, exact-SKU feature inclusion, detailed credit-state rules, APIs, schedule values, latency or interoperability guarantees.