<sb0>
okay, phys_opt_design seems to deal with the kasli timing issues
<sb0>
need to test it more to confirm though...
<sb0>
the post-route one may be enough and also doesn't disrupt a design that has met timing, so, we can just enable it globally on migen without breaking other boards or incurring synthesis time penalties
<sb0>
hmm I wonder if that would also deal with those pesky tPWS violations with Ultrascale SERDES-TTLs...
rohitksingh has quit [Quit: Leaving.]
<rjo>
sb0: XilinxVivadoToolchina.with_phys_opt? IIRC that didn't help when i tried it and slowed down things a lot.
<sb0>
rjo, that does the post-place one
<sb0>
and indeed it is slow and doesn't help
<sb0>
the post-route one is not so slow and improves timing significantly
<sb0>
they have the same command, but it does two different things ...
<sb0>
now it fails timing in the analyzer sometimes
<sb0>
this seems to do it: place_design, route_design, place_design -post_place_opt, route_design, phys_opt_design
<sb0>
but it's slow
<sb0>
let me see if a pre-route post_place_opt is enough
rohitksingh has joined #m-labs
<rjo>
sb0: ok.
<sb0>
hmm nix
<rjo>
sb0: i am not getting the PW violations (without sawg)
<sb0>
rjo, did you enable the serdes-ttls?
rohitksingh has quit [Quit: Leaving.]
<sb0>
who's using top_utilization_hierarchical_place.rpt, top_utilization_place.rpt, top_io.rpt, top_control_sets.rpt, top_clock_utilization.rpt and what for?
<rjo>
ah. probably not. i thought there was one on one of the smas.
<rjo>
i have used io and clock utilization.
<sb0>
no, it's disabled because it breaks timing. you need to go back some commits
<sb0>
I've asked (politely) xilinx tech support about how to do that with their MMCM and new [redacted] BUFGCE_DIV, because I don't see any way
<sb0>
other than having another clock domain for just those SERDES plus a CDC... it really looks like the transceivers now, with a lot of complicated and useless clock domains
<sb0>
that other clock domain, of course, would require messing with those BUFGCE_DIV async control signals to get deterministic phase... sigh
rohitksingh_work has joined #m-labs
<sb0>
_florent_, how is serwb coming along?
marmelada has joined #m-labs
<sb0>
meh, with phys_opt_design timing is still very fragile
<marmelada>
rjo, can I use dma and return some data with it?
<marmelada>
I'm trying to reach 1,5MSPS in sampler
<marmelada>
and at this point, without dma I can only do around 280 kSPS
sb000 has joined #m-labs
<sb000>
no, dma only supports outputs
<sb000>
inputs can be done, but it is not developed, planned or funded
<marmelada>
does it mean that, at this point, 1,5MSPS is impossible with artiq?
hartytp has joined #m-labs
<hartytp>
marmelada: basically, yes
<hartytp>
:(
<hartytp>
artiq is very slow in lots of ways
<marmelada>
:(
<hartytp>
that's really my one big complaint about it as a user
<hartytp>
to a certain extent it's a result of how flexible artiq is
<hartytp>
but a lot of it is due to lack of optimization
<marmelada>
hartytp: using your (I believe) driver i got around 280 kSPS
<hartytp>
at every level (both how artiq is built on top of misoc and how the misoc cores are implemented such as the sdram core not doing burst reads)
<hartytp>
the Sampler driver is rjo's
<marmelada>
ok
<hartytp>
if you want to read a small number of samples, you can increase the ififo depth
<hartytp>
and then do a burst read (lots of bus.write calls back-to-back and then do the reads later)
<hartytp>
but, you're not going to take huge number of samples like that
<hartytp>
that's why I'll do all the testing I'm planning about 200kSPs or less
<sb000>
hartytp, it would be helpful to get a list if what exactly is slow, with priority rankings
<sb000>
*of
<sb000>
no optimization is free and you probably know how much of a struggle it is to get anything to work at all
<rjo>
hartytp: be careful with implying that burst sdram reads would be significant improvement. that is not certain at all.
sb000 has quit [Ping timeout: 260 seconds]
<rjo>
marmelada: the coredevice driver for sampler and the RTIO infrastructure was explicitly **not** intended to achieve high sustained high event rates. bursts work just fine and easily max out the SPI bus.
key2 has joined #m-labs
<rjo>
s/high sustained/high sustained input/
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
rjo, I guess he's talking about the long reads for DMA
<sb0>
as for regular SDRAM bursts (length 8) we are already doing them
<marmelada>
rjo, sb0 is right
<rjo>
"the sdram core not doing burst reads"
<marmelada>
that was hartytp
<rjo>
for RTIO DMA input those would be sdram core writes
<rjo>
marmelada: yes. i replied to him.
<hartytp>
rjo: the sdram comment was not connected
<hartytp>
to this particular issue
<hartytp>
it's something that came up in DRTIO debugging.
<hartytp>
point is just that there are a lot of things in the stack that don't aren't optimized
<rjo>
hartytp: you cited it as a lack of optimization and reason for slowness
<hartytp>
yes, generally, but not this particular one
<rjo>
hartytp: optimiziation using "sdram burst reads"?
<rjo>
hartytp: you seemed to suggest that "sdram burst reads" are missing and an example for lack of optimization. i'm just noting that optimizations in the sdram controller might not have particularly high benefit/cost.
<hartytp>
hmmm...correct me if I'm wrong, but this came up when we looked at DMA on Kasli with the analyzer enabled. that ram access is just not really fast enough. AFAICT, using burst mode would help there
<hartytp>
anyway, I'm not totally up to speed on this, so maybe I'm wrong
<marmelada>
hartytp: bp adapters came and we only have your kasli in our lab
<rjo>
but that's not "sdram burst reads", it would be wishbone/axi bursts
<marmelada>
would it be okay for us to desolder power jack and insert bp connector instead?
<hartytp>
I guess the point is that the current speed issues surrounding ARTIQ are a problem for us in various ways, and do need to be fixed at some point
<hartytp>
marmelada: yes, please do that (I plan to do it if you don't!)
hartytp has quit [Quit: Page closed]
<rjo>
hartytp: absolutely. let's go and get money and manpower for it.
<sb0>
we don't have tCK=2.5ns. are the other settings correct?
<sb0>
we have tCK=2ns...
<sb0>
and for this CL/CWL we should have tCK between 1.875 and 2.5ns according to the sdram datasheet. so, we are within specs, and we can lower the system frequency a bit so that the sluggish xilinx stuff is happier
<sb0>
conversely, we can crank up the frequency a little on kc705
<sb0>
and sayma, though things always go wrong on sayma so we probably should not do that
<sb0>
the mmcm has this nice fractional multiply feature, so it should be easy to change all frequencies at once
<rjo>
sb0: have you given up on those timing paths on kasli? maybe actually throwing away the unused features in mor1kx would help. i only disabled the interrupt lines. i have not checked whether that also drops the corresponding SPR/IRQ mgmt stuff out of the hot paths.
<sb0>
there are also some intermittent timing failures in the analyzer, depending on vivado settings
<sb0>
whitequark, are we using the l.ffl1 instruction?
<sb0>
rjo, there is FEATURE_PIC, that should drop it
<_florent_>
sb0: on my design i was using a7ddrphy with tCK = 2.5ns
<_florent_>
sb0: i haven't done the port to artiq
<_florent_>
sb0: do you really need to run your cpu at 125Mhz on Kasli?
<sb0>
whitequark, those instructions appear in the firmware but I don't see why they are useful. can we get rid of them? their gateware implementation contributes to the timing failures on kasli
<sb0>
rjo, main_opticlock_rtio_clk_1 in more then one group at line 693 of file /home/sb/artiq_drtio/artiq_kasli/opticlock/gateware/top.xdc
<sb0>
sometimes, optimizations are not happy about this
<sb0>
hm, that was another one... on sys_clk
<rjo>
sb0: i had seen it as well but couldn't think of a way to easily avoid that. i think it arises from rtio_clk being either derived (indirectly) from sys_clk or from si5324.
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.2/20180316222652]]
marmelada has quit [Quit: Page closed]
rohitksingh has quit [Quit: Leaving.]
<GitHub-m-labs>
[artiq] dhslichter commented on pull request #969 a7dd3e7: @sbourdeauducq @hartytp we have some DACs that we use without LDAC (it's tied low on the board). We like having this option because then you free a TTL line for other uses. https://github.com/m-labs/artiq/pull/969#discussion_r177824018
<GitHub-m-labs>
[artiq] klickverbot commented on issue #891: I wouldn't ditch interrupts as we need them to implement a sampling profiler, something which both @whitequark and me have been wanting to do for quite some time. https://github.com/m-labs/artiq/issues/891#issuecomment-376968901
<sb0>
should we move bug-free sayma support to 5.0? i see this and su-servo holding 4.0...
<sb0>
though, maybe adding grabber support to 4.0 is a good idea
<GitHub-m-labs>
[artiq] klickverbot commented on issue #891: Sure, meeting timing is obviously more important; read my statement as "I'd really rather we found a way to keep timer interrupts".... https://github.com/m-labs/artiq/issues/891#issuecomment-376979718