With reference to the following parameter to be used in the TSN time aware shaping (802.1 Qbv), the provided granularity does not seem to be good enough. For example, if I have 3.2ns (10G MAC with 32b datapath), I can represent the value using tenths of nanoseconds as 32, which is an integer: so, no problem. However, I can have a period which is 2.56ns (64b datapath, 25G MAC), which using tenths of nanoseconds will come to 25.6 and thus I can only represent 25 in the TickGranularity but not 25.6 ns , thus losing 0.6ns of granularity which is vital over the gating schedule of a few seconds. Please correct me if my interpretation is wrong.
To make it future proof, I prefer the following. This helps me to solve the practical problems we might face while implementing the TSN in 25G MAC or future TSN MACs at higher throughputs.
TickGranulariyScale: Integer representing the scale of the granularity (ones, tenths, hundredths, thousandths etc)
TickGranularity: Value represented by the above scale
Let us take the following practical case: The idea is to arrive at the schedule where each gate is a common multiple of all the ports' ticks. Otherwise, the gate timing is not counted correctly in all the MAC ports, leaving some remainder leading to the drift in the gate timing on absolute timescale. If the application cannot read the MAC tick with a proper resolution, schedule calcuation will have considerable precision error.
Consider 3 ports: 1G (MAC1 tick: 8ns), 10G (MAC2 tick: 3.2ns) & 25G (MAC3 tick: 2.56 ns)
Through one-tenths resolution, the 'TickGranularity' specifies 80, 32 & 25 (cannot specify 25.6 in one-tenths. So, I lose the precision of 0.6) in one-tenths resolution. The application will configure the gate schedule with common multiple of (80, 32, 25): 800ns as the basic unit.
Through one-hundreth resolution (with suggested register ' TickGranularityScale'), we can specifiy 800, 320, 256. Now, the application will configure the gate schedule with common multiple of (800, 320, 256): 6400ns as the basic unit, which is more approriate as the gate counting is an integer multiple of MAC ticks.
It is quite possible that the same 25G MAC may have different ticks such as 2.56ns (64b) or 5.12ns (128b) depedning on the datapath widths. Also, some MACs such as 40G/100G may have 3 decimal MAC ticks depending on the datapath widths. If the schedules' internal gate timers need to work in proper synchronization with the MAC ticks (because there is no 1ns tick, which is why we have TickGranularity in the first place as explained in the Note of the clause 126.96.36.199.16), specifying the granularity along with its scale will make the original intent time-proof i.e., we donot need to change anything any time.
I hope that our practical need of the additional regiter ' TickGranularityScale' is justified.