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

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

[ARTIQ] [RFC] remove RTIOCollision

[Sébastien Bourdeauducq via ARTIQ]

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

Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq