sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<GitHub61> [smoltcp] whitequark commented on issue #82: Yes. Tap interfaces are software emulation of layer 2 interfaces (Ethernet in our case) so we can handle them with EthernetInterface. However, tun interfaces are software emulation of layer 3 interfaces (TCP/UDP/IP directly), so we would need an alternative to EthernetInterface that works on layer 3. We can implement that, but why should we? https://github.com/m-labs/smoltcp/issues/82#issuecomment-34
FelixVi2 has joined #m-labs
FelixVi has quit [Ping timeout: 248 seconds]
FelixVi2 has quit []
FelixVi has joined #m-labs
FelixVi has left #m-labs [#m-labs]
FelixVi has joined #m-labs
<FelixVi> _florent_: are you around?
<cr1901_modern> FelixVi: Patience. IRC is async.
<FelixVi> cr1901_modern: yeah, I can work on another platform implementation in the meantime ;)
<FelixVi> cr1901_modern: have you heard about the path resolution issue? I can help out with that and/or do some more testing as well
<cr1901_modern> which path resolution issue? I've lost count
<FelixVi> there might be a couple more things inside generated batch files that we haven't touched yet
<cr1901_modern> I just want cygwin to work so I can forget about it again lol
<FelixVi> the posix vs win path thing
<cr1901_modern> Batch files should be fine; user is expected to run the batch file from within the build directory
<cr1901_modern> it'll fail otherwise
<FelixVi> yeah, everything is working fine. I get one error that a file is not found, but that's just the ISE settings.bat that is called from with the build batch file
<cr1901_modern> A. which file?
<cr1901_modern> B. There is absolutely nothing we can do about that anyway
<FelixVi> build.bat
<FelixVi> but it's not a big deal, I got ISE binaries in system path and things are working fine
<FelixVi> this one and the two places (ise and programmer) we fixed previously are the only places the path issue has shown up thus far
<cr1901_modern> I haven't updated my copy w/ the programmer fix yet
<cr1901_modern> I'll give you credit in the PR/commit for it
<cr1901_modern> But prob should use my PR
<FelixVi> this *should* work fine as long as ISE binaries are in path
<FelixVi> I don't care as long as it works ;)
<cr1901_modern> source=True just isn't supported for Cygwin, not a huge deal
<cr1901_modern> well... "/cygdrive/c/Xilinx/" should work
<FelixVi> hmm, yeah it does
<FelixVi> then there must be something else... I'l track it down
<cr1901_modern> Wait, why doesn't this work?
<FelixVi> it works fine
<FelixVi> but I do get a "file not found" from an unidentified source
<FelixVi> nevertheless, it works fine
<cr1901_modern> meaning it can't find settings64.bat more than likely
<cr1901_modern> Can you manually swap the path to windows format?
<FelixVi> that works fine
<cr1901_modern> So no more "not found" error?
<FelixVi> so, it is this line it's coming from
<FelixVi> correct
<cr1901_modern> Cygwin must pass control back to the windows command interpreter when it executes a batch file
<FelixVi> yeah, fixing this should run the tools without having them in path
<FelixVi> do you want to add it to your PR? Feel free to grab what you can use from my commit - I tried to clean it up as much as possible
<cr1901_modern> Why don't you try it :)?
<cr1901_modern> I mean source=False
<cr1901_modern> FelixVi: Sure
<FelixVi> what's the deal with source = True vs source = False?
<cr1901_modern> source=True means try to automatically find the binaries
<FelixVi> ah, I see
<FelixVi> k, just pushed the fix for that
<cr1901_modern> FelixVi: Ack I'll commit it later. Need to rest for now
<FelixVi> are you rebasing your PR or should I merge my two commits into a single clean one?
<cr1901_modern> FelixVi: I'll rebase
<FelixVi> cool
<cr1901_modern> rjo: Even though you approved please don't commit yet. Won't get a chance to fix till tomorrow.
<FelixVi> hmm, so the mimasv2 target doesn't meet timing in my hands with fcore = 81.333 MHz
<FelixVi> so that has the same issue that I am facing with the Saturn, which is virtually identical but a LX45
<FelixVi> and running at lower freq fixes timing issues, but I still just can't pass memtest
<FelixVi> aight, so if you use p//2, I guess p better be an even number... But that didn't fix it either
rohitksingh_work has joined #m-labs
<GitHub61> [smoltcp] LuoZijun commented on issue #82: @whitequark as i know, the `phy` module is `RAW_SOCKET` api work on bsd/linux/windows platforms. ... https://github.com/m-labs/smoltcp/issues/82#issuecomment-345585988
<GitHub84> [smoltcp] LuoZijun commented on issue #82: @whitequark as i know, the `phy` module is `RAW_SOCKET` api work on bsd/linux/windows platforms. ... https://github.com/m-labs/smoltcp/issues/82#issuecomment-345585988
<GitHub34> [smoltcp] LuoZijun commented on issue #82: @whitequark as i know, the `phy` module is `RAW_SOCKET` api work on bsd/linux/windows platforms. ... https://github.com/m-labs/smoltcp/issues/82#issuecomment-345585988
<GitHub136> [smoltcp] whitequark commented on issue #82: If you just want the `phy::tun` module, I am fine with that. Please feel free to implement it and submit as a PR, and I will merge it. https://github.com/m-labs/smoltcp/issues/82#issuecomment-345588240
<GitHub23> [smoltcp] LuoZijun commented on issue #82: @whitequark okay, i try. https://github.com/m-labs/smoltcp/issues/82#issuecomment-345593019
<FelixVi> are there any examples how a kernel file is generated for misoc?
<FelixVi> saturn platform is still broken (I'll try another FPGA board tomorrow), so I'm using a Papilio for now
<FelixVi> is there a way that migen can run the compiler for kernels or are you supposed to generate Makefiles yourself?
<FelixVi> *migen or misoc
<FelixVi> all I'm trying to get going for now is a single puts("Hello World"), I assume that's a good start
<FelixVi> or maybe the blinkie example shown at orconf2014
<FelixVi> if anybody has a suggestion, I'll check IRC logs in the morning
<FelixVi> good night
FelixVi has quit []
cyrozap has quit [Ping timeout: 246 seconds]
cyrozap has joined #m-labs
FabM has joined #m-labs
<_florent_> FelixVI: has you tested the generated bitstream at 81.333 even with the timing errors?
<_florent_> has/have
<_florent_> FelixVI: if you change the cpu freq, you will have to adjust others parameters yes.
<_florent_> FelixVI: you can try to change rd_bitslip, wr_bitslip, dqs_ddr_alignment if frequency is changed
<_florent_> FeflixVI: for debug, you can reduce l2 size to minimum (try to reduce until misoc complains), add some printf to memtest to see what is read, what was expected on error check, then you can post results here or try to understand what is going on.
X-Scale has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
key2 has joined #m-labs
<key2> hi
<cr1901_modern> Idle thought: What happened to key1?
<key2> who that
FabM has quit [Ping timeout: 264 seconds]
<_florent_> cr1901_modern: the caterpillar has turned into a butterfly :)
FabM has joined #m-labs
<cr1901_modern> _florent_: Good point
FelixVi has joined #m-labs
<FelixVi> _florent_: yes, I tried the image at 81.333 MHz - didn't work
<FelixVi> timing must be different between the two speedgrades
<FelixVi> can you help me tweak the memory controller?
<FelixVi> I just need to setup a bunch of stuff as this is another computer
<FelixVi> _florent_: is this problem a thing because the sdram controller i/o aren't registered?
<FelixVi> I guess I'm just not sure what I am trying to tweak if the design meets timing
<FelixVi> or is there something that can't have a timing constraint?
AceChen has joined #m-labs
AceChen has quit [Client Quit]
AceChen has joined #m-labs
AceChen has quit [Client Quit]
<FelixVi> ok, so how are you supposed to compile misoc/software/memtest ?
<cr1901_modern> grep for "extra software packages"
<FelixVi> adding it as builder.add_software_package("memtest") yields this error
<cr1901_modern> oh nevermind can't help you then :)
<FelixVi> ah, it doesn't find common.mak
<FelixVi> this is what I get
AceChen has joined #m-labs
<FelixVi> ok, is common.mak just completely broken?
<FelixVi> or is it more path issues that I need to be looking at?
<cr1901_modern> Not at all :D
<cr1901_modern> Most likely :)
<FelixVi> ok, so it works not under Cygwin
<cr1901_modern> I'm going to have to install Cygwin, aren't I?
<cr1901_modern> bleeeeh
<FelixVi> as of now, it doesn't get TRIPLE right
<FelixVi> hold on, I might be able to fix it
<FelixVi> need to look at builder.py and possibly path stuff
<FelixVi> it's weird that it doesn't even copy source files to the build directory
<FelixVi> but there is also no warnings or errors
<_florent_> FelixVi: the fpga design meets timing but we have to ensure timing are respected for the dram
<FelixVi> _florent_: is there timing constraints that keep an eye on that?
<_florent_> FelixVi: no, that's outside the fpga
<FelixVi> _florent_: my understanding is that traces are length matched, so whatever the FPGA puts out should be correct
<_florent_> FelixVi: first thing to do is to reduce l2 size, then hack sdram.c to see what is read from sdram
<FelixVi> _florent_: does misoc support xilinx MCBs?
<_florent_> FelixVi: no but you can still use it as with an Instance
<FelixVi> _florent_: that can be done in bios or do I need to be able to compile kernels? Because that doesn't quite work yet, either
<_florent_> you can do that in bios
<FelixVi> _florent_: is l2 cache size determined by cpu_reset_address?
<_florent_> no, in the Soc definition
<FelixVi> k, found it
<_florent_> ok
<FelixVi> go from 8192 down to 512?
<_florent_> try to reduce to minimum
<_florent_> 8, 16, 32?
<FelixVi> k, 16 it is
<FelixVi> I still don't get why bios compiles fine, but memtest doesn't
<FelixVi> but that's a seperate issue
<FelixVi> k, sdram.c should print expected and actual values for ZEROONE
<FelixVi> let's see...
<FelixVi> Memtest failure: expected 1431655765 but got 1431655765
<FelixVi> from printf("Memtest failure: expected %d but got %d\n", ZEROONE, array[i]);
<FelixVi> as far as I can see that should check out
<FelixVi> ah, but for random data there's actual errors
acathla has quit [Read error: Connection reset by peer]
acathla has joined #m-labs
<FelixVi> for example expected 0x1BA5175, but got 0x51755175
<FelixVi> another one is expected 0x624F0979, but got 0x9790979
<FelixVi> it seems to repeat the lower 16-bits
<FelixVi> as if the serdes got the same input twice
<FelixVi> this is the period constraint report: https://pastebin.com/mtduWkrz
<FelixVi> 0 is sdram wr rd
<FelixVi> 2 is sdram dqs adr ctrl
<FelixVi> 3 is off-chip ddr
<FelixVi> 5 is sys
<FelixVi> ratios are identical to pipistrello
<FelixVi> this is the latest repo: https://github.com/FelixVi/misoc
<FelixVi> using target saturn
<FelixVi> apart from the repetition in data, I find it weird that 0x55555555 != 0x55555555
<FelixVi> ok, there was some brackets missing in sdram.c... it fails random data and random address only
<FelixVi> I think timing is fine, but somehow data is getting corrupted
<FelixVi> This is the memtest output: https://pastebin.com/xdw7dbh0
<FelixVi> This is the synthesis report: https://pastebin.com/gkZqEpB6
<FelixVi> What is going on there?
<_florent_> FelixVi: the problem is not with synthesis but with controller parameters. Now that you are able to see returned data, you play with rd_bitslip, wr_bitslip and dqs_ddr_alignment and see if it's better
mumptai has joined #m-labs
<FelixVi> yeah, hopefully that's fixable
<FelixVi> i still can't compile memtest, though
<FelixVi> the non-bios version appears to be missing libraries
<FelixVi> sb0: should memtest as software package be functional? If so, where does it get all its functions from? the linker says it can't find them
<FelixVi> _florent_: I'm not having much luck with dqs_ddr_alignment or bitslip
<FelixVi> what I find weird is that no matter what I do, the random address test (last one in bios memtest) is alsways off by 1
<GitHub115> [artiq] jbqubit commented on issue #829: Patch applied. Running same ARTIQ Python example as above. Writing to influxdb generates no errors. Thanks @sbourdeauducq. https://github.com/m-labs/artiq/issues/829#issuecomment-345858639
<FelixVi> the other question I have is what if the soc configuration and FPGA mapping changes? Do you have to sit sown every time and fiddle around with memory timing?
<FelixVi> or does this keep working assuming you hit timing relatively centered
<cr1901_modern> "Do you have to sit sown every time and fiddle around with memory timing?" Probably not
mumptai has quit [Quit: Verlassend]
<FelixVi> cr1901_modern: I hope so... Something here doesn't check out
<FelixVi> It's probably another detail I'm missing
<FelixVi> but it's like address and data serdes have a weird phase shift
<FelixVi> pll3 has an actual period of 2.666 ns while pll2 has 7.972 ns
<FelixVi> I think that's the problem, so it's gonna be hard to align data off the 2x clock and shifted 2x clock