On 7/16/2020 3:09 PM, Vladimir Oltean wrote:
> On Fri, Jul 17, 2020 at 12:49:27AM +0300, Vladimir Oltean wrote:
>> On Thu, Jul 16, 2020 at 02:36:45PM -0700, Jacob Keller wrote:
>>>
>>>
>>> On 7/16/2020 2:20 PM, Vladimir Oltean wrote:
>>>> There are external event timestampers (PHCs with support for
>>>> PTP_EXTTS_REQUEST) that timestamp both event edges.
>>>>
>>>> When those edges are very close (such as in the case of a short pulse),
>>>> there is a chance that the collected timestamp might be of the rising,
>>>> or of the falling edge, we never know.
>>>>
>>>> There are also PHCs capable of generating periodic output with a
>>>> configurable duty cycle. This is good news, because we can space the
>>>> rising and falling edge out enough in time, that the risks to overrun
>>>> the 1-entry timestamp FIFO of the extts PHC are lower (example: the
>>>> perout PHC can be configured for a period of 1 second, and an "on" time
>>>> of 0.5 seconds, resulting in a duty cycle of 50%).
>>>>
>>>> A flag is introduced for signaling that an on time is present in the
>>>> perout request structure, for preserving compatibility. Logically
>>>> speaking, the duty cycle cannot exceed 100% and the PTP core checks for
>>>> this.
>>>
>>> I was thinking whether it made sense to support over 50% since in theory
>>> you could change start time and the duty cycle to specify the shifted
>>> wave over? but I guess it doesn't really make much of a difference to
>>> support all the way up to 100%.
>>>
>>
>> Only if you also support polarity, and we don't support polarity. It's
>> always high first, then low.
>>
>
> Sorry for the imprecise statement.
> If you look at things from the perspective of the signal itself, the
> statement is correct.
> If you look at them from the perspective of the imaginary grid drawn by
> the integer multiples of the period, in the PHC's time (a digital
> counter), the correct statement would be that "it's always rising edge
> first, then falling edge". And then the phase is just the delta between
> these 2 points of reference.
>
> Let me annotate this:
>
> t_on
> <------>
> t_period
> <--------->
> phase
> <->
>> +------+ +------+ +------+ +------+ +------+ +------+ +------+
>> | | | | | | | | | | | | | |
>> --+ +--+ +--+ +--+ +--+ +--+ +--+ +
>>
>> +---------+---------+---------+---------+---------+---------+--------->
> t=1000 t=1010 t=1020 t=1030 t=1040 t=1050 t=1060
>> period=10 time
>> phase=2
>> on = 7
>>
>> There's no other way to obtain this signal which has a duty cycle > 50%
>> by specifying a duty cycle < 50%.
>>
>
> Thanks,
> -Vladimir
>
Right this makes sense now, thanks for the detailed explanation!
Regards,
Jake
