Wednesday, 2021-09-22

*** tpb <[email protected]> has joined #litex00:00
sajattack[m]<jevinskie[m]> "You could probably fit a "couple..." <- that's a nifty-looking board, maybe try emailing [email protected]01:05
*** mc6808 <[email protected]> has joined #litex02:27
*** Degi <[email protected]> has quit IRC (Ping timeout: 264 seconds)03:32
*** Degi <[email protected]> has joined #litex03:34
*** mc6808 <[email protected]> has quit IRC (Quit: Client closed)05:07
*** C-Man <[email protected]> has quit IRC (Ping timeout: 252 seconds)05:53
*** FabM <[email protected]/team/FabM> has joined #litex06:18
*** cr1901 <[email protected]:8d:8600:911:99af:ecfe:75f6:9ed5> has quit IRC (Ping timeout: 260 seconds)08:57
*** TMM_ <[email protected]> has quit IRC (Quit: - Chat comfortably. Anywhere.)10:10
*** TMM_ <[email protected]> has joined #litex10:10
*** C-Man <[email protected]> has joined #litex10:25
*** ilia__s <[email protected]> has joined #litex10:46
*** ilia__s <[email protected]> has quit IRC (Ping timeout: 256 seconds)11:04
*** cr1901 <[email protected]:8d:8600:911:ac7b:1555:3d5f:1f9f> has joined #litex11:33
*** benh <[email protected]> has joined #litex12:31
benh_florent_: Hi Florent ! Long time no see :-)12:31
benhAny idea why the tests are failing on this PR ?
_florent_Hi benh12:33
_florent_I'll look at this, thanks. I probably broke the no CPU case when adding the FIFO mode for the UART12:34
benh_florent_: yup, my PR fixes the generation but the test cases are somewhat failing :-)12:59
benhI also did a small PR for liteeth to support GMIIMII12:59
_florent_ok thanks13:00
leonsbenh: you mean 10/100Mbit/s speeds over GMII?13:00
leonsbenh: ah nevermind :)13:01
benhHrm ... so it looks like there are a number of issues with the definition for the wukong board in LiteX ...13:11
benhfor example the clock pin doesn't match the doc and examples :-)13:11
benhalso the FPGA is unfortunately a -1 speed grade13:11
benhwhich is problematic since GMIIMII requires a sysclk of 125Mhz, which might be difficult to attain with Microwatt at that speed13:12
benhis that a hard limit of the PHY ?13:12
leonsbenh: what do you mean by GMIIMII? I still don't understand :D13:13 didn't have an option to instanciate LiteEthPHYGMIIMII13:17
benhbtw, is that expected ?13:17
benhbuild/microwatt_0/wukong-a100t-vivado/microwatt_0.runs/impl_1/runme.log:WARNING: [DRC RPBF-3] IO port buffering is incomplete: Device port eth_mdio expects both input and output buffering but the buffers are incomplete.13:17
benhbuild/microwatt_0/wukong-a100t-vivado/microwatt_0.runs/impl_1/runme.log:WARNING: [DRC RPBF-3] IO port buffering is incomplete: Device port eth_mdio expects both input and output buffering but the buffers are incomplete.13:17
benhthere's also a pile of warnings about litedram IOBUF having no load on IBUF13:18
_florent_benh: I don't have the Wukong board but Melkhior here has been playing with it quite a bit IIRC13:28
_florent_benh: you can also probably restrict operation to MII mode on this board13:28
benhOk. Well there are definitely mismatches in the pin assignment between LiteX and the doc I got13:34
benhor example clock on M21 vs M2213:34
benhahhhh... QMTECH replied to me, it's a board "v2"13:35
benhclock has moved and CLOCK_DEDICATED_ROUTE FALSE is not needed13:35
leonsbenh: regarding the CPU clock speed, why don't you just let the PHY run in a different clock domain? GMII requires 125MHz given it's 8bit per cycle and you need 1Gbit/s13:36
leonsYour CPU can presumably run at much lower speeds, e.g. 50MHz if the clock domain crossing has a large enough buffer or you increase the data width13:36
leonsI'd advise you to look at the 32bit MAC data path PR by david-sawatzke13:36
benhbecause crossing clock domains with wishbone sucks :_)13:37
benhand afaik the clock passed to the PHY has to be the sys_clk no ? Unless there's a clock domain gap already inside liteeth ? I haven't looked in details13:38
benhit would be good indeed if the PHY had an async fifo to the MAC13:38
benhor MAC to buffers13:38
benhso that the wishbone interface can be in a different clock domain from the rest of the eth13:39
zypthat's already supported13:39
leonsThere is such a FIFO13:39
zypetherbone got a 32b datapath, so it can run down to 125/413:39
somlo_florent_: btw, PR 1040 is good to go as far as my ability to clean it up :) Please have a look and merge if you agree, whenever you get a chance13:40
leonsAnd if even running the MAC path at 125MHz has too tight timing for you, david-sawatzke and I have been working on 32 and 64-bit data path through the MAC (which then also allows running it with 10Gbit/s at 156.25Mhz)13:41
benhzyp: I'll have to look at the details, the stuff spat out by doesn't seem to support that13:41
benhleons: thanks, I think the MAC at 125 should be fine13:41
benhits the rest of the system that will probably struggle past 100 :-) we'll see...13:41
leonsbenh: look at mac/core.py13:42
benhI'll send another PR to add Wukong v2 support as well, but now bed time13:42
benhthanks I will13:42
*** ilia__s <[email protected]> has joined #litex14:05
mm001_florent_ I have finally managed to switch on and off the LED of the RV901T board using the with etherbone by putting the LED to a GPIOOut like in the colorlite example and using litex_server and the scripts. Now I would like to switch on and off the LED only by UDP data. Like you suggested on 2021-09-15, I used a LiteEthUDP2StreamRX, but it does not work yet. In the class BaseSoc, I defined udp_streamer = LiteEthUDP2StreamRX(14:26
mm001ip_address=convert_ip(""),udp_port=1122) then I add it with self.submodules.udp_streamer = ClockDomainsRenamer("eth_rx")(udp_streamer) and in the self.sync i do If(udp_streamer.source.valid, my_led.eq([0])14:26
*** ilia__s <[email protected]> has quit IRC (Ping timeout: 256 seconds)14:26
_florent_mm001: nice, I'm currently working on an example for this! I'll push it in a couple of minutes :)14:27
mm001however, I think I miss something. Is the LiteEthUDP2StreamRX connected? I guess not. I tried self.comb += self.ethphy.source.connect(udp_streamer.sink) but without success.14:27
mm001_florent_ GREAT!! Thanks a lot!14:28
mm001by the way, building with ethernet enabled gives a region overlap...14:29
mm001and if I remove self.add_ethernet, the ping response works, but only if I change the sys_clk to 133e6 like in
_florent_But now that I started looking again at the code after a > 5 years, I see things to improve, so I'm also improving some parts...14:30
_florent_mm001: I'll look at the region overlap, I fixed something similar a few days ago IIRC14:31
mm001_florent_ no problem. it's just difficult to start using LiteX without working examples, but I don't give up... :-)14:31
_florent_mm001: sure, we are trying to improve this14:32
mm001I don't understand yet what has to be connected to what and how. And every change needs a new build, just to see that it still does not work...14:33
mm001But anyway, it's great we have LiteX in the first place and thank you very much for all the work and putting it open source!14:33
mm001just another question: where are you going to push your example to?14:34
_florent_mm001: if you want to speed up iterations, you can also use litex_sim that has etherbone support14:44
mm001_florent_ ah, great, I'll have to have a look at litex_sim! 14:47
*** FabM <[email protected]/team/FabM> has quit IRC (Ping timeout: 264 seconds)15:01
_florent_make sure to update LiteX/LiteEth15:03
_florent_The interesting parts are:15:04
_florent_the UDPStreamer instance, providing you stream Endpoints from/to a UDP port15:05
_florent_and here you can see the latch of the incoming UDP RX data to use it to drive the leds:
*** TMM_ <[email protected]> has quit IRC (Quit: - Chat comfortably. Anywhere.)15:24
*** TMM_ <[email protected]> has joined #litex15:24
mm001_florent_ Thanks a lot! I think I understand what you did in those lines and I adapted it to take it into It does build without errors but I can't get the udp data onto the LED yet. I'll continue to try. Just to check that I'm doing everything right: In the file, I deleted the lines 87-91 (the LED Chaser) and in this place I added:15:53
mm001self.submodules.udp_streamer = udp_streamer = LiteEthUDPStreamer(udp=self.ethcore.udp, ip_address="", udp_port=1122)15:55
mm001self.comb += udp_streamer.source.ready.eq(1)15:55
mm001my_led = platform.request_all("user_led")15:55
mm001self.sync += If(udp_streamer.rx.source.valid, my_led.eq([0]))15:56
*** C-Man <[email protected]> has quit IRC (Ping timeout: 265 seconds)15:56
mm001_florent_ This should work, shouldn't it?15:57
_florent_mm001: If you are also adapting the udp port in the script, it should be fine yes15:58
mm001well, I just go to command line and test with:16:00
mm001echo -n '0' $pipe$ socat - -udp-datagram:
mm001and change with echo -n '1' to toggle the LSB16:01
mm001i can see the packet in wireshark...16:02
mm001the ip_address in the LiteEthUDPStreamer is the computer, right?16:06
mm001the board is at and the computer at
_florent_mm001: ok, i'll do a test on the RV901T16:17
_florent_mm001: regarding the compilation issue with ethernet, were you just testing: ./ --with-ethernet ?16:17
mm001_florent_: it was ./ --cpu-type=None --integrated-main-ram-size=0x100 --with-ethernet --build16:22
_florent_ok thanks I will look at it, we can probably allow the build, but this will not be something functional since --with-ethernet needs a CPU16:28
mm001_florent_ got it! i had to send 64 bytes in order to flush the fifo16:28
mm001my mistake. thanks! Yeah!! It works!16:28
mm001_florent_ am I right assuming the ip_address in LiteEthUDPStreamer is only for TX?16:32
_florent_mm001: in fact RX is also checking it:
_florent_mm001: but while looking at the code earlier I was wondering if we should really keep this check16:34
mm001_florent_: That means 'valid' is only 1 when the sender has the right address... 16:37
_florent_yes because with LiteEthUDPStreamer we want to create a link between the FPGA and Host16:38
_florent_for both TX and RX16:38
mm001Ok, got it. but that's easy enough to change...16:39
mm001thanks a lot!16:39
_florent_but if you just want to received UDP data, you can also just use the UDP port directly16:39
_florent_with udp.crossbar.get_port(udp_port, dw=8)16:39
_florent_and then use the udp_port.source16:40
mm001Ok, will try that16:42
mm001Would also be nice to find out why crashes on udp packet :-)16:43
*** michalsieron <[email protected]> has joined #litex17:17
*** michalsieron <[email protected]> has quit IRC (Client Quit)17:18
*** Martoni42 <[email protected]:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex18:12
Melkhiorbenh: yes the current support is for the V1 Wukong (w/o the on-board micro-sd)18:14
MelkhiorEthernet works for me as-is, but 1 GBiT is too fast for the soft-cores - so I plugged it into a 100 MBit switch, where it works perfectly 18:15
MelkhiorI only ever tried with VexRiscv, not microwatt, usually running them at 100 MHz18:17
*** ilia__s <[email protected]> has joined #litex18:27
*** C-Man <[email protected]> has joined #litex19:18
*** ilia__s <[email protected]> has quit IRC (Remote host closed the connection)19:20
*** ilia__s <[email protected]> has joined #litex19:21
*** geertu <[email protected]> has quit IRC (Ping timeout: 264 seconds)20:26
*** ilia__s <[email protected]> has quit IRC (Ping timeout: 256 seconds)20:34
jevinskie[m]I took a risk and got two of those arria 10 accelerator boards. I can remove the onboard ddr to get the pinout while the rest (e.g. pcie and dimm should be able to be probed externally, boundary scan to find the clocks, etc). Let’s hope I don’t get discouraged and give up :)20:49
*** Martoni42 <[email protected]:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 260 seconds)20:52
gatecatjevinskie[m]: ooh which ones, Microsoft ones?21:30
jevinskie[m] available here
tpbTitle: | Gidel (at
benhMelkhior: so what PHY do you instanciate for the ethernet ?21:49
benhbecause GMII_MII which is the "theorical" fit, asserts if you try to use a speed lower than 125Mhz... ah wait the assert is in gen.py21:49
benhso if you use directly in LiteX it won't assert, only when generating standalone cores21:50
benhMelkhior: how do you want me to add support for v2 ? a different target/platform or a --version argument to the existing one ?21:50
*** ilia__s <[email protected]> has joined #litex22:03
*** ilia__s <[email protected]> has quit IRC (Ping timeout: 256 seconds)22:09
benhzyp: as usual LiteX confuses me :-) How do you create a standalone liteeth wishbone slave at 125Mhz with a wishbone at a different freq (100Mhz) ?22:13
benhI can't quite see how that's put together22:13
benhzyp: I see how to pass a freq to LiteEthPHYGMIIMII constructor but it's just used to calculate timings for the detection, it doesn't do anything else, I assume the actual clock is coming from elsewhere ?22:15
benhzyp: I never understood how clocks work in LiteX...22:17
benhzyp: LiteEthPHYGMIIMII uses PulseSynchronizer and looks explicitely for "sys" ...22:21
benhzyp: ok I think  I get it .. the PHY is clocked externally, the MAC uses sys_clk, so I could have the MAC at 100Mhz and the PHY at 125Mhz, rigjt ?22:35
benhhowever in the middle I have LiteEthGMIIMIIModeDetection() which is the state machine that flips between GMII and MII, and this works by "measuring" the rx_clk from the PHY compared to the sys_clk22:35
benhnow, I can't quite get my head around the LiteX constructs in there, so I don't know how that FSM is itself clocked, that said, there's a 5% margin, we could in theory use a much bigger margin no ? Since there a 5x difference between MII and GMII clocks22:37
benhI'll try hacking that formula, I think I understand what it does, and use a much bigger margin, see how that works here22:42
benhbah.. .that might just work (and also work better for non integer sys_clk/125e6 ratios too)22:47
benh@@ -162,8 +162,8 @@ class LiteEthGMIIMIIModeDetection(Module, AutoCSR):22:47
benh         )22:47
benh         fsm.act("DETECTION",22:47
benh             update_mode.eq(1),22:47
benh-            # if freq < 125MHz-5% use MII mode22:47
benh-            If(sys_counter > int((clk_freq/125000000)*1024*1.05),22:47
benh+            # if freq < 125MHz-50% use MII mode22:47
benh+            If(sys_counter > int((clk_freq*1024*1.05)/125000000),22:47

Generated by 2.17.2 by Marius Gedminas - find it at!