IRC logs for #openrisc Tuesday, 2014-11-25

--- Log opened Tue Nov 25 00:00:43 2014
olofkLimb: Remind me, what is the issue you are seeing?08:08
olofkysionneau: Stil ready for DFI? :)08:32
_franck__it looks good. Too bad there is no source code.10:13
olofk_franck_: Nice find!10:17
olofkI'll drop him a mail10:18
_franck__I've tried but haven't got any answer. But I'm not as famous as you ! You could have more luck10:19
olofkYou mean that I'm famous for hunting down and killing people who don't answer my e-mails? :)10:20
_franck__yeah that's what I meant :)10:21
jeremybennett_Is there a problem with OpenRISC SVN at the moment?  FuseSoC is struggling here.10:25
ysionneauolofk: yes!11:02
olofkjeremybennett_: There's often problem with OpenCores SVN nowadays11:19
olofkysionneau: I was wondering if there is really any benefit in doing a two phase DDR implementation. I switched over to a single phase, and got it mostly working now. Any thoughts11:20
ysionneauhow I understand it, it's easier to have <wb_width> bits moved in/out sdram in one system cycle11:24
olofkHow wide is your RAM?11:25
ysionneauso if your sdram dq_width is 16 and your wb_width is 32 then 1 phase is OK11:25
ysionneaubut if your dq_width is 8 then you might wanna have 2 phases11:25
olofkMy dq width is 16 and wb width = 32, but every write consumes 4x16 words, so I need to scale it up to 64 bits to utilize the full bandwidth11:26
ysionneauor you can use a wishbone downconverter ( )11:26
olofkFor writing I would need an upsizer11:27
ysionneau12:25 < olofk> How wide is your RAM? < depends on the system, for now my only DDR system's dq width is 32 (2 x16 chips)11:27
ysionneaubut to test my controller I cannot have more than 32 bits right now so I reduced the number of used dq pins to x811:27
olofkSo for every burst you need to supply 128 bits of data, right? If you are using BL411:28
olofkah ok11:28
ysionneauthe thing is, in our systems we set BL so that we get wb_size in 1 system clock11:28
ysionneauso here I set BL4 in my x8 system11:29
ysionneaubut all of this is totally implementation dependant :/11:29
olofkBut that would only work for x8 and x4 DQ widths, if you have a 32 bit wb11:29
ysionneauit only works for dqx8 here, or dqx4 if I use a DownConverter which translates the 1 32bit access in 2 16 bits accesses11:31
ysionneauI mean, I think the more phases the better, you get more bandwidth, but I also think it's getting harder to integrate11:33
ysionneauit tends to be easier with dq_width x nphases <= wb_width11:33
olofkYes, I'm starting to see the benefits of using several phases if you can use the native data width all the way to the phy11:34
ysionneauyes, then you set BL = 2*nphases for DDR11:34
ysionneauor 1*nphases for SDR11:34
olofkBut the phy got complicated enough so I'm settling for a single phase with data_width = 4*dq_width11:34
olofkwith BL=411:35
olofkfor a 16-bit RAM11:35
ysionneauso you have 2 system cycles to retrieve the data right?11:35
olofkLots of restrictions here :)11:35
ysionneauhere basically your system clock == your ddr clock ?11:35
ysionneauyes I think it's the easier way to do11:36
ysionneau2 phases is a little bit more complex but not that much and it gives more bandwidth11:36
olofkBut I will probably need to do this a better way to increase the bandwith11:36
olofkProblem is then that I can only send 32*sys_clk bps anyway11:37
olofkWell, that's not entirely true if I have multiple masters11:38
olofkAnyway. Hoping to be done with my tech-independent DFI Phy soon. Would be interesting to see how hard it would be to integrate that in misoc11:41
ysionneauyou've done it in Migen?11:45
olofkNo. Pure verilog, but I guess it could be wrapped in a module11:49
olofkOr if someone wants to rewrite it, it's not very many lines of code11:50
Limbolofk: the cellular ram interface works with anything smaller then size=4096 in wb_intercon.conf but anything larger causes CRC errors in openOCD and doesn't work22:02
olofkLimb: Do you have the source available somewhere?22:04
LimbThat's unmodified from juliusb original code for the nexys 322:08
olofkLimb: Do you know if there are any simulation models available for the cell ram?22:10
Limbolofk: not to my knowledge22:10
LimbI increased the read and write cycles and got it to work at 8192, but it wasn't writing correct values22:12
olofkThat smells like timing issues. Can you send me your .twr file that's generated by ISE?22:13
LimbI will do so in about an hour22:14
olofkI don't know a thing about Cellular RAMs, but is the clock really supposed to be 0?22:17
Limbolofk: it has a standard SRAM interface, and I don't know much about them either. I have the data sheet on my desk at home. Are you referencing a specific line of code?22:19
olofkI found a simulation model by the way. I can try to set up a testcase and see what happens22:21
LimbWould you mind linking it olofk?22:23
olofkThe model is available here{BD8A72EA-2DC2-4B88-846E-7B59997A2D97}22:23
olofkI like Micron. They have great models22:23
olofkNot like stupid Winbond assholes that only supplies encrypted models. Grrr!!!22:24
Limbolofk: during asynch mode clock is static low22:26
olofkHave you tried lowering the clock frequency by the way?22:27
LimbI'm not sure of these lines would affect it, I don't have them in my code22:30
LimbAnd I haven't tried lowering the clock, I figured lowering the nexys4s 100 MHz to 50 MHz would keep Iit in line with the nexys322:31
olofkIt makes more sense to let wb_intercon handle that arbiter stuff22:31
LimbIs that part of the arbiter? I couldn't tell if it was or doing some translation between the WB interface and cell ram22:33
olofkI think that's just 2-port wishbone arbiter22:34
olofkBut with priority on the data bus. Shouldn't matter in this case though22:34
olofkLimb: Going to bed now, but I set up a quick test bench. Not sure it does what it's supposed to do, but I'm getting a lot of warning about timing violations here23:03
Limbolofk: thats my twr file23:17
--- Log closed Wed Nov 26 00:00:44 2014

Generated by 2.15.2 by Marius Gedminas - find it at!