| *** tpb <[email protected]> has joined #litex | 00:00 | |
| jevinskie[m] | benh: how did tweaking the clock detection margins go? | 00:33 |
|---|---|---|
| jevinskie[m] | florent: did you have any ideas about cutting timing on the IP checksum? I thought about pipelining it and found this old RFC that implements it in GALs. I wonder if any universities still use GALs in their intro courses :) https://datatracker.ietf.org/doc/html/rfc1936 | 00:36 |
| tpb | Title: rfc1936 (at datatracker.ietf.org) | 00:36 |
| benh | jevinskie[m]: fixing another bug causing my stuff to break when I add liteeth (unrelated to litex) | 00:41 |
| benh | I don't think the above patch I pasted makes a difference since clk_freq is already a float | 00:43 |
| benh | thus I don't see why we realy on sys_clk being at least 125Mhz... it should work ok with lower sys_clk as long as the data path is larger than 8 bits no ? | 00:44 |
| benh | or am I missing something ? | 00:44 |
| benh | of course a real gigabit link will probably flood those tiny cores, especially with only 2 receive slots, no DMA and no pipelined wishbone | 00:45 |
| *** Coldberg <[email protected]> has joined #litex | 00:49 | |
| benh | unless I'm mistaken we can probably just remove the asserts in gen.py | 00:52 |
| *** C-Man <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 00:53 | |
| jevinskie[m] | I agree that I don’t think sysclk needs to be 125, since counting happens in eth_rx domain. Unless we’re both missing something :) | 01:14 |
| benh | yeah, I originally thought the above math would be wrong due to integer arithmetic rouding but then I figured clk_freq is probably floating point, I went back to the old code, regenerated with the 100/125 freqs and the resulting verilog looks fine | 01:17 |
| benh | anyways, I'll do more tests | 01:17 |
| *** Degi_ <[email protected]> has joined #litex | 03:30 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 03:30 | |
| *** Degi_ is now known as Degi | 03:30 | |
| benh | _florent_: what ever happened to the idea of having a way to "fix" the CSR layout for the sake of OS drivers ? | 04:40 |
| benh | _florent_: for example I can see today that the liteeth driver that went upstream hard wires the register layout | 04:40 |
| benh | _florent_: but the PHY part doesn't match what litex generated :-) because GMII_MII puts the Mode status register before the PHY reset and MDIO so everything is shifted | 04:41 |
| benh | _florent_: I have memories that we talked about having a way to specify "templates" via name/offset tables | 04:41 |
| benh | in fact, the stuff currently upstream doesn't work at all | 04:47 |
| benh | because the CSR banks are generated the other way around between MAC and PHY from the device-tree in Linux vs. what LiteX spat out | 04:48 |
| benh | so we have both registers inside the PHY bank changing depending on the PHY type (MDIO gets shifted around because the per-PHY-type stuff comes first) | 04:50 |
| benh | and we have the banks themselves flipping around | 04:50 |
| benh | jevinskie[m]: So just taking out those asserts in gen.py worked | 05:01 |
| benh | I have microwatt at 100Mhz with liteeth+GMII_MII (at 125) and packets are flowing fine | 05:02 |
| benh | (once I hacked to compensate for the CSRs moving around) | 05:02 |
| jevinskie[m] | Excellent! Good work :D | 05:05 |
| jevinskie[m] | I’m trying to figure out WTF is going on with the RGMII timing. I’m getting high nibble for byte X with the low nibble for byte X+Y. The dev kit ref project has bizarre clock / data skew - quartus puts max delay on the data ports and the data path is 0.2 ns longer than the clock path for rx_ctl. Is it accidentally pushing out the clock and data by a cycle? RGMII internal delay is off | 05:10 |
| jevinskie[m] | I’ve resorted to looking at the trace lengths. Luckily intel provides the PCB layout file for the max10 dev kit :) | 05:11 |
| benh | nah | 05:11 |
| benh | I spoke too soon | 05:11 |
| benh | it works if I force the link to 100Mb/s | 05:11 |
| benh | on the peer | 05:11 |
| benh | the mode detection seems to work (reading the CSR) when switching between 100 and 1000 | 05:11 |
| benh | but at 1000 I don't seem to get any packet | 05:11 |
| jevinskie[m] | Well at least the mux is working or stuck on MII xD | 05:12 |
| benh | :-) | 05:13 |
| benh | the driver tx count increments so the MAC thinks its sending | 05:13 |
| jevinskie[m] | Try hooking up litescope to tx/rx ctl/data and looking at something like an ARP packet and compare with wireshark (my current approach) | 05:13 |
| benh | the peer doesn't see the packets | 05:14 |
| benh | I'm not in LiteX, I'm in standalone mw, we don't have litescope | 05:14 |
| benh | but I can try a pure litex design at some point | 05:14 |
| benh | the mux works, the detection of 100 vs 1000 works | 05:15 |
| benh | I can change the peer speed with ethtool and it's properly reflected in the CSR that exposes the mode | 05:15 |
| benh | but no packets flow on the GMII | 05:15 |
| benh | I suppose I could at least check gtx with a scope | 05:17 |
| benh | jevinskie[m]: am I correct in my understanding that the "mode" argument to LiteEthPHYGMIICRG() constructor is fixed at generation time ? | 05:23 |
| benh | or it's a variable ? | 05:23 |
| benh | generating HW via migen/litex never agreed with my brain, I just can't read the stuff :-) give me verilog or vhdl anytime :-) | 05:23 |
| benh | trying to figure out how is gtx generated | 05:24 |
| jevinskie[m] | It’s a signal :) `mode = self.mode_detection.mode` | 05:26 |
| benh | jevinskie[m]: yes that I get | 05:38 |
| benh | jevinskie[m]: but the argument passed to LiteEthPHYGMIICRG() is actually: mode == modes["MII"] | 05:39 |
| benh | which is basically mode == 1 | 05:39 |
| benh | that baffles me ... I didn't think that would generate via some python black magic another signal behind a comparator | 05:39 |
| benh | but it seems to do | 05:39 |
| benh | oh well, I don't know why it doesn't work at this point, and I'm out of time | 05:40 |
| *** geertu <[email protected]> has joined #litex | 06:22 | |
| benh | hrm... LiteX is generating a bad PLL outside of operating ranges, Vivado barfs | 06:34 |
| benh | I'll have a look later | 06:34 |
| *** Coldberg <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 06:41 | |
| _florent_ | benh: The fixed CSR mapping is not yet in place, but we have been discussing it a few days ago: https://libera.irclog.whitequark.org/litex/2021-09-15#30842762 | 06:48 |
| tpb | Title: #litex on 2021-09-15 — irc logs at whitequark.org (at libera.irclog.whitequark.org) | 06:48 |
| _florent_ | i'll try to spend some time on it soon since this makes upstreaming drivers difficult | 06:50 |
| _florent_ | The current Eth PHYs probably have a CSR capabilities/mapping, so this can explain what you see when switching the PHY. This would be good to uniformize this for the same reasons | 06:51 |
| _florent_ | But we need https://github.com/enjoy-digital/litex/issues/548 first | 06:52 |
| _florent_ | jevinskie[m]: A way that can be convenient to debug your RGMII issue could be try a netboot and set software_debug to True: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1403 | 06:54 |
| _florent_ | This will disable the RX hardware checks and let the CPU handle them. The CPU will then also print the RX/TX packets that you can then easily compare with Wireshark captures | 06:55 |
| _florent_ | If you suspect an issue in RX, you can also create a minimal design with just the PHY + LiteScope and compare received packets with the ones from Wireshark | 06:56 |
| *** pftbest_ <[email protected]> has quit IRC (Remote host closed the connection) | 06:58 | |
| *** pftbest <[email protected]> has joined #litex | 06:58 | |
| *** FabM <[email protected]> has joined #litex | 07:16 | |
| jevinskie[m] | Yep I’ve taken the latter approach and am just looking at the RX bytes from the DDR inputs with litescope. I have some timing issue since the correct low nibbles are appearing in the next bytes low nibbles. High nibbles are also correct but paired with low data from the wrong cycle. I’m furiously drawing out timing diagrams and measuring path delays to the ddr input registers | 08:05 |
| jevinskie[m] | There is negligible trace skew, data and clock are all pretty close. I can’t route the rx clk pin to a PLL on this max10 so it seems all the skewing has to be done with timing constraints? I’m starting to think the reference project works by chance luck | 08:09 |
| *** Coldberg <[email protected]> has joined #litex | 09:25 | |
| benh | _florent_: thanks, I'll read those links ltr ! | 09:33 |
| benh | _florent_: I have neither Rx not Tx | 09:34 |
| benh | I'll do more experiments later, right now I'm trying to remove microwatt from the equation and adjusting LiteX own Wukong support to work on board v2 | 09:34 |
| benh | then I'll see if that works and if not we can debug further, such as using a pure GMII see if that works | 09:34 |
| benh | etc... | 09:35 |
| benh | _florent_: any idea what can cause LiteX to generate a bad PLL2 ? ie, with parameters out of range that cause vivado to barf | 09:37 |
| Melkhior | benh: one known bug in Wukong support is J10 and J11 definitions are swapped | 09:38 |
| _florent_ | benh: Passing a wrong speedgrade to the PLL could cause it | 09:38 |
| Melkhior | (my local copy has a bunch of other changes to support PS/2 and USB PMods) | 09:38 |
| _florent_ | or a wrong timing constraint at the input | 09:38 |
| _florent_ | benh, Melkior: BTW if there are different revision of the Wukong board, this could be worth adding revisions to the platform, as done in OrangeCrab for example | 09:40 |
| _florent_ | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/gsd_orangecrab.py | 09:40 |
| Melkhior | I don't have the new one to test :-( but that's probably the right way if it is very close | 09:53 |
| benh | Melkhior: ah good, I had started doing separate _io definitions for v1 and v2 thinking it was a difference between the two versions :-) | 09:58 |
| benh | Melkhior: I'll revert that and just fix it | 09:58 |
| benh | Melkhior: there's also a bad pin number in the differencial connector (jp something... I'll check later, looks like a typo) | 09:59 |
| benh | _florent_: so I added a --board-version parameter but I'll go look at orangecrab later | 09:59 |
| benh | also it spits out that PLL: | 10:00 |
| Melkhior | benh: never used the differential one so never checked it from the original submission | 10:00 |
| benh | .CLKFBOUT_MULT(6'd36), | 10:00 |
| benh | .CLKIN1_PERIOD(20.0), | 10:00 |
| benh | .CLKOUT0_DIVIDE(4'd9), | 10:00 |
| benh | .CLKOUT0_PHASE(1'd0), | 10:00 |
| benh | .CLKOUT1_DIVIDE(5'd18), | 10:00 |
| benh | .CLKOUT1_PHASE(1'd0), | 10:00 |
| benh | .DIVCLK_DIVIDE(1'd1), | 10:00 |
| benh | .REF_JITTER1(0.01), | 10:00 |
| benh | .STARTUP_WAIT("FALSE") | 10:00 |
| benh | ) PLLE2_ADV ( | 10:00 |
| benh | .CLKFBIN(s7pll_pll_fb), | 10:00 |
| Melkhior | benh: not sure what you mean? | 10:00 |
| benh | .CLKIN1(s7pll_clkin), | 10:00 |
| benh | .PWRDWN(pll_idelay_power_down), | 10:00 |
| benh | .RST(s7pll_reset7), | 10:01 |
| benh | .CLKFBOUT(s7pll_pll_fb), | 10:01 |
| benh | .CLKOUT0(s7pll_clkout0), | 10:01 |
| benh | .CLKOUT1(s7pll_clkout1), | 10:01 |
| benh | .LOCKED(pll_idelay_locked) | 10:01 |
| benh | ); | 10:01 |
| benh | which makes Vivado barf that VCO is out of range | 10:01 |
| benh | Yeah i just went through every IO pin :-) | 10:01 |
| benh | Melkhior: can you check if the FPGA is really a -2 speed grade ? | 10:01 |
| benh | mine is a -1 | 10:01 |
| benh | well, the PLL generated by LiteX for wukong is what I pasted above, and Vivado errors out at generation because the params cause VCO to be out of range | 10:01 |
| benh | I'll dig deeper later if you don't know off hand | 10:01 |
| Melkhior | it's a -2 on my board, I think V1 were all -2 | 10:02 |
| Melkhior | Didn't notice the new one is -1 :-( | 10:02 |
| Melkhior | should be easy to change that into a version-dependent parameter, I suppose | 10:03 |
| benh | sure, just checking :) | 10:03 |
| Melkhior | V1 is a XC7A100T-2FGG676I | 10:03 |
| Melkhior | On the website https://github.com/ChinaQMTECH/XC7A100T-200T_Wukong_Board/tree/main/User_Manual_XC7A100T | 10:05 |
| Melkhior | they claim the new one is the same for the A100T | 10:05 |
| Melkhior | Vivado barfs when configuring the FPGA or when generating the bitstream? In the second case i'ts weird as the Litex board file should say speed -2 so should be fine | 10:07 |
| Melkhior | enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv_smp/core.py | 10:07 |
| Melkhior | https://github.com/litex-hub/litex-boards/blob/f18b10d1edb4e162a77972e2e9c5bad54ca00788/litex_boards/platforms/qmtech_wukong.py#L173 | 10:08 |
| Melkhior | (wrong copy/paste at first :-) ) | 10:08 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 10:10 | |
| *** TMM_ <[email protected]> has joined #litex | 10:10 | |
| Melkhior | Also the Wukong targets use multiple PLLs to avoids dependency between the system clock, the idelay clock, and the Video clock for the HDMI framebuffer | 10:13 |
| Melkhior | I have the same PLL definition in my Verilog output, it's fine on my board | 10:16 |
| Melkhior | vivado 2020.1 | 10:16 |
| benh | Melkhior: no because I changed it to do speed -1 since that's what I have :-) | 10:22 |
| benh | I managed to live chat with one of the QMtech guys via Aliexpres "contact vendor" interface the other day | 10:22 |
| benh | he confirmed that they are supposed to be -1 | 10:22 |
| benh | he also confirmed that they aren't producing the A200T variant yet because the FPGA is too expensive | 10:23 |
| benh | while at it I suggested that they do a V3 with a dual FTDI so the jtag, wire and power can all be on the same cable like Arty :-) | 10:23 |
| benh | Vivado 2019.2 here | 10:24 |
| benh | I think it's a -1 vs -2 but I'll play around to check, probably not tonight though | 10:24 |
| benh | it barfs in DRC | 10:24 |
| benh | https://pastebin.com/HB2ULdNK | 10:25 |
| tpb | Title: ERROR: [DRC PDRC-43] PLL_adv_ClkFrequency_div_no_dclk: The computed value 1800.0 - Pastebin.com (at pastebin.com) | 10:25 |
| benh | interesting... I though 1800.0 was precisely the upper limit, maybe it's 1600.. | 10:25 |
| Melkhior | 1800 is the limit on -2 | 10:26 |
| benh | yup, 1600.00 is the limit on -1 | 10:27 |
| Melkhior | you can try by replacing the speedgrade on all PLL to -1, it should sort you out | 10:27 |
| benh | yeah I thought I had, must have missed it, anyways, I have to go, thanks for the advice | 10:28 |
| Melkhior | they should fix their documentation if they really produce with -1 :-/ | 10:28 |
| benh | I'll look again tomorrow and send a PR when v2 works | 10:28 |
| Melkhior | feel free to swap J10 and J11 for the V1 in the patch :-) | 10:28 |
| benh | actually I don't even know if mine is really a -1 or -2, it's one of those with a QR code only | 10:28 |
| benh | it doesn't say what the speed is on the package | 10:28 |
| Melkhior | I was thinking of getting a V2 for the embedded sdcard, but if it's a -1, no point, I'll keep mine and the pmod | 10:29 |
| benh | yeah and I'll fix the differencial connector too, it's clearly a typo since one pin ends up duplicated | 10:29 |
| Melkhior | Vivado HW MGR + JTAG should tell you quickly | 10:29 |
| benh | ah how can you tell from JTAG ? | 10:29 |
| benh | you mean using the vivado GUI ? yeah I would need to use a vivado compatible jtag probe | 10:29 |
| Melkhior | connect to it with the vivado hw manager, it should detect the chip and tell you what it is I think | 10:29 |
| benh | I'm currently using an olimex tinyh | 10:29 |
| benh | I have an old xilinx platform cable but with an annoying connector I don't have the right match for, and with the ccurrent covid lockdown, I can't really go shopping :-) | 10:30 |
| benh | ("jp3", " AF7 AE7 AD8 AC8 AF9 AE9 AD12 AC10", | 10:31 |
| benh | "AA11 AB11 AF11 AE11 AD14 AC14 AF13 AE13", | 10:31 |
| benh | "AD12 AC12"), | 10:31 |
| Melkhior | Got myself a "waveshare" compatible box from Amazon, 40€, works fine with both the Qmtech Wukong and the ZTex board (which has an embedded USB programmer anyway) | 10:31 |
| benh | that's the other bug I think... the AD12 in the first line should be AD10 | 10:31 |
| Melkhior | yeah, sounds plausible :-) | 10:32 |
| benh | ok. I ordered a xilinx "compatible" one from aliexpress too, it's somewhere between china and here... | 10:32 |
| Melkhior | never tried that connector... | 10:32 |
| benh | me neither, I jsut scrubbed the pins to find the diff between 1 and 2 | 10:32 |
| benh | anyways, gotta go, ttyl | 10:32 |
| Melkhior | bye | 10:34 |
| Melkhior | benh: turns out I misremembered, it seems Viv HW doesn't see the speedgrade through JTAG - or at least I can't find it in the interface :-( | 10:42 |
| *** ilia__s <[email protected]> has joined #litex | 10:44 | |
| *** ilia__s <[email protected]> has quit IRC (Remote host closed the connection) | 10:46 | |
| leons | Melkhior: If the Xilinx forums are to be believed, there is absolutely no way for the FPGA to know it’s own speedgrade. Apparently it’s only determined after manufacturing and not programmed back into the device. | 10:48 |
| Melkhior | leons: darn, that's not convenient when you have a heatsink on top of it... | 10:48 |
| Melkhior | thx for the info | 10:49 |
| benh | I'm making the speed grade an argument to the constructor | 11:21 |
| benh | with a default of -2 for v1 and -1 for v2 | 11:21 |
| benh | Melkhior: allright ... it builds now ... but nothing on serial if I try to run it :-) debugging will be needed, and that will be for another day | 11:36 |
| benh | hrm... I suppose it would help if I built it for the right board version =P | 11:37 |
| Melkhior | benh: hehe yes, in particular if the clock moved you're not going to get much :-) | 11:38 |
| benh | yup :-) | 11:38 |
| benh | ok it's up | 11:41 |
| benh | and I seem to be getting packets in the peer which is set to 1000bT | 11:43 |
| benh | though the "BIOS" says MII on the litex side | 11:43 |
| benh | which is .. odd | 11:43 |
| benh | that's definitely strange but not something for tonight ... whether I set the peer to 100bT or 1000bT, litex bios says MII (I verified when using gmii_mii in Microwatt standalone that the mode does switch properly there) | 11:47 |
| benh | if I look at it with mem_read of the CSR space I see it flipping ... odd | 11:49 |
| benh | that said, it shows that liteeth works fine with sys_clk at 100Mhz and rgmii_mii at gigabit speeds | 11:57 |
| benh | so the problem with microwatt is ... elsewhere (or timing) | 11:57 |
| benh | so as far as BIOS printing the wrong mode, that's because it doesnt' wait long enough after resetting the PHY | 12:00 |
| benh | if I sprinkle some eth_mode() here or there it eventually "adjusts": | 12:00 |
| Melkhior | benh: to improve reception you can set nrxslots to more than the default 2 in the add_ethernet of the targets, it should buy a bit of time for the core(s) to process packets (as far as I understand) | 12:49 |
| Melkhior | help if the traffic is 'bursty' | 12:49 |
| Melkhior | if it's sustained, you need faster cores :-) | 12:50 |
| benh | Microwatt isn't too bad for such a big beast :-) | 13:39 |
| benh | also with pipeline wishbone and my custom L2 cache we get | 13:40 |
| benh | Memspeed at 0x40000000 (Sequential, 2.0MiB)... | 13:40 |
| benh | Write speed: 84.7MiB/s | 13:40 |
| benh | Read speed: 117.0MiB/s | 13:40 |
| benh | on the wukong with standalone microwatt (not using LiteX infra, just the standalone eth/dram core + my stuff) | 13:40 |
| benh | as a comparison, the standard LiteX VexRiscV on the same board (both at 100Mhz) gives | 13:41 |
| benh | Memspeed at 0x40000000 (Sequential, 2.0MiB)... | 13:41 |
| benh | Write speed: 27.1MiB/s | 13:41 |
| benh | Read speed: 29.2MiB/s | 13:41 |
| benh | I think I might know what's wrong with GMII mode on my stuff, I think I hadn't ported over the clock & timing constraints for eth | 13:43 |
| benh | sometimes it would be nice to be able to tell Vivado to shut up | 13:45 |
| benh | WARNING: [DRC LUTLP-2] Combinatorial Loop Allowed: 1 LUT cells form a combinatorial loop. This can create a race condition. Timing analysis may not be accurate. The preferred resolution is to modify the design to remove combinatorial logic loops. This loop has been identified in the constraints as being known and understood by use of the ALLOW_COMBINATORIAL_LOOPS property on a net in the loop. The cells in the loop are: soc0/processor/execute1_0/random_0/ro_reg | 13:45 |
| benh | [63]_i_2. | 13:45 |
| benh | well, yeah, we used ALLOW_COMBINATORIAL_LOOPS on this on purpose | 13:46 |
| benh | yes, it's not deterministic... | 13:46 |
| benh | it's a bloody RNG :-) | 13:46 |
| benh | interesting... so MII/GMII switching etc.. works fine in LiteX+VexRiscV | 13:51 |
| benh | (using the bios to send/receive packets) | 13:52 |
| benh | with standalone microwatt however, I now seem to receive packets fine | 13:52 |
| benh | but I can't send | 13:52 |
| benh | ie rather it thinks it's sending but nothing lands on the peer | 13:52 |
| benh | I'll have to scope it I suppose | 13:52 |
| benh | smells like timing | 13:54 |
| benh | ah... | 14:16 |
| benh | build/microwatt_0/wukong-v2-a100t-vivado/vivado.log:WARNING: [Vivado 12-507] No nets matched 'eth_rx_clk'. [/home/benh/hackplace/microwatt-fusesoc/build/microwatt_0/src/microwatt_0/fpga/wukong-v2.xdc:472] | 14:16 |
| benh | build/microwatt_0/wukong-v2-a100t-vivado/vivado.log:CRITICAL WARNING: [Vivado 12-4739] create_clock:No valid object(s) found for '-objects [get_nets eth_rx_clk]'. [/home/benh/hackplace/microwatt-fusesoc/build/microwatt_0/src/microwatt_0/fpga/wukong-v2.xdc:472] | 14:16 |
| benh | build/microwatt_0/wukong-v2-a100t-vivado/vivado.log:WARNING: [Vivado 12-507] No nets matched 'eth_tx_clk'. [/home/benh/hackplace/microwatt-fusesoc/build/microwatt_0/src/microwatt_0/fpga/wukong-v2.xdc:473] | 14:16 |
| benh | build/microwatt_0/wukong-v2-a100t-vivado/vivado.log:CRITICAL WARNING: [Vivado 12-4739] create_clock:No valid object(s) found for '-objects [get_nets eth_tx_clk]'. [/home/benh/hackplace/microwatt-fusesoc/build/microwatt_0/src/microwatt_0/fpga/wukong-v2.xdc:473] | 14:16 |
| benh | if the constraints aren't applied that might explain | 14:16 |
| benh | ah the don't touch attributes on the eth_rx_clk/eth_tx_clk nets are getting lost in standalone mode | 14:25 |
| benh | hrm.. I wonder where that "keep" comes from | 14:32 |
| benh | something's adding a preiod constraint to those clocks, now to find whome... | 14:32 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Remote host closed the connection) | 14:54 | |
| _florent_ | benh: The keep attribute is automatically added when adding the period constraint on a signal | 14:54 |
| _florent_ | benh: We should probably add keep attributes in the generator to these signals | 14:55 |
| _florent_ | benh: Nice otherwise for the mem speed with pipeline wishbone and your L2 cache | 14:56 |
| benh | _florent_: yeah I'm debugging ... looks like add_ethernet() adds period constraints to the eth clocks but when using gen.py for a standalone core we don't get them | 15:05 |
| benh | _florent_: that's only part of the problem though :-) I need to make my xdc smarter at "finding" the signals... in litex they are all toplevel so the constraints work, with microwatt they are down the hierarchy so I need some smarter constructs | 15:05 |
| benh | _florent_: feel free to review my PR fixing up gen.py for ethernet but if you haven't merged yet I suggest you hold | 15:06 |
| benh | as I will have more fixes | 15:06 |
| benh | but feel free to comment :-) | 15:06 |
| benh | oh well, I have the constraints going through now and the problem remains... when used standalone, I get no packets outgoing to the wire at 1000bT | 15:32 |
| benh | works fine if I switch the peer to 100 and I can switch back/forth, it always work at 100 and never at 1000 | 15:32 |
| benh | the mode detection is working fine, I checked looking at the CSR | 15:32 |
| benh | and it seems to work with pure litex + vexriscv | 15:32 |
| benh | rx works but tx doesn't | 15:33 |
| benh | could be a problem with gtx... not sure | 15:33 |
| benh | gtx is an oddball DDROutput | 15:34 |
| *** hjimenez93[m] <hjimenez93[m]!~hjimenez9@2001:470:69fc:105::fe30> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has quit IRC (Read error: Connection reset by peer) | 16:02 | |
| *** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has quit IRC (Read error: Connection reset by peer) | 16:02 | |
| *** bluecmd <bluecmd!~bluecmd@2001:470:69fc:105::1d44> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** dmiller[m] <dmiller[m]!~dmillergn@2001:470:69fc:105::e9f6> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** OmkarBhilare[m] <OmkarBhilare[m]!~ombhilare@2001:470:69fc:105::4e51> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** willcode4[m] <willcode4[m]!~willcode4@2001:470:69fc:105::e1b3> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Write error: Connection reset by peer) | 16:02 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** jryans <jryans!~jryans@2001:470:69fc:105::1d> has joined #litex | 16:03 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #litex | 16:04 | |
| *** dcallagh <dcallagh!~dcallagh@2001:470:69fc:105::9c5> has joined #litex | 16:04 | |
| *** leons <leons!~leons@2001:470:69fc:105::abc> has joined #litex | 16:04 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has joined #litex | 16:04 | |
| *** a3f <a3f!~a3f@2001:470:69fc:105::41d> has joined #litex | 16:04 | |
| *** Las[m] <Las[m]!~lasmatrix@2001:470:69fc:105::74e> has joined #litex | 16:04 | |
| *** CarlosEDP <CarlosEDP!~carlosedp@2001:470:69fc:105::218e> has joined #litex | 16:04 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has joined #litex | 16:04 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #litex | 16:04 | |
| *** kaji <kaji!~kajiryoji@2001:470:69fc:105::405b> has joined #litex | 16:04 | |
| *** sajattack[m] <sajattack[m]!~sajattack@2001:470:69fc:105::1d9> has joined #litex | 16:04 | |
| *** david-sawatzke[m <david-sawatzke[m!~david-saw@2001:470:69fc:105::1634> has joined #litex | 16:04 | |
| *** dmiller[m] <dmiller[m]!~dmillergn@2001:470:69fc:105::e9f6> has joined #litex | 16:04 | |
| *** DerekKozel[m] <DerekKozel[m]!~dkozelgnu@2001:470:69fc:105::2f14> has joined #litex | 16:04 | |
| *** OmkarBhilare[m] <OmkarBhilare[m]!~ombhilare@2001:470:69fc:105::4e51> has joined #litex | 16:04 | |
| *** hjimenez93[m] <hjimenez93[m]!~hjimenez9@2001:470:69fc:105::fe30> has joined #litex | 16:04 | |
| *** vomoniyi[m] <vomoniyi[m]!~vomoniyig@2001:470:69fc:105::3023> has joined #litex | 16:04 | |
| *** willcode4[m] <willcode4[m]!~willcode4@2001:470:69fc:105::e1b3> has joined #litex | 16:04 | |
| *** bluecmd <bluecmd!~bluecmd@2001:470:69fc:105::1d44> has joined #litex | 16:04 | |
| *** yosys-questions <[email protected]> has joined #litex | 16:56 | |
| *** ilia__s <[email protected]> has joined #litex | 17:42 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 18:25 | |
| *** yosys-questions <[email protected]> has quit IRC (Quit: Client closed) | 18:35 | |
| jevinskie[m] | Well it’s common to clock a ddr bus with a ddr IO itself instead of a dedicated clock pin to reduce skew | 19:39 |
| jevinskie[m] | You just fix d_hi to 1, d_lo to 0 and clock and your 1x rate to generate a 1x clock | 19:51 |
| tnt | AFAIK it's not just common ... it's the recommended way. | 19:52 |
| tnt | "dedicated clock pin" is even often just referring to special input path and means nothing for output. | 19:52 |
| *** _franck_ <[email protected]> has quit IRC (Excess Flood) | 20:01 | |
| *** _franck_ <[email protected]> has joined #litex | 20:01 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 252 seconds) | 20:28 | |
| jevinskie[m] | My whole problem this whole time was I wasn’t taking into account that ALTDDIO has Xilinx’s SAME_EDGE behavior not SAME_EDGE_PIPELINED. Fixed with a delay register and now ARP core is getting the correct packet :) 🙃 | 20:33 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 21:09 | |
| *** TMM_ <[email protected]> has joined #litex | 21:10 | |
| *** yosys-questions <[email protected]> has joined #litex | 21:33 | |
| benh | jevinskie[m]: right, I got that, it's just the way the DDROutput is wired up is a bit funky :-) but it should work | 22:05 |
| benh | but for some reason something doesn't and so far I had no luck finding what .... packets are received fine but on tx nothing shows up on the peer | 22:06 |
| benh | and my scope isn't fast enough to probe the GMII :-) | 22:06 |
| jevinskie[m] | Now we’re in the same boat. Not that traces are even exposed. I’m sure it will end up being something simple, like how I haven’t done ddr constraints on tx yet | 22:20 |
| benh | My xdc constraints were bad (the net names weren't right) but fixing that didn't help | 22:41 |
| benh | I'll try a pure GMII without the GMII_MII mux later | 22:41 |
| benh | gosh, Xilinx are still assholes... | 22:41 |
| benh | so that Artix has the new QR code only marking, no speed grade visible... so I requested access to the QR code reading feature in the app | 22:42 |
| benh | and they rejected | 22:42 |
| benh | some mumbo jumbo about not being an authorized corporate goon | 22:42 |
| jevinskie[m] | Yep same here. 🙄 | 22:43 |
| benh | there is clearly not enough competition in the FPGA space ... :-) | 22:45 |
| *** yosys-questions <[email protected]> has quit IRC (Quit: Client closed) | 23:45 | |
| jevinskie[m] | tnt: cough erhmm that fixed the last issue with TX for me :D I’d have 2 ns of skew to figure out what to do with otherwise | 23:51 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!