<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.
<trabucayre>
tnt: using p_r with wine is working but definitely not the best way :-(
<jevinskie[m]>
Indeed.
<trabucayre>
gatemate is working with LiteX (no-cpu + no-uart, or no-cpu + uart), I have a PR for edalize too
<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 assignment
<tnt>
trabucayre: 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 ...
<trabucayre>
Missing native pnr tools for linux is my regret... Yep
<trabucayre>
and emerge wine on my """old""" x230 take time...
<jevinskie[m]>
Bagh, if I do the connect in a stub submodule it works. What is going on with this signal assignment ordering? :(
<jevinskie[m]>
`class Dummy(Module):
<jevinskie[m]>
def __init__(self, sink, source):
<jevinskie[m]>
self.comb += sink.connect(source)`
<jevinskie[m]>
Hmm... if I force verilog generation with _print_combinatorial_logic_synth instead of _print_combinatorial_logic_sim it works...
<jevinskie[m]>
_florent_: any ideas?
<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: https://github.com/YosysHQ/yosys/pull/761
<jevinskie[m]>
Nvm, I was still testing with the dummy module. the sim vs synth verilog doesn't seem to be the issue
<zyp>
jevinskie[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 verilog
<zyp>
if so; don't do that, ensure the original connection doesn't happen first
<jevinskie[m]>
Doh, you're right. I should just instantiate the uart phy and not use add_uart
<zyp>
indeed
<jevinskie[m]>
I wonder if this id10t error can be detected at runtime?
<zyp>
amaranth does error if you tried assigning the same signal from multiple modules -- one of the improvements it got over migen
<zyp>
(ask me how I know, I were the idiot :)
Shatur has joined #litex
<jevinskie[m]>
Thanks a bunch zyp! I wonder if a warning if there are > 2 (reset and combinatorial) assignments