10:01 <kitten_nb_five> hello! it seems in this channel there a people familiar with Colorlight 5A-75B and similar boards using Lattice ECP5.

10:01 <kitten_nb_five> did anybody managed to make the DRAM work on the 5A-75B V7 with ECP5 in CABGA256-package using pure Verilog and not this migen-thing?

10:02 <tnt> "manage" ? I mean there is nothing special about it, so any SDRAM controller will work.

10:03 <daveshah> I've successfully used https://github.com/skristiansson/wb_sdram_ctrl on a ULX3S before

10:03 <daveshah> but there are plenty of other Verilog SDRAM options out there

10:09 <kitten_nb_five> tnt: maybe this was the wrong word (non-native english-speaker here). i want to know if we are sure the hardware-pin-mapping is correct and if there is anything special (it seems like no) that i must consider for using the DRAM. For learning purpuouses i am trying to write my own simple controller, the simulation seems fine but it does not work, the DRAM draws no current while it should be drawing like 100mA or so in auto-refresh

10:33 <daveshah> Been a while since I've looked at DRAM commands, but I'm not sure if auto-refresh will significantly increase current other than for the short time to refresh the row

10:34 <daveshah> have you actually tried writing something and reading it back?

10:41 <kitten_nb_five> daveshah: if i read the datasheet correctly (do you want a link?) it says refresh-current is 100mA, so...

10:42 <kitten_nb_five> no, i did not try Read/Write, i think i will do this next

10:42 <kitten_nb_five> (and i am doing refreshes continously)

10:42 <daveshah> Yeah but autorefresh only lasts a few 10s of ns

10:44 <kitten_nb_five> now that you say this... yeah...

10:44 <kitten_nb_five> i should try implementing simple read/write i think. lot more fun to come...

10:45 <kitten_nb_five> afaik there is only a config-register on DRAM, nothing like a vendor code or something i could read to check my stuff?

10:46 <kitten_nb_five> (i am a software guy, ICs with SPI and I2C and stuff usually have something like this...)

12:24 <omnitechnomancer> It should be reasonably easy to use a state machine to write a set of values in a burst then read it back and check it?

12:33 <kitten_nb_five> i hacked together some write()-stuff, but for read() i am struggeling. i based my design on a FSM that is triggered by negedge of the DRAM-clock. however for reading i need to sample on the posedge of this clock. not sure how to handle this. we don't have CS# of the DRAM, it is hardwired to GND, so timing is a bit hairy.

14:26 <omnitechnomancer> Can you do clever things with DDR input modes?

14:33 <Gracana> Hi folks, I've done a couple ice40 boards but I'd like to make life easier on myself and keep all the components on the top of the PCB so I can reflow the boards on a hotplate. Is that a bad idea? Think I could get away with it in an ecp5 design? I know it won't make for good decap placement, but I'm hoping it'll be ok for designs without super demanding high-speed I/O.

14:35 <Gracana> I guess I can just give it a shot and see how poorly it works, but comments/advice from people with more experience would be nice.

14:38 <agg> i just assembled a new ecp5 board with cabga256 where i did only top-side decoupling to make life easier, but i hadn't got around to seeing how bad it is yet

14:40 <agg> with wide power planes going to the power balls i'm optimistic it will reasonable

14:41 <Gracana> oh, that's good to hear

14:41 <Gracana> How many layers does your board have?

14:41 <agg> 4

14:45 <Gracana> how much of the signals were you able to escape?

14:46 <agg> I escaped all the ones I needed for the design, which is jtag, qspi flash, 24 top i/o, 19 right i/o, 31 left i/o

14:49 <agg> (no ddr memory, 8 lvds pairs)

14:49 <Gracana> Ah ok, a lot left on the table but still very cool. I hope it works.

14:50 <agg> there's a decent bit of room to escape more signals if I needed to, but this got everything I wanted

14:50 <Gracana> good!

14:56 <agg> Gracana: so with 72% of this LFE5U-45F-6BG256 running 100MHz LFSRs, an IO wired to 3v3 shows 200mVpp and 40mVrms ripple

14:57 <agg> there are no doubt tougher tests to subject it

14:57 <agg> (I hadn't looked into the 3v3 ripple under load specifically, but everything else I've tested so far has worked fine, btw)

15:02 <Gracana> That's quite respectable. Sounds good enough for me to try it out.

15:04 <agg> with the fpga in reset it's about 16mVpp and 3mVrms, so most of that is from the fpga logic ticking over

15:05 <Gracana> Can I see a picture of your board layout?

15:06 <agg> sorry, it's an unreleased work project, so shouldn't really share photos

15:06 <Gracana> oh ok, no problem

15:06 <agg> it's not especially exciting though, I basically have a lot of decoupling caps right next to the fpga in all the spots I don't have traces coming out on the top layer

15:07 <agg> and they via directly to the power plane from there

15:07 <Gracana> What I'm mostly curious about is how many decoupling caps you omitted vs a full layout with decaps for every supply pad

15:08 <agg> I had 2x 10n 1v1, 6x 100n 1v1, 2x 10µ 1v1, 1x 10n 2v5, 2x 100n 2v5, 1x 10µ 2v5, 100n for each VCCIO (13x), and another 3x 10µ on the vccio rails but not super close

15:09 <Gracana> nice, you've got them all and more.. that sounds about as good as it can get within the design constraints

15:10 <agg> if I was doing them on the underside i'd have had more smaller valued capacitors per ball ideally

15:10 <agg> but yea it didn't seem like a huge compromise in number of capacitors, the worry is just in the inductance between them and the balls

15:13 <Gracana> Well, I'll have to give the layout a try and see what I can come up with. My design will need more IO (for a 32 bit bus) and I'm still a little worried about switching large portions of an I/O bank on/off at the same time, but otoh my bus speed can be pretty low, with some series termination.

16:49 <kitten_nb_five> ok, my stuff still does not work, the DRAM always returns 16'h00 on read. i will try to hook up the logic analyzer to the mess, maybe i'll see something. oh men...