| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** geertu <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 00:06 | |
| shenki | shorne: I wasn't yet testing your changes, but I can do that once I get my kernel booting | 00:09 |
|---|---|---|
| shenki | 23:45 < geertu> shenki: You need to build a kernel from litex-hub/linux#linux-rebase | 00:11 |
| shenki | i don't think that will help; the only driver that is relevant in that branch is the vexriscv interrupt controller | 00:11 |
| shenki | and that wouldn't be loaded as the device tree doesn't contain the compatible for that driver | 00:11 |
| shenki | also, I would expect to see early uart output before irqs enabled | 00:12 |
| sajattack[m] | <Melkhior> "sajattack: ilp32d requires..." <- I think maybe my linker supports ilp32d but my compiler doesn't? Does that make any sense? | 00:25 |
| sajattack[m] | I have my gcc toolchain and my kernel set to ilp32d, and I used the same toolchain to produce gdb, which resulted in ilp32d gdb, and I specified gcc with ilp32d as my linker, but I have no flag for rust to make it ilp32d | 00:26 |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has joined #litex | 00:31 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 260 seconds) | 00:33 | |
| *** geertu <[email protected]> has joined #litex | 00:33 | |
| *** _whitelogger <[email protected]> has quit IRC (Remote host closed the connection) | 02:04 | |
| *** _whitelogger <[email protected]> has joined #litex | 02:05 | |
| sajattack[m] | nevermind, built an ilp32 gcc toolchain and now it's complaining it can't link soft float and hard float together | 03:07 |
| sajattack[m] | so rust must be using ilp32d | 03:07 |
| sajattack[m] | <Melkhior> "sajattack: ilp32d requires..." <- how did you configure gdb? | 03:12 |
| sajattack[m] | I learned how to get qemu and gdb to work together instead of trying to gdb on the actual board https://hastebin.com/urigazuruw.rust | 03:36 |
| tpb | Title: hastebin (at hastebin.com) | 03:36 |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 03:46 | |
| *** Degi <[email protected]> has joined #litex | 03:47 | |
| *** peeps[zen] is now known as peepsalot | 04:09 | |
| *** alainlou <[email protected]> has quit IRC (Quit: Client closed) | 04:09 | |
| *** Yam26 <[email protected]> has joined #litex | 04:35 | |
| sajattack[m] | so that seems to me like the stdout object is a nullptr | 04:42 |
| Yam26 | Hello, | 05:43 |
| Yam26 | I have a few questions about LPDDR4 ram. Is it appropriate to ask here? I have two channels LPDDR4. At 800MT/s, it's pretty reliable. But at 1000MT/s, the calibration is not reliable. If the calibration works, then I could run sdram_bist and use it with no problem. Can anyone give me a suggestion how to make the calibration more reliable? The | 05:51 |
| Yam26 | one that seems to be a problem is the read leveling. | 05:51 |
| Yam26 | Thank you | 05:51 |
| *** FabM <[email protected]> has joined #litex | 06:16 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 06:23 | |
| *** TMM_ <[email protected]> has joined #litex | 06:23 | |
| _florent_ | Yam26: Hi, which hardware are you using? Can you share some calibration logs at 800MT/s and 1000MT/s? | 06:49 |
| shenki | _florent_: hello! I am writing a model for liteeth | 06:56 |
| shenki | _florent_: I am trying to understand how the slot selection works. Do you have a moment to describe it to me? | 06:56 |
| shenki | (where in the python does it decide which slot to put an incoming packet in, and how does it know that slot is free) | 06:56 |
| Yam26 | _florent_ it's my own hardware. | 07:14 |
| Yam26 | can I just paste the calibration here ? | 07:14 |
| Yam26 | =============== SoC ==================-- | 07:14 |
| Yam26 | CPU: VexRiscv SMP-LINUX @ 50MHz | 07:14 |
| Yam26 | BUS: WISHBONE 32-bit @ 4GiB | 07:14 |
| Yam26 | CSR: 32-bit data | 07:14 |
| Yam26 | ROM: 64KiB | 07:14 |
| Yam26 | SRAM: 8KiB | 07:14 |
| Yam26 | L2: 0KiB | 07:14 |
| Yam26 | SDRAM: 524288KiB 16-bit @ 800MT/s (CL-10 CWL-6) | 07:14 |
| Yam26 | --========== Initialization ============-- | 07:14 |
| Yam26 | Initializing SDRAM @0x40000000... | 07:14 |
| Yam26 | Switching SDRAM to software control. | 07:14 |
| Yam26 | Write leveling: | 07:14 |
| Yam26 | tCK equivalent taps: 48 | 07:14 |
| Yam26 | Cmd/Clk scan (0-24) | 07:14 |
| Yam26 | |000000000011111111111111| best: 9 | 07:14 |
| Yam26 | Setting Cmd/Clk delay to 9 taps. | 07:14 |
| Yam26 | Data scan: | 07:15 |
| Yam26 | m0: |00000000000000000000| delay: - | 07:15 |
| Yam26 | m0, b15: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | best: m0, b10 delays: 24+-06 | 07:15 |
| Yam26 | m1, b00: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b01: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b02: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b03: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b04: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b05: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b06: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b07: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b08: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b09: |11111111100000000000000000000000| delays: 04+-04 | 07:15 |
| Yam26 | m1, b10: |00000000000000001111111111111111| delays: 24+-08 | 07:15 |
| Yam26 | m1, b11: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b12: |00000000000000000000000000000000| delays: - | 07:15 |
| tnt | dude ... pastebin ! | 07:15 |
| Yam26 | m1, b13: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b14: |00000000000000000000000000000000| delays: - | 07:15 |
| Yam26 | m1, b15: |00000000000000000000000000000000| delays: - | 07:15 |
| _florent_ | Yam26: pastebin will indeed probably better for this :) | 07:15 |
| Yam26 | my bad | 07:15 |
| _florent_ | np | 07:16 |
| Yam26 | This is at 1000MT/s when it is working https://pastebin.com/igeAMsuL | 07:17 |
| tpb | Title: 1000MT/s - working - Pastebin.com (at pastebin.com) | 07:17 |
| Yam26 | This is 1000MT/s when it is not working https://pastebin.com/Pud4iPQy | 07:17 |
| tpb | Title: 1000MT/s - not working - Pastebin.com (at pastebin.com) | 07:17 |
| Yam26 | And this is 800MT/s https://pastebin.com/fQV52L1L which is working like 95% of the time. | 07:19 |
| tpb | Title: 800MT/s working - Pastebin.com (at pastebin.com) | 07:19 |
| _florent_ | Yam26: The valid windows in the read leveling of m0 is not clean when not working | 07:24 |
| _florent_ | https://www.irccloud.com/pastebin/mLFbeeII/ | 07:24 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 07:24 |
| _florent_ | vs this when working: | 07:25 |
| _florent_ | https://www.irccloud.com/pastebin/tEAceNyy/ | 07:25 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 07:25 |
| Yam26 | yeah, I notice that. what do you think is the problem, why it is not clean. | 07:25 |
| _florent_ | this could be some wrong electrical setting on the FPGA side or LPDDR4 side | 07:26 |
| Yam26 | I see. | 07:26 |
| Yam26 | it's highly possible :-) | 07:27 |
| _florent_ | you can probably do some tests with different settings and see how it impacts the calibration | 07:28 |
| _florent_ | shenki: For LiteEth TX: The MAC has N slots, the software first checks if a slot is available, if so, it can fill the SRAM memory and then initiate the Xfer through the start CSR that will fill the slot FIFO. | 07:30 |
| Yam26 | Can you suggest the settings that I should try ? I read through LPDDR4 specification, it seems like I can do Vref calibration, but I don't think litedram is doing that. | 07:30 |
| _florent_ | The core then starts the Xfer when the slot FIFO is non-empty and free the slot when the Xfer is done | 07:31 |
| shenki | for recieve, how does the hardware know that the slot has been read? | 07:31 |
| leons | IIRC you clear the receive event | 07:32 |
| leons | shenki: What do you mean by writing a model? | 07:32 |
| _florent_ | For LiteETH RX, the core can only store the incoming packet if a slot is available | 07:33 |
| _florent_ | https://github.com/enjoy-digital/liteeth/blob/master/liteeth/mac/sram.py#L82 | 07:33 |
| _florent_ | If not slot available, the packet will just be discarded. | 07:33 |
| leons | https://github.com/enjoy-digital/liteeth/blob/master/liteeth/mac/sram.py#L132 | 07:33 |
| leons | There the receive packet is latched out of the FIFO, by clearing the event | 07:34 |
| shenki | leons: from software's perspective, once the memory region is read by the CPU the MAC knows the slot is free? | 07:36 |
| _florent_ | Yam26: are you basing your platform on this one? https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/antmicro_lpddr4_test_board.py | 07:38 |
| leons | shenki: no, you have to explicitly acknowledge the packet, like so: https://github.com/tock/tock/blob/6c0f73713d3abb7a0aedef422359e5a631bd7dab/chips/litex/src/liteeth.rs#L225-L227 | 07:38 |
| Yam26 | Yes, I was basing my platform termination based on that. | 07:39 |
| shenki | leons: acking the irq, ok | 07:39 |
| shenki | leons: that's good to know! thanks | 07:39 |
| _florent_ | Yam26: I'm not sure to know the current status at sys_clk_freq > 50MHz, it seems to be the default on this test hardware: | 07:40 |
| _florent_ | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/antmicro_lpddr4_test_board.py#L129 | 07:40 |
| shenki | leons: we have a qemu model to do CI for Linux on microwatt. I'm adding support for ethernet | 07:40 |
| _florent_ | https://github.com/antmicro/litex-rowhammer-tester/blob/master/rowhammer_tester/targets/lpddr4_test_board.py#L78 | 07:40 |
| leons | shenki: no worries. The driver I've sent you seems to work pretty well, but it's not really authoritative :) | 07:40 |
| leons | shenki: that's pretty cool! | 07:41 |
| leons | shenki: is that going to be upstreamed or published? | 07:41 |
| shenki | I wrote the Linux driver for liteeth, but it was a long time ago, so it seems I've forgotten some details | 07:41 |
| shenki | yeah, we will submit it upstream | 07:42 |
| leons | shenki: heh. Yeah, I was about to look into that. AFAIK the current LiteEth interface has a pretty significant weakness -- specifically it uses an event source pulse for TX (https://github.com/enjoy-digital/liteeth/blob/master/liteeth/mac/sram.py#L186) | 07:43 |
| _florent_ | Yam26: I'll try to have more information on the max validated sys_clk_freq with the LPDDR4 test board | 07:43 |
| Yam26 | _florent_ thank you | 07:44 |
| leons | Where it should really be an EventSourceLevel. When you enable timestamping that already is the case. The EventSourcePulse doesn't really allow you to simply determine how many packets have been sent by the HW, you have to work around that in SW using the level CSR and it as far as I'm concerned that gets ugly quickly | 07:44 |
| leons | As soon as LiteX has versioned register sets in peripherals, we could modify it to use an EventSourceLevel and have the Linux driver detect that automatically | 07:45 |
| shenki | leons: this means software doesn't know how many packets have been sent? | 07:45 |
| Yam26 | my board works fine at 50MHz, I'm pushing it. I need around 1000MT/s for my application. This is calculated assuming with 64 bits wide already. | 07:45 |
| leons | shenki: it can know, by knowing how many have been sent and what the contents of the level CSR are. But it would be much nicer to just couple the event to the source of the FIFO which the HW has anways | 07:46 |
| leons | That way you can in SW just loop until the event is deasserted | 07:47 |
| leons | and read a packet in every loop iteration. So the HW would tell you which slot to read. It would also make it possible to have an out-of-order send, for example when one would want to build a fancy LACP integration | 07:48 |
| leons | s/which slot to read/which slot is ready | 07:49 |
| shenki | I'm not following you completely. I do welcome improvements to the logic though! | 07:49 |
| shenki | If you want to add some documentation (or open an issue that describes your proposed improvement) I would be grateful | 07:49 |
| leons | I think it's an issue which has to first be solved on the HW side -- it would be a breaking interface change and we should introduce versioning into the register set by then | 07:50 |
| leons | Such that at least newer drivers could detect older HW | 07:50 |
| shenki | yeah, that is something we have to be careful of now that we have support in linux | 07:50 |
| leons | We're already stuck in the situation that older drivers will fail badly and silently on newer interfaces, because the current interface is not versioned. I think that's something we must improve on. Not every software can read in the SoCs header files and know what the registers look like. Sometimes you want to build your software ahead of time | 07:52 |
| shenki | Yeah. One way to mitigate this is to add new functionality to new registers below the current set | 07:52 |
| shenki | that won't always be possible of course | 07:53 |
| leons | I'm thinking of something like a 32-bit read-only register, of which the upper 16 bits are a counter for breaking changes and the lower 16 bits would be a bitmask of features the HW has | 07:53 |
| leons | shenki: yes, but changing the event handling in LiteEth would be an example of such a breaking change I think | 07:53 |
| leons | And IMHO at some point there should be a breaking change. We don't want to carry over legacy interfaces to the end of time... | 07:54 |
| shenki | yeah the bitmask idea is interesting. it would get messy; I'd prefer to collect up a set of improvements into a new major release of the gateware | 07:55 |
| shenki | the downside is that goes against the iterate quickly approach that we've been able to have so far | 07:56 |
| leons | There was an issue for that once, but if I remember correctly it didn't get much traction. florent, would you be open to revisiting that? | 07:56 |
| leons | As more drivers make it into upstream projects the problem is only going to get bigger | 07:57 |
| *** cr1901 <cr1901!~William@2601:8d:8600:911:70fb:6a50:fd5:35b3> has quit IRC (Read error: Connection reset by peer) | 07:59 | |
| shenki | another improvement to make would be to add DMA support to liteeth, instead of the CPU having to copy buffers into the SRAM | 08:00 |
| leons | Yup! All possible with a versioned interface :D | 08:01 |
| shenki | We can get about 30MBit on microwatt on the Arty currently. That goes up from ~20MBit with an optimised memcpy_io routine, so we're very much limited by copying packets in and out | 08:02 |
| _florent_ | leons: I'm OK with this direction. We first need to improve the CSR mapping inside a module to simplify adding/removing registers inside a Module with a common API. | 08:03 |
| _florent_ | https://github.com/enjoy-digital/litex/issues/548 | 08:03 |
| _florent_ | Then we could add an API version register | 08:03 |
| _florent_ | and update it each time the API is updated | 08:04 |
| _florent_ | For the hardware capabilities, we would have to see if this would need to be regrouped in a single register or it would be spread in the different registers | 08:05 |
| leons | Makes a lot of sense. Do you want me to look into the CSR mapping? | 08:08 |
| leons | Alternatively I would even be fine with putting the register set versions in a different register set, which people could disable if they so desire. Sort of a “peripheral discovery core”. But that might lead to even more fragmentation. | 08:08 |
| _florent_ | leons: Sorry if progress is this is slow on this, the scope if the project is very large and for now it's easier to have companies funding new features/customization than funding such evolutions/maintenance. I'm trying to get more people involved, but it can take time. | 08:16 |
| _florent_ | leons: If you have time to look at the CSR mapping, this could be very useful yes. | 08:17 |
| jevinskie[m] | Hmm the triple speed reference demo from intel which works fine with my 10/100 adapter doesn’t even use tx_clk, just gtx_clk. I wonder if I have to feed gtx a 125 MHz clock and give the PHY core a 25 MHz clock divided from that? | 08:39 |
| *** michalsieron <[email protected]> has joined #litex | 09:30 | |
| *** michalsieron <[email protected]> has quit IRC (Quit: michalsieron) | 09:37 | |
| *** emkat <emkat!~emkat@2001:67c:2564:518:9e7b:efff:fe46:1776> has joined #litex | 09:42 | |
| emkat | Is it possible to simulate other targets than the simsoc with lxsim? I'd like to simulate my own soc which contains custom hardware modules. | 09:45 |
| _florent_ | emkat: you can use lxsim as a basis and extend it with your custom modules | 10:07 |
| emkat | Should I do that by modifying litex_sim.py or is it possible to tell lxsim to use a different file? | 10:15 |
| *** futarisIRCcloud <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 10:16 | |
| *** cr19011 <cr19011!~William@2601:8d:8600:911:99af:ecfe:75f6:9ed5> has joined #litex | 11:33 | |
| *** Yam26 <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 12:09 | |
| _florent_ | emkat: For now youhave to modify litex_sim.py manually | 12:19 |
| emkat | _florent_: I just read the contents of lxsim and found out that it uses entry_points.txt to call litex.tools.litex_sim:main. So I think that means I can just copypaste litex_sim.py elsewhere, modify it as needed (but keeping the sim-related code) and run the main function, correct? | 12:22 |
| emkat | I have to go now, but thanks for your help! | 12:47 |
| *** emkat <emkat!~emkat@2001:67c:2564:518:9e7b:efff:fe46:1776> has quit IRC (Quit: Leaving) | 12:47 | |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has joined #litex | 12:53 | |
| Las[m] | Hi, I'm trying to package Litex with Nix, and I need to figure out the dependencies. Is there anything other than Migen and Verilator? | 12:54 |
| _florent_ | Las[m]: You can find the dependencies here: https://github.com/enjoy-digital/litex/blob/master/litex_setup.py#L19-L60 | 12:57 |
| _florent_ | And in the installation guide: https://github.com/enjoy-digital/litex/wiki/Installation | 12:58 |
| Las[m] | Thanks, _florent_ how come it depends on both nmigen and migen? | 13:03 |
| _florent_ | The Minerva CPU is written in nMigen and we are generating from nMigen sources when used in a design | 13:04 |
| Las[m] | Hmm, thanks! | 13:05 |
| *** alainlou <[email protected]> has joined #litex | 13:50 | |
| *** alainlou <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 14:13 | |
| *** alainlou <[email protected]> has joined #litex | 14:21 | |
| *** philpax_ <[email protected]> has joined #litex | 14:45 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Remote host closed the connection) | 14:55 | |
| leons | Las: I’ve done that already | 15:00 |
| *** mm001 <[email protected]> has joined #litex | 15:00 | |
| leons | Just now got all tests working as well | 15:00 |
| Las[m] | Leon: Wait where? | 15:00 |
| leons | https://github.com/lschuermann/tock-litex | 15:00 |
| leons | Doesn’t make sense to upstream to nixpkgs IMHO | 15:01 |
| leons | But I can offer to split out the packages into a non-Tock related repo this evening | 15:01 |
| Las[m] | Quite a coincidence | 15:01 |
| leons | It also features an updater script for the TOML-defined package versions | 15:02 |
| Las[m] | I'm going to upstream Migen FWIW | 15:02 |
| leons | That’s great, I think that makes sense | 15:02 |
| leons | But for all the LiteX packages, not so much | 15:02 |
| Las[m] | Where are those TOML-defined package versions? | 15:02 |
| leons | I have it on a staging branch currently. Only pushing to master once I’ve verified everything works. Let me upstream my local changes in a few hours | 15:03 |
| leons | s/upstream/push | 15:03 |
| Las[m] | Nice, thanks | 15:04 |
| leons | Does it sound good for you to just split out the LiteX package definitions in a separate repo? I worked hard on getting all the tests working with the package interdependencies using fixed-point function evaluation these past days | 15:06 |
| Las[m] | Yeah | 15:06 |
| Las[m] | wdym? Are you using something custom that isn't callPackage? | 15:06 |
| leons | I would rather concentrate our efforts on one repo instead of fragmenting everything :) | 15:06 |
| leons | I do use callPackage but there’s a ton of recursive dependencies for the check phase so I built a little magic to take care of it :) | 15:07 |
| leons | I don’t think it’s very relevant for the general LiteX channel, should we discuss this in a private chat once I’ve pushed it? | 15:08 |
| Las[m] | Sure. | 15:09 |
| leons | It’d be super great to have someone else involved as well, that means it’s going to be much better maintained :) | 15:09 |
| mm001 | Hi! I have a beginner question regarding LiteX UDP. Maybe someone can help me. I have a RV901T board, and can build rgmii_test.py and load it with ISE impact. I can ping the board. Now I would like to make very simple UDP transfer, without CPU. I have seen in the code that the UDP core has sink and source.valid/ready/data. Can I directly access these signals in rgmii_test.py? | 15:15 |
| mm001 | I have tested to wire the data[0] directly to the LED, just as a first test, like this: self.comb += platform.request("user_led").eq(ethcore.udp.rx.source.ready) | 15:16 |
| mm001 | This must be wrong, because as soon as I send an udp packet to the board, the board somehow "crashes", does not respond to ping anymore. | 15:17 |
| Las[m] | Leon: I'm having issues joining your room BTW. Not sure if there's some federation issue between your instance and matrix.org. | 15:30 |
| leons | mhm, there shouldn't be - using it with others just fine. Perhaps you can invite me to a room instead? | 15:30 |
| Las[m] | I have. | 15:30 |
| Las[m] | Can you not see it? | 15:30 |
| leons | Now I do and joined it :) | 15:31 |
| *** alainlou <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 15:42 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 16:06 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 268 seconds) | 16:12 | |
| *** Yam26 <[email protected]> has joined #litex | 16:27 | |
| *** Yam26 <[email protected]> has quit IRC (Quit: Client closed) | 16:33 | |
| *** dkozel_web <[email protected]> has joined #litex | 16:48 | |
| *** dkozel_web <[email protected]> has quit IRC (Quit: Client closed) | 16:57 | |
| _florent_ | mm001: you could used the LiteEth stream frontend: https://github.com/enjoy-digital/liteeth/blob/master/liteeth/frontend/stream.py | 16:59 |
| _florent_ | used/use | 16:59 |
| _florent_ | it's used here for example to upload DRAM data to UDP: https://github.com/360nosc0pe/scope/blob/main/peripherals/dma_upload.py | 16:59 |
| _florent_ | With LiteEthStream2UDPTX: https://github.com/360nosc0pe/scope/blob/main/peripherals/dma_upload.py#L44 | 17:00 |
| _florent_ | if you want to receive UDP data, you can use LiteEthUDP2StreamRX | 17:00 |
| _florent_ | you'll get a valid/ready/data stream with your UDP data | 17:01 |
| _florent_ | And you could do something similar to : self.sync += If(udp_rx.source.valid, leds.eq(udp_rx.source.data)) | 17:02 |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 17:29 | |
| *** pftbest <[email protected]> has quit IRC (Remote host closed the connection) | 17:35 | |
| *** pftbest <[email protected]> has joined #litex | 17:50 | |
| *** pftbest <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 17:55 | |
| *** pftbest <[email protected]> has joined #litex | 17:55 | |
| *** cr19011 is now known as cr1901 | 18:15 | |
| mm001 | Ok, thanks! I'll try that out. Can I put LiteEthUDP2StreamRX directly into the class RGMIITest? Or is the UDP in this class already connected to something else? | 18:39 |
| mm001 | Sorry, I'm still a bit confused about what is connected how etc... By the way, the rgmii_test.py also crashes without my changes when I send a udp packet to it. I guess that's normal? | 18:40 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 18:57 | |
| *** TMM_ <[email protected]> has joined #litex | 18:58 | |
| _florent_ | mm001: it's probably crashing because udp.rx.source.ready is not set to 1 | 19:13 |
| _florent_ | it should not crash with self.comb += ethcore.udp.rx.source.ready.eq(1) | 19:14 |
| _florent_ | I'll provide an example tomorrow | 19:14 |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 260 seconds) | 19:59 | |
| jevinskie[m] | @florent is the MII PHY core expected to work with a RGMII PHY if fed 25 MHz GTX clk? Or do I need to port the GMII PHY to altera ddr even though I’m only interested in 100 mbps mode right now? | 21:05 |
| *** futarisIRCcloud <[email protected]> has joined #litex | 21:30 | |
| *** alainlou <[email protected]> has joined #litex | 22:24 | |
| *** alainlou <[email protected]> has quit IRC (Client Quit) | 22:24 | |
| mm001 | @florent Just tested with self.comb += ethcore.udp.rx.source.ready.eq(1), still crashes on udp packet... | 23:04 |
| mm001 | (just for your info) | 23:04 |
| *** mm001 <[email protected]> has quit IRC (Quit: Leaving) | 23:12 | |
| *** mm001 <[email protected]> has joined #litex | 23:13 | |
| *** futarisIRCcloud <[email protected]> has quit IRC (Quit: Connection closed for inactivity) | 23:40 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!