<jeremyh_>
21:01 <esden> I have another minor example question. Is there some description of how to use get_tristate and handle bidirectional pins?
<jeremyh_>
21:15 <vup> esden: If you have a platform definition with a Resource defined as "oe", you can just `pin = platform.request("...")` it and you get back something with a `pin.o` and a `pin.oe`
<jeremyh_>
21:16 <vup> now for bidirectional pins its the same, just with the direction defined as "io" and in addition to `pin.o` and `pin.oe` you get a `pin.i`
<jeremyh_>
21:17 <esden> So get_tristate is only used internally then?
<jeremyh_>
21:18 <vup> I think so, but not sure
<d1b2>
<Darius> ahah
<d1b2>
<dragonmux> yeah, that 'driving with z' thing "works" but may not do what you want it to - it's made of pitfalls as modern FPGAs don't have 'z' (undriven)
<d1b2>
<Darius> yeah it only works for IOs
<d1b2>
<Darius> I think inside the FPGA it gets turned into a MUX
<d1b2>
<Darius> but, tool dependent like you say
<d1b2>
<dragonmux> as you're dealing with a physical resource, the it'll always work way is to describe the pins as what they are (inputs, outputs, in-out, output + enable) for a given pin using the dir keyword argument
<d1b2>
<dragonmux> then read the physical state with .i, drive the output with .o and set the direction with .oe
<d1b2>
<dragonmux> as for it working for IOs @Darius - uh.. so.. mm, kinda - yosys doesn't really support z, it works if you get the description just so because internally it rewrites it to $tribuf (IWRC), but it's not actually supported otherwise
<d1b2>
<Darius> ahh right..
<d1b2>
<dragonmux> in-FPGA it causes.. issues..
<d1b2>
<Darius> probably best to ignore me then 😄
<d1b2>
<dragonmux> it's always better in Verilog to use the device's pin IO primitive and deal with the in, out and oe + pad io signals as this will always map correctly by virtue
<d1b2>
<dragonmux> you can probably get away with asking yosys for its virtual tristate buffer primitive too if you know what toolchain your code is always going to be put through
<jeremyh_>
I got it working:)
<jeremyh_>
i have an FTDI FIFO blinky now
<d1b2>
<dragonmux> noice 🙂
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #amaranth-lang
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #amaranth-lang
cr1901 has quit [Remote host closed the connection]
<_whitenotifier-8>
[amaranth] whitequark closed issue #603: RTLIL sync rules are Verilog-specific and should not be emitted - https://git.io/JSTjE
<_whitenotifier-8>
[amaranth-lang/amaranth] whitequark pushed 1 commit to main [+0/-0/±1] https://git.io/JSTju
<_whitenotifier-8>
[amaranth-lang/amaranth] modwizcode 5a4d45b - back.rtlil: avoid sync process emission in RTLIL.
<_whitenotifier-8>
[amaranth] whitequark closed issue #672: Amaranth FSM does not allow asynchronous reset - https://git.io/Jy4dW
<_whitenotifier-8>
[amaranth] whitequark closed pull request #667: back.rtlil: avoid sync process emission in RTLIL. - https://git.io/JDi3N
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] whitequark pushed 1 commit to main [+0/-0/±27] https://git.io/JSTj9
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] whitequark 79dd44b - Deploying to main from @ amaranth-lang/amaranth@5a4d45b59993206fcc3590cf74ae78c4fba55fe8 🚀
<_whitenotifier-8>
[amaranth] whitequark commented on pull request #667: back.rtlil: avoid sync process emission in RTLIL. - https://git.io/JSkeI
nelgau has joined #amaranth-lang
nelgau has quit [Ping timeout: 245 seconds]
<nickoe>
Hi. I know this chan is not for migen, but in the migen simulation keyword "yield" is there to take data from the simulation do the python script. Is there a limite on the data type for this statement? I am trying to simulate a pipeline that returns with a datawidth more than 32 bits -- specifically 39. bit, but it appers that the data type python sets on the result is just 'int', which I guess are only 32 bit as it looks like the data I
<nickoe>
get out of this is truncated.
<whitequark>
the Python `int` type is arbitrary width
<d1b2>
<dragonmux> yield is a Python keyword used to build generators, there are no limits on the data type passable in either direction using this keyword
<whitequark>
>>> 1<<64
<whitequark>
18446744073709551616
<whitequark>
<class 'int'>
<whitequark>
>>> type(1<<64)
<whitequark>
your data is being truncated elsewhere
<nickoe>
a bit ood then. I will try to slice it in the sim and wire it up in two signals and see if it looks as expected.
<nickoe>
Given I don't really intend to use that data width in the end... it is just how the module I am testing has it now.
nelgau has joined #amaranth-lang
nelgau_ has joined #amaranth-lang
nelgau_ has quit [Remote host closed the connection]
<nickoe>
just a note, I do see the expected signed data in the vcd of the sim, so I guess it is only as test bench issue here that I need to understand.
nelgau has quit [Ping timeout: 256 seconds]
<nickoe>
ohh, great! PEBKAC again as expected. Probably caused by an undo to much. When I first realized that I didn't have the same output width as input width I corrected it in the module, but somehow the output signal that I used my actual module simulation DUT was too narrow. :)
<nickoe>
And thank you for your input
nelgau_ has joined #amaranth-lang
nelgau_ has quit [Remote host closed the connection]