03:15 <stekern> ysionneau: (call ra) that is a bit surprising. I would have expected that the old value for ra would have been used the call and the new value to be written back at a later stage

03:15 <stekern> s/used the/used for the

03:19 <stekern> to me it would sound like you'd need special logic to behave like that

05:38 <mithro> so, anyone got a suggestions on how to figure out why half my ram is failing the memory initialisation test?

05:53 <sb0> does it work fine with sdrrd/sdrwr?

05:55 <mithro> https://www.irccloud.com/pastebin/CS0Hx9MR

05:55 <sb0> that's not sdrrd/sdrwr

06:08 <mithro> https://www.irccloud.com/pastebin/sotvfIAM

06:08 <sb0> you are not getting correct values

06:09 <sb0> it should be 0001101120213031

06:09 <mithro> sb0: I'm trying to figure out what the correct values are, but I don't understand the code in sdrwr

06:10 <sb0> also, if you do sdrwr 0, you will write to the first 8 locations

06:10 <sb0> (in a burst)

06:10 <sb0> and then sdrrd 0-7 will give you the different SDRAM burst orderings, which will help you determine if your reads or your writes are failing

06:11 <sb0> sdrwr/sdrrd just copy the passed value to the SDRAM address lines when asserting CAS

06:12 <sb0> also, if you consistently read the same (possibly incorrect) data, it's probably the write that failed

06:13 <sb0> wait, how many bits do you have?

06:13 <sb0> 16?

06:13 <sb0> (DQ lines on the SDRAM)

06:14 <sb0> sorry the expected value should be 0001020310111213

06:14 <mithro> according to the data sheet, density == 1G bits, the schematic has 16 DQ lines

06:14 <sb0> did you configure burst length 8?

06:15 <sb0> can you read an uninitialized address?

06:15 <sb0> eg sddrd 32

06:16 <mithro> sb0: probably not, where does that get configured?

06:16 <mithro> BIOS> sdrsw

06:16 <mithro> SDRAM now under software control

06:16 <mithro> BIOS> sdrrow

06:16 <mithro> Precharged

06:16 <mithro> BIOS> sdrrow 0

06:16 <mithro> sorry about that :/

06:17 <mithro> pasted into IRC channel rather then paste bin :(

06:17 <mithro> sb0: -> http://pastebin.ubuntu.com/8221181/

06:18 <sb0> ok

06:18 <sb0> sounds like you have a write problem, and the reads are probably fine

06:19 <sb0> and you're probably at the correct burst length too

06:19 <sb0> try changing the write latency

06:21 <mithro> this is where my knowledge of DDR starts to fail me - write latency is tWR? - tWR is set to what the datasheet and MIG seem to agree on... Should I increase that?

06:23 <sb0> either change the write latency in the DDR chip or in the PHY... and don't expect it to be straightforward

06:24 <sb0> DDR chips don't support all combinations of CAS/write latencies

06:24 <sb0> and the PHY might need some tweaking to get the S6 SERDES to output the data at a different time

06:25 <sb0> you may want to read the micron ddr2 datasheets, which are the best explained of all sdram manufacturers afaik

06:27 <GitHub33> [misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/BXGj7w

06:27 <GitHub33> misoc/master 2388bfa Sebastien Bourdeauducq: bios: support DDR3 write leveling and read calibration. This makes the full DDR3 SODIMM work on the KC705.

06:27 <GitHub33> misoc/master a7b4550 Sebastien Bourdeauducq: sdramphy/initsequence: cleanup and expose DDR3 MR1 value

06:29 <sb0> in initsequence.py, there's a line "wr = 2" that you could perhaps use to change the write latency on the ddr chip - but check the datasheet before

06:30 <mithro> datasheet for my part is http://www.deutron.com.tw/pdf/D2_64x16.pdf -- annoyingly they use to use the MT47H64M16HR which has a much better datasheet

06:31 <sb0> yeah, but ddr2 chips from different manufacturers are very similar - you can read the micron datasheet to understand the concept, and check the one for your chip to get the specs

06:34 <mithro> sb0: is there an easy way to get the output of init_sequence, or should I just use the q module?

06:34 <sb0> software/include/generated/sdram_phy.h

06:35 <sb0> what's the q module?

06:36 <mithro> sb0: it's a really useful python module, you do "import q; q(blah)" and it dumps it into a file in /tmp/q with loads of information. q can also be used as a decorator on functions / classes to trace them, etc

06:36 <mithro> it's a very horrible hack but still very useful :)

06:37 <mithro> it's a very horrible hack but still very useful :)

06:37 <mithro> sb0: gah, my IRC client is unhappy today

06:37 <mithro> sb0: so it looks like my chip only supports a burst length of 4 and 8

06:38 <sb0> yes, that's what ddr2 chips usually support

06:39 <sb0> hmm, it should be burst length 4

06:39 <sb0> sorry, still immersed in ddr3

06:39 <mithro> sb0: which it seems to be using - didn't you mention something about BL of 16 in somewhere? Or I'm just confused...

06:39 <mithro> sb0: no worries! DDR3 support would be awesome :)

06:40 <mithro> sb0: I'm very interested in your Series 7 device support - it's what finally got me to try out your stuff

06:41 <mithro> sb0: on a related note, you do misoc + hardware hacking as part of m-labs stuff full time?

06:44 <mithro> sb0: does your system support cl levels other than 3? It seems like cl=3 is hardcoded in your S6DDRPHY module...

06:46 <sb0> yes. right now I'm working on ARTIQ, a control system for trapped-ion physics experiments, which uses misoc, and the kc705 ddr3 support was for that.

06:48 <sb0> we don't support variable CAS latency; if you change the CL, you have to make the SERDES sample the data at a different point in time, and then realign all the data in a burst to a system clock cycle. that's a tad messy and platform-dependent, and it's not worth doing it as you want to operate at the smallest possible CL for performance reasons anyway.

06:48 <sb0> only intel has time for this

06:49 <sb0> and much worse horrors like usb, acpi, etc.

06:50 <mithro> sb0: I was hoping on going in the opposite direction, increasing the CL to give a bigger margin

06:50 <mithro> sb0: if writes to the RAM are failing, then is it possible that the init_sequence is also failing?

06:51 <sb0> increasing the CL only shifts the data by an integer number of cycles, it won't improve IO timing margins

06:51 <sb0> also, CL only matters for reads

06:52 <sb0> no, since you are registering the read/write commands properly, and the init sequence goes the same route

06:53 <sb0> I think you should spend a couple hours studying some ddr2 datasheets

06:53 <mithro> sb0: true - just trying to reduce differences between our known working MIG configuration - we use a CL=5 on this chip (the data sheet says a CL=3 should work)

06:55 <sb0> it sounds like you are just sending the write data a cycle too late or too early

06:55 <sb0> or half a cycle

06:57 <mithro> sb0: thanks for your help, I really do need to get a better understanding of DDR2 - I have such a hodge podge of some specific bits of knowledge which make me dangerous and then huge holes in between

06:59 <mithro> sb0: misoc specific question, you seem to do all your set up of the DDR2 chip in C - is that the normal approach in your system because you have a full processor available? Seems like a pretty intelligent approach in a system like this

07:00 <sb0> yeah, it saves some FPGA resources, simplifies some developments (particularly the rather complex ddr3 leveling), and helps a lot with troubleshooting the SDRAM when it acts up

07:01 <sb0> there is no support for sdram without a cpu

07:04 <GitHub118> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/hCBpkA

07:04 <GitHub118> misoc/master 36434b6 Sebastien Bourdeauducq: sdram: merge DFII_PIX_RDDATA_SIZE and DFII_PIX_WRDATA_SIZE

07:27 <mithro> sb0: is there a good discussion thread about how you ended up on the lm32 processor? http://opencores.org/usercontent,doc,1393289758 seems to list the huge amount of system

07:30 <sb0> yeah and most of them are crap

07:31 <sb0> lm32 works and has the best performance/LUT ratio, simple as that

09:31 <GitHub79> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/rpYCbQ

09:31 <GitHub79> migen/master f21e050 Sebastien Bourdeauducq: platforms/kc705: use jtaghs1_fast cable

09:36 <sb0> rjo, just tested ddr3 with vivado - it works here too

10:47 <mithro> in migen is there a quick way to create a second clock from the primary clock in a simulation?

11:24 <sb0> multi clock simulations are not implemented

13:44 <_florent_> hi

13:45 <_florent_> sb0: DDR3 init on my board: http://pastebin.com/w3qzNqJz, it's also working :)

14:12 <sb0> 2:00-06 is rather close... that one could perhaps be bit-slipped too

14:12 <sb0> but good :)

23:30 <rjo_> sb0: nice tour de force! i'll see who i can get to actually do some code reading and testing here. i don't want to be the only one who ever read and ran the code...

23:32 <rjo_> sb0: just out of curiosity: can a single lasmi dma master saturate that? what is the bus rate and width in that case?