Thursday, 2022-06-30

*** tpb <[email protected]> has joined #litex00:00
*** Degi <[email protected]> has quit IRC (Ping timeout: 255 seconds)02:24
*** Degi <[email protected]> has joined #litex02:26
cr1901_trabucayre: I don't have the bandwidth to undertake this now, but would you accept a Linux GPIO bitbang interface into openfpgaloader?03:51
*** cr1901_ is now known as cr190103:51
*** xenador77 <[email protected]/xenador77> has joined #litex04:00
*** swetland <[email protected]> has quit IRC (Quit: Connection closed for inactivity)04:08
trabucayrecr1901: there is already a discussion and a work to use libgpiod: maybe you can try and give your opinion? :)04:34
cr1901Ack, will do hopefully today or this week, thanks04:35
trabucayreThanks too!05:00
*** xenador77 <[email protected]/xenador77> has quit IRC (Remote host closed the connection)06:28
*** FabM <[email protected]:d604:103:600:181a:3be2:c2ef:e652> has joined #litex06:35
*** toshywoshy <[email protected]> has quit IRC (Ping timeout: 255 seconds)07:37
*** toshywoshy <[email protected]> has joined #litex07:37
*** TMM_ <[email protected]> has quit IRC (Quit: - Chat comfortably. Anywhere.)09:45
*** TMM_ <[email protected]> has joined #litex09:45
*** dklim <[email protected]> has joined #litex12:13
*** dklim <[email protected]> has quit IRC (Client Quit)12:13
*** nelgau_ <[email protected]> has joined #litex12:14
*** nelgau <[email protected]> has quit IRC (Ping timeout: 256 seconds)12:16
*** shorne <[email protected]> has quit IRC (Ping timeout: 246 seconds)13:28
*** shorne <[email protected]> has joined #litex13:28
*** Melkhior_ <[email protected]:e0a:1b7:12a0:225:90ff:fefb:e717> has joined #litex17:02
*** Melkhior <[email protected]:e0a:1b7:12a0:225:90ff:fefb:e717> has quit IRC (Ping timeout: 264 seconds)17:03
mithro@trabucayre Can you remind me what the colognechip is?17:13
tntw ?17:24
tpbTitle: GateMate FPGA – Cologne Chip (at
jevinskie[m]GateMate, your FPGA buddy :P
tntstill waiting for their linux toolchain ... it's been "coming soon" for months ...17:24
*** Shatur <[email protected]> has joined #litex17:29
Shaturpepijndevos[m]: opened a small PR to your crate:
*** Shatur <[email protected]> has quit IRC (Quit: Konversation terminated!)18:30
*** FabM <[email protected]/team/FabM> has quit IRC (Quit: Leaving)18:36
jevinskie[m]Starting to think I'm nuts... `self.submodules += stream.Pipeline(self.uart.sink, self.uart.source)` works for a sim uart loopback but `self.comb += self.uart.sink.connect(self.uart.source)` doesn't echo for me. Any ideas? I'm diffing the generated netlists now.18:43
trabucayretnt: using p_r with wine is working but definitely not the best way :-(18:45
trabucayregatemate is working with LiteX (no-cpu + no-uart, or no-cpu + uart), I have a PR for edalize too18:49
jevinskie[m]OK, so my issue is the order of assignments in the generated verilog. Using Pipeline `uart_uart_source_valid <= uart_uart_sink_valid` is the last assignment while using raw connect I get `uart_uart_source_valid <= uart_tx_fifo_source_valid;` as the last assignment18:51
tnttrabucayre: I don't have (and don't want) any 32b libs on my system ... if the vendor can't be bother to provide proper tools I'm not going to bother using their chips ...19:01
trabucayreMissing native pnr tools for linux is my regret... Yep19:04
trabucayreand emerge wine on my """old""" x230 take time...19:05
jevinskie[m]Bagh, if I do the connect in a stub submodule it works. What is going on with this signal assignment ordering? :(19:09
jevinskie[m]`class Dummy(Module):19:09
jevinskie[m]    def __init__(self, sink, source):19:09
jevinskie[m]        self.comb += sink.connect(source)`19:09
jevinskie[m]Hmm... if I force verilog generation with _print_combinatorial_logic_synth instead of _print_combinatorial_logic_sim it works...19:40
jevinskie[m]_florent_: any ideas?19:40
jevinskie[m]I forget the exact reason behind two different styles of verilog for synthesis and simulation. I know that yosys breaks up things differently for simulation for perf reasons:
jevinskie[m]Nvm, I was still testing with the dummy module. the sim vs synth verilog doesn't seem to be the issue19:52
zypjevinskie[m], sounds like you're trying to connect to endpoints that are already connected and seeing differing behavior depending on which connection gets emitted first in the verilog19:53
zypif so; don't do that, ensure the original connection doesn't happen first19:54
jevinskie[m]Doh, you're right. I should just instantiate the uart phy and not use add_uart19:55
jevinskie[m]I wonder if this id10t error can be detected at runtime?19:55
zypamaranth does error if you tried assigning the same signal from multiple modules -- one of the improvements it got over migen19:57
zyp(ask me how I know, I were the idiot :)19:58
*** Shatur <[email protected]> has joined #litex20:10
jevinskie[m]Thanks a bunch zyp! I wonder if a warning if there are > 2 (reset and combinatorial) assignments20:24
jevinskie[m]If you could emit a warning*20:24
zypno, in some cases it's what you want20:28
*** Guest59 <[email protected]:200:4400:65d0:20e1:15c6:7689:8b70> has joined #litex20:40
*** Guest59 <[email protected]:200:4400:65d0:20e1:15c6:7689:8b70> has quit IRC (Client Quit)20:42
*** Shatur <[email protected]> has quit IRC (Quit: Konversation terminated!)22:57

Generated by 2.17.2 by Marius Gedminas - find it at!