On Thu, Nov 24, 2016 at 2:55 AM, Sébastien Bourdeauducq <[email protected]> wrote:
> Well there is nothing unmanageable there.

Sure. Unmanageable it is not.

> * If we keep your "reset address CSR on timestamp modification" feature,
> those writes that always have address zero (e.g. set TTL level) can use a
> different syscall that ignores the address and saves the associated CPU
> overhead.

Yes. The downsides are maintainability, readability and code size.

> * In DRTIO packets, the address field can be transmitted in a handful of
> nanoseconds.

But another -- let's say -- 16 bits fixed length address field is a
significant overhead in DMA and DRTIO for small packets.

> * For replacements in DRTIO, we can just do it on the remote side. The
> inefficiency of sending multiple packets is fine as the throughput will be
> limited by the CPU anyway. For DMA, we can optimize the sequences in advance
> to remove internal replacements.

How do you want to do the replacement?
Optimizing the sequence in advance in CPU/runtime would be
channel-dependent and mode-dependent special casing.
Doing so in gateware before it enters the DMA buffer would require
gateware there that depends on channel features on remote DRTIO
devices.

What one could do is add another bit that marks an event as
replaceable. Then the gateware could be agnostic.

> * The remote side also has a synchronous FIFO which is easier to handle than
> the asynchronous FIFO of local RTIO.

--
Robert Jördens.
_______________________________________________
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Reply via email to