Re: [ARTIQ] [RFC] remove RTIOCollision

[Robert Jördens via ARTIQ]

On Wed, Mar 15, 2017 at 1:07 PM, Sébastien Bourdeauducq via ARTIQ
 wrote:
> Hi,
>
> RTIOCollision is a bit tedious to implement with DRTIO, since the master
> does not know if a given channel should do replace or collision. The
> satellite would need to report this information for each of its channels
> (and this also needs to be passed from the gateware scripts to the satellite
> manager firmware), then the master should program it into its gateware. Do
> we strongly need it, or can we simply have the replace behavior at all
> times? According to this mailing list discussion, the replace behavior is
> actually wanted:
> https://ssl.serverraum.org/lists-archive/artiq/2016-November/001052.html

Even on the same (data) address, many channels are not idempotent (the
DDS, SAWG, any SPI devices). More generally any channel where state is
kept can be non-idempotent. I don't see how we can track that at the
master.
Why not do blind submission and do the replacement at the satellite
side plus asynchronous error reporting like RTIOBusy?

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

Re: [ARTIQ] [RFC] remove RTIOCollision

[Slichter, Daniel H. (Fed) via ARTIQ]

> Why not do blind submission and do the replacement at the satellite side
> plus asynchronous error reporting like RTIOBusy?

As long as the satellite is able to handle things appropriately for the type of 
channel it is, I am OK with this.  If it's a TTL you should do replace (as is 
currently used and is convenient for zero-length pulses etc.), if it's not you 
throw an RTIOBusy error which is reported asynchronously.  

Best,
Daniel
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq