10:06 <popo> hi anyone here?

10:07 <popo> hallo

10:08 <qwebirc88278> hi

10:19 <lekernel> hi popo`

10:55 <_florent_> Hi ex-milkymisters :)

10:55 <_florent_> I'm just trying to catch up with the last migen/misoc changes

10:55 <_florent_> and was wondering:

10:56 <_florent_> will you be ok to integrate some "unofficial" ports in MiSoC?

10:56 <_florent_> I'm thinking of the de0-nano port in a first time

10:57 <_florent_> or do you prefer that the "unofficials" ports live outside of MiSoC?

10:57 <_florent_> The good thing I see with the de0-nano port is that is demonstrates the use of the altera toolchain

10:58 <_florent_> and will only need the c4sdrphy to be added to MiSoC

10:59 <_florent_> BTW does the LX9 port dissapeared? I don't see it in MiSoC and I'm not able to find the lx9 port on Robert's Github?

11:06 <lekernel> yes, we can have the de0-nano port in misoc, but it needs to work and keep working :)

11:08 <_florent_> yes of course I will do the work needed to integrate it correctly

11:08 <_florent_> and maintain it

11:09 <_florent_> It's basically only the "simple" SoC plus the c4sdrphy

11:10 <_florent_> I'll work on it and let you now it's ready

11:11 <_florent_> I'm also thinking of re-trying the Vivado support I've made some time ago for the KC705 port

11:12 <_florent_> (Vivado was not able to finish the P&R the last time I tried)

11:12 <_florent_> Are you interested by the Vivado port?

11:15 <lekernel> did you clean up the KC705 DDR3 PHY?

11:16 <_florent_> no, for now it's not cleaned up, but I will that soon and try to integrate it in MiSoC in case you want to integrate it

11:16 <_florent_> will do that

11:17 <lekernel> what I mean by "cleaned up" is do the read/write leveling properly

11:17 <lekernel> I doubt your solution is stable across PVT

11:18 <lekernel> I had a look at DDR3 datasheets, and the timing numbers don't check out

11:21 <_florent_> I will maybe also try the other solution (with the trick on the controller and without read-leveling)

11:23 <lekernel> "read leveling" is use DQS :) DDR3 has a comparatively large tolerance on the clock-to-DQS timing

11:24 <lekernel> if you sample data with the clock, like you can do with previous DDR generations, you can only use it reliably at DDR/DDR2 performance levels, maybe worse

11:27 <lekernel> and you should not use fully asynchronous FIFOs clocked by DQS, as those introduce a large and unpredictable latency. you should write the FIFO with DQS and read it with the clock in the cycle that will sample the correct data and not cause setup/hold violations in the worst case (slowest) DQS arrival time

11:27 <lekernel> (that cycle is fixed after the issue of a read command to the DDR3)

11:31 <_florent_> ok thanks for the informations

11:31 <_florent_> I really want to try this solution

11:31 <_florent_> the thing is with DDR, you know when you start, but you really don't know when you'll have something that works :)

11:32 <lekernel> the "trick" in the controller is to issue a dummy read command (i.e. repeat it) when there is a bubble, in order to flush data out of the IDDR2 and into the FIFO

11:32 <_florent_> and you don't have anything the see what is going wrong (except if you work for big compagnies :()

11:33 <lekernel> alternative is not to use the IDDR2 and design a soft dual-edge-clocked FIFO, but it sounds much more difficult, less portable, easier to get wrong, and possibly slower

11:36 <_florent_> it will probably be easier to use the IDDR2 in a first time since detecting bubble should be relatively easy

11:38 <lekernel> yes. soft async logic in FPGAs is a lot of pain: the routing has a lot of skew and the software tools aren't made for that (nor the FPGA architecture). plus you want that to be fast ...

11:44 <_florent_> yes that's why they added in_fifo / out_fifo / phasers but since it is not documented, it's maybe even easier to use soft async logic ;)

11:46 <lekernel> the xilinx design is horrible, don't touch it

11:50 <_florent_> thanks for the warning but I was not going to touch it :)I'm not going to touch it

11:50 <_florent_> oops

17:30 <azonenberg> lekernel: Xilinx apparently doesnt like documenting any of their memory interface hard IP

17:30 <azonenberg> They seem to assume you'll use MIG if you use memory at all

17:30 <azonenberg> or should i say, they're pushing MIG

17:32 <lekernel> ...and its non-portability :)

17:32 <azonenberg> Indeed

17:32 <lekernel> plus horrid interface etc.

17:33 <lekernel> (GUI)