eigenform has quit [Quit: No Ping reply in 180 seconds.]
eigenform has joined #amaranth-lang
<cr1901>
Can someone remind me how I request a diff input from an amaranth platform? Also how to request "single i/o pin where you're reading the value on posedge/negedge of the read clk"?
<d1b2>
<dragonmux> for a differential pin, as long as it's defined in the platform as a DiffPins(), then request like any other resource and enjoy Amaranth handling the differential nature under the hood for you
<d1b2>
<dragonmux> for a DDR pin, platform.request('resource', resourceNum, xdr = {'signal': 2}) where signal is the name of a given signal that should be 2:1 gearboxed, repeat for each signal in the resource you need like this
<d1b2>
<dragonmux> hehe, all good - the .sense signal this results in is the "positive" image of the signal and the inverted/"negative" form will be generated automatically as part of the resource's handling
<d1b2>
<dragonmux> rather.. handling for the inverted form will be generated automatically
<cr1901>
(AFAICT, platform.request() eventually creates a Pin, with some support circuitry surrounding it)
<d1b2>
<tnt> @dragonmux To continue here : cell \SB_LUT4 \U$$5 parameter \LUT_INIT 4'1000 connect \I0 \buffers_out [4] connect \I1 1'1 connect \I2 1'0 connect \I3 1'0 connect \O \buffers_in [0] end process $group_0 assign \buffers_in 5'00000 assign \buffers_in [4:1] \buffers_out [3:0] sync init end
<d1b2>
<tnt> IMHO the above is a bug. Either it hard errors out. Or is doesn't overwrite the output of the LUT with 0. But the current behavior is fucked up.
<d1b2>
<garbile> I'll stay out of this one 😄
<d1b2>
<garbile> I'm happy to run any tests you want with my setup if that happens to be helpful though
<d1b2>
<tnt> I think it's fine, now I see how it fails. But just the fact it took 30 min for the 3 of us to figure out WTF was going on IMHO proves my point the behavior is not what it should be and very un-intuitive.
<d1b2>
<garbile> Maybe a warning message somewhere?
<d1b2>
<tnt> As I said above. It should either error out / hard fail or do what you'd expect. You assign the o_O of an Instance to a signal and instead it wires it to a constant 0, like how could that possibly be what the user want to do ?
<whitequark>
tnt: talking about Yosys or Amaranth here?
<whitequark>
ah, I see, it's the combination of the two
<whitequark>
the way Yosys handles driver-driver conflicts is... not ideal. I tried arguing for changing it or at least warning and got told that it's basically not happening, many years ago
<d1b2>
<tnt> Given how Amaranth uses yosys, tbh, I'm not sure whose job it is to deal with it.
<whitequark>
you can reproduce this if you use Yosys with Verilog
<d1b2>
<tnt> Sure. But in verilog there is no implicit assignment of all the bits to 0.
<d1b2>
<tnt> Here defining buffers_in = Signal(5) and then trying to wire buffers_in[1:5] using normal Amaranth logic and buffers_in[0] as the output of an Instance generates a driver conflict without the user really writing one.