On Fri, Oct 17, 2014 at 9:34 PM, Sébastien Bourdeauducq wrote:
> Speaking of RTIO input errors, Joe proposed that excessively short
> transitions should be reported (the RTIO core can only report one event
> per system clock cycle - 8ns on the KC705). They may happen e.g. due to
> excessive ringin
> Speaking of RTIO input errors, Joe proposed that excessively short transitions
> should be reported (the RTIO core can only report one event per system
> clock cycle - 8ns on the KC705). They may happen e.g. due to excessive
> ringing in cables. I see two ways of reporting them:
> 1) throwing an
On 10/17/2014 11:12 PM, Slichter, Daniel H. wrote:
>> > The FIFO can also be disabled when the RTIO input is in gateware counter
>> > mode (and no overflow exceptions will be raised in this mode).
> Sounds good.
Speaking of RTIO input errors, Joe proposed that excessively short
transitions should
> 1 MHz does not sound like an unreasonable performance target for software
> and RTIO/processor communication optimizations. And we can have the
> large block RAM FIFO as you said, as a plan B that is easy to roll out.
If you think this is doable, then please go ahead with the further
optimizati
On 10/17/2014 07:50 AM, Slichter, Daniel H. wrote:
> For your experiments 1 and 2 the count rate is ~1 MHz and so the
> processor will probably not be able to read all the events out of the
> queue as fast as they come in.
1 MHz does not sound like an unreasonable performance target for
software a
On 10/17/2014 12:56 AM, Gaebler, John wrote:
> Often our output patterns are repeated many times so I was wondering
> if there is a way to do branching and looping through the 64 entry
> deep output channel memories so that we can repeat patterns without
> reloading them into memory.
I'd rather tr
>Everyone, Please see attached for several experiments that I expect will place
>the greatest demands on the timing resolution of the RTIO. -Joe
None of the foregoing discussion has anything to do with the timing resolution
of the RTIO core. It timestamps all events with a resolution of ~1 ns,
On 10/16/2014 11:12 PM, Slichter, Daniel H. wrote:
> For inputs, what is the deepest FIFO one could make given the
> resources on the Kintex7? Could one do a 65k FIFO?
Yes, with 64-bit timestamps (a pessimistic estimate) that would make a
~4Mbit memory. The FPGA on KC705 has ~16Mbit of block RAM
Hi,
> If we go the DMA route, maybe a good option is to have DRAM backing of
> the RTIO FIFOs that is implemented all in gateware and is fully transparent
> for
> the software. Then we can have FIFOs with hundreds of megabytes of
> storage (note that loading/unloading them will take some time). B
Hi,
On 10/15/2014 11:34 PM, Slichter, Daniel H. wrote:
> I agree with Robert that DMA would be the most sensible next step
> here, rather than trying other tweaks. I don't really know how
> difficult this would be to implement, though.
Implementing DMA in the SoC is not necessarily very difficu
> > Should I make it a priority to optimize this (the CPU/RTIO
> > communication via CSR looks like a good suspect), or is it going to be
> > enough for the near future?
>
> Good enough IMHO. My guess would be that the sum of tweaks like CSR
> data width will at most yield a factor of 3-5, probabl
On 10/15/2014 12:35 AM, Sébastien Bourdeauducq wrote:
> I've done some quick testing on the sustained performance that the
> system has when pushing RTIO switch commands with some minimal
> processing between them (increase the time and manage the loop).
> It tured out that a new switch command can
12 matches
Mail list logo
