From nobody Wed May 8 06:36:53 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VZ56D6wnwz5KRb2 for ; Wed, 08 May 2024 06:37:08 +0000 (UTC) (envelope-from john@sanren.ac.za) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VZ56D53ptz4gjc for ; Wed, 8 May 2024 06:37:08 +0000 (UTC) (envelope-from john@sanren.ac.za) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-2b433dd2566so2865924a91.2 for ; Tue, 07 May 2024 23:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sanren-ac-za.20230601.gappssmtp.com; s=20230601; t=1715150226; x=1715755026; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=e5wwxomo9diVvQllS93KtqgRTmsgU+YZOSEg5yWGBMM=; b=coR+rKKbYvDy4Pe2c8tDSqDXRIDidSxLaVUmOpnea6MxrcB4wiH+P4JzYyGYltMCCO G++cWLWHX5pSlHB7ElfP0n+0p7DJr2YVmZ4JHt0rlDA2Z+WCsAI/sv6OLONtdEwRQS5k x2J4UtC9/1M5GpOywllEHJ3E6E6N81FD+iRMloyaQ5k1ck9NQp4usfKFe+0ZW/5gcDmq 1kHoN+rXls1aZfjZy44v9FcvS5XEryWmvYq2vOVpNjUuYh6KmHuKo729dfXNEzH2D6jf x0cFVC4xxZw08sCm1L39tnwnxGepRSdyxKpusLg743dcsfHBpXE7c8mXcNWIvBusVcKV bavQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715150226; x=1715755026; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=e5wwxomo9diVvQllS93KtqgRTmsgU+YZOSEg5yWGBMM=; b=dPybc8xmQqF9kMWdYsxvg9YwwHW7NAWdTGi0M8j7pV47ibjtNaMB4MktJRFg4vhskU eD/cyZ9jWe4cKV5Jz1zYYvUHe+5s1yDGDpmwgLexpjkDURPyY19rxjB1qLa3zVt1B9MZ 1e1E8SzGRk/3yYkzPwOnSi2eYN98aP/sWUOa/dWiSSVMzboiTKyqzcR9jUWF24KrWtS7 I7ZuOcXX3myMIg7Q3Nl7NEpB/REs3wwTZb8P9dP3M7kaPdRVDSJ7WkTKaezg3akCmAj5 +muqn8jnupXlB+9t8FJ3nnRcg5IzGy4d9GmCzBlVKKSIvioFHYEor/S/2Z8uElC2Qq9b WRlw== X-Gm-Message-State: AOJu0YyiH3O6f3zsXMm8a+6xvm+ckQ6zQw8G0Q+68W8FLhR6Go8mQPnd u5fhjfmgastMC12oIa8+lqfVoV6XbRYm+mXHs4NJxJPiIAmZZ9iv76ymN//k0vgGCsfp2y2ZzxR qBYvT26349GFBuqmoZXqbkxp96WKGWEIex9aTheWn1XjpRKV0HkY= X-Google-Smtp-Source: AGHT+IEs/uE9TSjEdeoRqF+2/5U9+kmXhMEO0Hl5c4z42aFEGnRaa2ly1k7bX+O6mpeDz2qCEvtxHJUh/FaKHR3s81Q= X-Received: by 2002:a17:90a:c590:b0:2b2:9d08:80a1 with SMTP id 98e67ed59e1d1-2b6169d9452mr1667386a91.33.1715150225657; Tue, 07 May 2024 23:37:05 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <202405080535.4485ZFN9066673@critter.freebsd.dk> In-Reply-To: <202405080535.4485ZFN9066673@critter.freebsd.dk> From: John Hay Date: Wed, 8 May 2024 08:36:53 +0200 Message-ID: Subject: Re: FreeBSD driver for the OCP TAP Time Card To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000efee4d0617eb87d5" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4VZ56D53ptz4gjc --000000000000efee4d0617eb87d5 Content-Type: text/plain; charset="UTF-8" Hi Poul-Henning, On Wed, 8 May 2024 at 07:35, Poul-Henning Kamp wrote: > -------- > John Hay writes: > > > I have been working on a FreeBSD driver for the Open Compute Project > (OCP) > > Time Appliance Project (TAP) Time Card. The card consists of three main > > parts, a clock module, a GNSS module and a FPGA module. The firmware for > > the FPGA implements a counter that is synchronized to TAI using the GNSS > > module and the clock module. The counter is implemented as two 32-bit > > registers, seconds and nanoseconds, like struct timespec, and make that > > available on the pci-e bus. > > That is /precisely/ the kind of hardware timecounters were designed for :-) > True, it did make it a lot easier. :-) Working close to the nanosecond does seem to push things close to the limits though. :-) There are a few things I wish could be handled differently. Maybe there are ways, and I just did not find them. :-) One is that you cannot just feed timecounters with a timespec value. It assumes the hardware counter is in binary, while in this case, the nanoseconds rolls over at 1 second, so for every tc_get_timecount(), you have to multiply the seconds register value by 10^9 and then add the nanosecond register value. Not a big deal and reading the registers over the pci-e bus is the slowest part by far. The other is that the conversion from the above value to bintime and later back to what is used elsewhere, seems to lose a little precision. The comments in sys/kern/kern_tc.c also note that. In the pps code, I wished that one could provide a timestamp with pps_capture(). It uses the time at which it handled the interrupt. The card latch the counter values when the pps happens, so it knows the correct time. Currently I hack around it by twiddling sc->sc_pps_state.capcount directly. Regards John --000000000000efee4d0617eb87d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Poul-Henning,

On Wed, 8 May 2024 a= t 07:35, Poul-Henning Kamp <phk@ph= k.freebsd.dk> wrote:
--------
John Hay writes:

> I have been working on a FreeBSD driver for the Open Compute Project (= OCP)
> Time Appliance Project (TAP) Time Card. The card consists of three mai= n
> parts, a clock module, a GNSS module and a FPGA module. The firmware f= or
> the FPGA implements a counter that is synchronized to TAI using the GN= SS
> module and the clock module. The counter is implemented as two 32-bit<= br> > registers, seconds and nanoseconds, like struct timespec, and make tha= t
> available on the pci-e bus.

That is /precisely/ the kind of hardware timecounters were designed for :-)=

True, it did make it a lot easier. :-)= Working close to the nanosecond does seem to push things close to the limi= ts though. :-)

There are a few things I wish c= ould be handled differently. Maybe there are ways, and I just did not find = them. :-)

One is that you cannot just feed tim= ecounters with a timespec value. It assumes the hardware counter is in bina= ry, while in this case, the nanoseconds rolls over at 1 second, so for ever= y tc_get_timecount(), you have to multiply the seconds register value by 10= ^9 and then add the nanosecond register value. Not a big deal and reading t= he registers over the pci-e bus is the slowest part by far.
<= br>
The other is that the conversion from the above value to bint= ime and later back to what is used elsewhere, seems to lose a little precis= ion. The comments in sys/kern/kern_tc.c also note that.

=
In the pps code, I wished that one could provide a timestamp wit= h pps_capture(). It uses the time at which it handled the interrupt. The ca= rd latch the counter values when the pps happens, so it knows the correct t= ime. Currently I hack around it by twiddling sc->sc_pps_state.capcount d= irectly.

Regards

John
--000000000000efee4d0617eb87d5--