lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling has joined #m-labs
<sb0> already one small thing to hate about kintex7: the flash clock needs to be accessed using a special STARTUPE2 primitive that ise does not insert automatically when trying to use the pin as regular IO
<GitHub123> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/601nQA
<GitHub123> migen/master 7f4e512 Florent Kermarrec: kc705: add spiflash pins
fengling has quit [Quit: WeeChat 0.4.3]
fengling has joined #m-labs
<fengling> I have an JTAG Serial Cable run2, does it support i2c mode?
fengling_ has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<sb0> fengling_, the m1 jtag pod?
<sb0> it's just a ft2232h... you can probably configure it for i2c if the ftdi-chip supports it and you can access the right ios
<sb0> what do you need i2c for?
<fengling_> sb0: yes
<fengling_> sb0: i want to test a board , it use iic
fengling_ is now known as fengling
<fengling> sb0: but i am not sure about the hardware, it has a SN74LVC1G17(Single Schmitt-Trigger Buffer) between the TCK and T_TCK.
<sb0> ah, yes, that's for supporting 2.5V JTAG... this might not play nice with the bidirectional signal sda of i2c
<fengling> sb0: I've tried gpio works,but IIC use the same pin with jtag.
<sb0> maybe use the uart connector instead
<sb0> I don't remember if it has buffers
<fengling> sb0: thanks, the uart connect just two pins, pin40 is float.
mumptai has joined #m-labs
_florent_ has joined #m-labs
<GitHub185> [misoc] sbourdeauducq pushed 4 new commits to master: http://git.io/_JmN7Q
<GitHub185> misoc/master 2f2a57d Sebastien Bourdeauducq: targets/ppro: clean up indentation
<GitHub185> misoc/master 3eabec2 Florent Kermarrec: make.py: add set_flash_proxy_dir to flash-bios
<GitHub185> misoc/master 7b10f18 Sebastien Bourdeauducq: targets/ppro: fix BIOS address
<sb0> _florent_, hi. I checked the RESET# pin on the DDR3 - and LVCMOS15 is correct, it's part of the DDR3 standard (so that the SDRAM can be held in reset when Vref is not stable yet)
<sb0> _florent_, also, platform-dependent mishaps like the STARTUPE2 should not be put in cores
xiangfu has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
<sb0> _florent_, are you able to reconfigure the kc705 from xc3sprog after flashing?
<sb0> with "xc3sprog -c jtaghs1 -R" I get "Device does not support reconfiguration."
<sb0> also, the flashing doesn't seem to work here, even though xc3sprog says the verification succeeds. DONE does not go high, and when loading the bitstream manually the BIOS does not boot.
<sb0> ah, DONE goes high... just takes a long time - much slower than with the preloaded designs
<sb0> BIOS still broken
fengling has quit [Quit: WeeChat 0.4.3]
fengling has joined #m-labs
xiangfu_ has joined #m-labs
<_florent_> hi
<_florent_> I've tested the BIOS on my board, it was working
<_florent_> but what I'm not sure is that the dummy parameter on my board still has its default value
<_florent_> maybe you should try with dummy=15
fengling_ has joined #m-labs
xiangfu has quit [Ping timeout: 246 seconds]
fengling has quit [Ping timeout: 246 seconds]
<_florent_> in fact the configuration I tested: flashing the BIOS and loading the bistream XC3SPROG
<sb0> meh, nevermind, I was using the wrong serial port
<_florent_> :)
<sb0> ttyUSBx naming is a mess
<_florent_> ok so on your board the dummy=11 configuration also works?
<sb0> I disabled XIP and just memory-mapped the SPI flash core to test. it's reading correct data with dummy=11.
<sb0> recompiling with XIP...
<sb0> also, after a while, DONE does go high and the board boots from the flash
<sb0> I guess there's some bitgen option to make the FPGA read the flash faster ...
<_florent_> yes it's probably reading the flash in FAST_READ mode (1 dq) and not in QIOFR mode (4 dq)
<_florent_> Where do you want to put the STARTUPE2?
xiangfu_ has quit [Quit: leaving]
xiangfu has joined #m-labs
<sb0> I put it into the SoC toplevel
<sb0> I also fixed the addresses
<sb0> XIP works :)
<GitHub142> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/oyKbxg
<GitHub142> misoc/master 35327a4 Sebastien Bourdeauducq: targets/kc705: BIOS XIP
<ysionneau> yeah!
<_florent_> great!
<_florent_> now you will be able to play the read/write leveling of the DDR3...
<_florent_> btw on my configuration I'm pretty sure only 1 or 2 of the 8 SO-DIMM modules introduces the errors
<_florent_> if you use only the first module, it's probably working
<larsc> I feel your pain, I have a couple of ZC706s on my desk, the bitstream works on half of them doesn't work on the other half
<sb0> hmm XIP is broken when using load-bitstream (same bug as the papilio)
<_florent_> strange, it's what I tested I think...
<sb0> that's rather inconvenient with the slow flash boot time.. hmm
<_florent_> so you flash the bios, you load the bitstream and it does not boot?
<sb0> yeah
<sb0> but if I write the bitstream to the flash, and make the fpga load it from there, then it boots
<sb0> there is exactly the same symptom on the papilio pro
<sb0> on the ppro, boot also works when you use urjtag instead of xc3sprog for the bitstream load
<sb0> and boot works with both xc3sprog and urjtag when xip is disabled
<sb0> it's only the xc3sprog+xip combination that triggers the problem (and of course this is the one we want)
<_florent_> but the strange thing is that I validated this by loading the bitstream
<_florent_> but the bistream in the flash was a corrupted one, don't know it it change somethign
<ysionneau> (I have the same issue on my papilio pro as well)
xiangfu has quit [Ping timeout: 255 seconds]
<sb0> _florent_, this is with lm32. did you use openrisc?
<sb0> it seems to be a factor as well
<_florent_> no I'm using lm32
xiangfu has joined #m-labs
<_florent_> but you can try to corrupt your flash (writing the bios for example to address 0) to see if it change something
<_florent_> ah... it's with openrisc that it doesn't work?
<_florent_> if so, no I haven't test with openrisc
<sb0> no, it's with lm32
<_florent_> so I was lucky... I'll retry that with the upstream code, but I don't have the KC705 near me today
fengling_ has quit [Ping timeout: 240 seconds]
<sb0> "The bitstream options LCK_cycle or Match_cycle will add an undefined additional number of clock cycles"
<sb0> xilinx ug470. some things will never change ...
<sb0> they probably mean that the number of cycles needed for PLL/DCM lock and DCI calibration may vary ...
<sb0> _florent_, also, I'm using ISE. maybe the bug does not manifest itself with vivado...
<_florent_> IIRC I was using ISE...
<sb0> so, setting CAS to 7 does align the data correctly... we shouldn't need bitslip
<GitHub8> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/Ylls_w
<GitHub8> migen/master 402c7db Sebastien Bourdeauducq: platforms/kc705: read the configuration flash faster (ISE only)
<GitHub8> migen/master cb5894b Sebastien Bourdeauducq: platforms: add -w option to bitgen_opt
<GitHub120> [misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/ddRezA
<GitHub120> misoc/master 66fe45b Sebastien Bourdeauducq: k7ddrphy: decrease CAS latency to account for cmd/data flight time
<GitHub120> misoc/master b94647a Sebastien Bourdeauducq: k7ddrphy: suppress idiotic bitgen warning about ISERDES IOBDELAY parameter
xiangfu has quit [Remote host closed the connection]
<sb0> "WARNING:Pack:2949 - The I/O component clk200_p uses an DQS_BIAS attribute with I/O standard LVDS. The DQS_BIAS attribute will be ignored since the selected I/O standard does not support DQS_BIAS usage."
<sb0> where is that DQS_BIAS attribute coming from?!
<sb0> hmm, from IBUFDS it seems... and that's totally undocumented... another quirk
<sb0> "WARNING:PhysDesignRules:2217 - ISERDESE2 instance <ISERDESE2_46> has the attribute INTERFACE_TYPE set to MEMORY and the DATA_RATE to DDR and the DATA_WIDTH to 8. This combination is not recommended. For INTERFACE_TYPE MEMORY and DATA_RATE DDR the recommended DATA_WIDTH values are <4>."
<sb0> this one is also funny. and no mention anywhere else...
<sb0> _florent_, I see why you kept the SERDES in NETWORKING mode and used bitslip since it was there :) but I'd rather make overengineering a xilinx-only problem as much as possible, and stay away from bitslip
<sb0> also this bitslip feature does not make any sense as you can trivially implement it in the fabric using a register and a barrel shifter
_florent_ has quit [Ping timeout: 246 seconds]
Alain__ has joined #m-labs
_florent_ has joined #m-labs
<_florent_> in fact yes we don't really need bitslip, that was just more convenient to try to find timing but I wasn't aware of the "WARNING:PhysDesignRules:2217
<_florent_> even if data were not aligned correctly we can still play with CAS, read command phase, read phase
<sb0> xilinx fpga ios are always full of surprises ;)
<sb0> yes, totally
<_florent_> but that's not dynamic
<_florent_> on the "almost working" timing I provided you, I don't understand why I need to have the IDELAY configured to 27 on the last modules...
<_florent_> but maybe it was a "WARNING:PhysDesignRules:2217" related issue...
<_florent_> if you change the INTERFACE_TYPE you will then gain a full sys_clk on read latency
<sb0> yeah, I tried that and in addition to the warning, the serdes seems to sample the data earlier (only the last 64 bits are SDRAM data)
<sb0> er, no, last 256
<_florent_> with INTERFACE_TYPE configured to NETWORKING?
<sb0> with INTERFACE_TYPE=MEMORY. when you set it to NETWORKING, data is correctly aligned with the SERDES sampling window (all at CAS latency 7)
<sb0> *last 128
<_florent_> strange, I was expecting to have the same alignment but only 1 full sys_clk before...
<sb0> yeah, same. maybe that's what the warning is about
<_florent_> you can increase the read phase by 1sys4x clk, and read the ouput of the serdes 1 sys_clk after
<_florent_> but then you loose the 1 sys_clk gain of latency
<_florent_> btw, I think we should automatically compute read/write cmd phases and read/write phases
rofl__ has joined #m-labs
sh[4]rm4 has quit [Ping timeout: 260 seconds]
_florent_ has quit [Ping timeout: 246 seconds]
rofl__ is now known as sh4rm4
_florent_ has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.90.1 [Iceweasel 24.7.0/20140722231038]]
clever has joined #m-labs
_florent_ has quit [Quit: Page closed]
sh[4]rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 260 seconds]
sh[4]rm4 is now known as sh4rm4
mumptai has quit [Ping timeout: 260 seconds]
Alain__ has quit [Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446]]
mumptai has joined #m-labs