lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
_florent_ has quit [Read error: Connection reset by peer]
<sb0> rjo, without SYNC_CLK syncing I don't think there's much of a choice
<sb0> the PTW can be computed after the shifting, if that helps
<rjo> sb0: i was trying to imagine how subsequent experiments could differe in the worst case if (for some reason) the measured syncclk phases are different and thus the fud shifts are different.
<rjo> the skew should be constant after each reset. so there is no point in measuring before each experiment. then the shifts can be known at compiletime and cheaply integrated there.
<rjo> it depends quite a bit on the phase setting/tracking mode. john gaebler wanted to write something on that...
<rjo> but with runtime-shifts at least the timing violations can be avoided. and it will not be worse than the current implementation.
<rjo> bah. nasty stuff. local rtio fpgas for every ~4 dds would be the way to go.
<sb0> yeah, and no more large (and unreliable, as I have noticed) cables...
<sb0> what about running under 2.5GHz so that sync works properly?
<GitHub127> [artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/UcIRlg
<GitHub127> artiq/master 29cd340 Robert Jordens: taaccs slides: fix spelling, get rid of lab_hardware.jpg
sj_mackenzie has joined #m-labs
wpwrak has quit [Ping timeout: 245 seconds]
wpwrak has joined #m-labs
nengel has quit [Remote host closed the connection]
nengel has joined #m-labs
<rjo> sb0: yep. need to do the convincing that the synchronization scheme from the datasheet (which is not that trivial afaict) is the way to go.
<sb0> rjo, according to ADI tech support you can actually sync them even at 3.5GHz (with "extreme difficulty")?
<rjo> the reply that raghu got? i don't know whether i would want to explore that parameter range given their own apparent uncertainty ;)
<rjo> once they put something in the datasheet or someone shows me that it can be done, maybe.
<rjo> did they mention the timing that would be hypothetically required to do it?
<sb0> no, it's all very vague. the monster-FPGA can do output delays with ~40ps resolution, so if we use it to send the resets we have a lot of control - but this assumes low jitter, etc.
<sb0> also, it cannot take the 3.5GHz clock so we'd need some prescaler circuit that can also introduce jitter or some unknown delay
<sb0> the monster-FPGA can be programmed to retry the reset for each DDS with different timing until all the clocks are aligned, though
<sb0> some sort of automatic calibration mechanism like for DDR3...
<rjo> sounds more like DDR5 or 6.
<rjo> by the way. another thing that came to mind regarding plls:
<rjo> ah no forget it. i figured it out while writing the post.
MY123 has joined #m-labs
sb0_ has joined #m-labs
sb0_ has quit [Quit: Leaving]
xiangfu has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
sj_mackenzie has quit [Remote host closed the connection]
_florent_ has joined #m-labs
xiangfu_ has joined #m-labs
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu_ has joined #m-labs
kristianpaul has quit [Ping timeout: 245 seconds]
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
xiangfu has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
clever_ is now known as clever
xiangfu has joined #m-labs
xiangfu_ has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu_ has joined #m-labs
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu_ has joined #m-labs
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu_ has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu has quit [Remote host closed the connection]
xiangfu has joined #m-labs
xiangfu_ has joined #m-labs
xiangfu_ has quit [Read error: Connection reset by peer]
xiangfu has quit [Read error: Connection reset by peer]
FabM has quit [Quit: ChatZilla 0.9.91 [Iceweasel 31.1.0/20140903072827]]
14WAAHOK0 has joined #m-labs
77CAAQP4Q has joined #m-labs
14WAAHOK0 has quit [Remote host closed the connection]
77CAAQP4Q has quit [Ping timeout: 260 seconds]
xiangfu has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu has quit [Read error: Connection reset by peer]
xiangfu has joined #m-labs
xiangfu_ has joined #m-labs
xiangfu_ has quit [Remote host closed the connection]
xiangfu has quit [Remote host closed the connection]
xiangfu has joined #m-labs
_florent_ has quit [Quit: Leaving]
xiangfu_ has joined #m-labs
xiangfu_ has quit [Remote host closed the connection]
xiangfu has quit [Remote host closed the connection]
<GitHub137> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/z-v9Xw
<GitHub137> artiq/master b12fd1d Sebastien Bourdeauducq: transforms/remove_dead_code: bugfixes
<GitHub137> artiq/master 7806ca3 Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/ARTIQ
<GitHub0> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/1ITKcw
<GitHub0> artiq/master 217fe82 Sebastien Bourdeauducq: coredevice/core: optimize further
<GitHub0> artiq/master cf7848c Sebastien Bourdeauducq: transforms/inline: rewrite
<ysionneau> sb0 what can you read on the sdram chip on your papilio pro board? MT48LC4M16A2?
<ysionneau> on the ppro schematic they say "MT48LC64M4A2" ( http://papilio.cc/uploads/Papilio/sdram-schematic.png ) ...
<ysionneau> on the schematic they connected A[12:0] but in reality the chip on the board has only A[11:0] pins
<ysionneau> and in the mibuild file we indeed have 13 pins for the sdram.a
<ysionneau> I guess we should fix that to only put the 12 pins
* ysionneau trying to find out which one to remove
<larsc> cut the green wire
<ysionneau> by looking at the schematic it seems the P34 in sdram.a in papilio_pro.py from mibuild is useless
<ysionneau> let's try to synthesize without this extra pin :p
<ysionneau> and see if cutting the green wire triggers the bomb or not =)
<ysionneau> indeed it still works even without P34
mumptai has joined #m-labs
mumptai has quit [Ping timeout: 244 seconds]
mumptai has joined #m-labs
MY123 has quit [Quit: Connection closed for inactivity]
<rjo> ysionneau: i have c4m16 on my boards. when i went through the number of required address lines vs memory size it made sense to me...
<ysionneau> C4M16 only has 12 address lines
<ysionneau> on the ppro schematic (and ppro mibuild platform file) there are 13 address lines
<ysionneau> I guess the mistake comes from the schematic
<rjo> ysionneau: maybe a catch-all for different hardware versions (other sdrams) of the ppro?
<ysionneau> maybe there are several hw version out there, dunno :x
<ysionneau> anyway, does not matter that much as it's the top bit
mumptai has quit [Ping timeout: 260 seconds]