jjsuperpower has quit [Remote host closed the connection]
jjsuperpower has joined #amaranth-lang
jjsuperpower has quit [Ping timeout: 255 seconds]
jjsuperpower has joined #amaranth-lang
<cr1901>
This is a transparent dual-port mem I just simulated with the Python sim. I feel like the data read after the first clock tick is incorrect. It's reading from addr 2 instead of 1
<cr1901>
Can anyone else confirm that this looks incorrect?
<cr1901>
I would expect the read after the first clock tick to return 8, not fffff801
<whitequark[cis]>
is this with the latest amaranth checkout?
<cr1901>
Yes
<cr1901>
Just tried w/ c7da6c1292. (Previously HEAD was 11d5bb1)
<cr1901>
whitequark[cis]: If you think it's a bug, I can file an issue as the last thing I do before bed
<whitequark[cis]>
yep please do
<_whitenotifier-f>
[amaranth] cr1901 opened issue #930: Transparent memory using Python simulator reading from incorrect address when write occurred on previous cycle also - https://github.com/amaranth-lang/amaranth/issues/930
<cr1901>
whitequark[cis]: Done, going to bed. Or trying to
<whitequark[cis]>
thanks!
jjsuperpower has quit [Ping timeout: 260 seconds]
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
<Wanda[cis]>
cr1901: are you double sure you're not using outdated amaranth? I fixed this exact bug a few days ago, in c9416674d1e89b0537870d80588ee34b8cd12097
<Wanda[cis]>
no stale vcd files or something?
<Wanda[cis]>
... uh, okay, I can reproduce it, but wtf
<Wanda[cis]>
cr1901: okay, so what happened is
<Wanda[cis]>
your testbench is wrong because it doesn't use Settle
<Wanda[cis]>
but then you updated to the current HEAD and it still failed, because of the missing Settle
<Wanda[cis]>
either way, inserting yield Settle() right before the assert makes it pass on current main (and still fail before the fix commit) so I'm considering this a dup
MarekMaterzok[m] has quit [Quit: Idle timeout reached: 172800s]
<cr1901>
Ahhh. I thought Settle() was for comb-only testbenches.
<whitequark[cis]>
there's an open RFC fixing this
<Wanda[cis]>
cr1901: so, should the issue be closed?
<cr1901>
Wanda[cis]: I'm trying to confirm now, but "pdm update"/my internet is being a bit dodgy, so gimme a few mins
<cr1901>
Wanda[cis]: Yes, can be closed
<_whitenotifier-f>
[amaranth] whitequark closed issue #930: Transparent memory using Python simulator reading from incorrect address when write occurred on previous cycle also - https://github.com/amaranth-lang/amaranth/issues/930
<cr1901>
Before a90bc7b91a5a4/#915 was merged, this code ran without error. As of #915 however, I get "Cannot connect several output members 'arg0.action', 'arg1.action' together". Is this a bug, or was my code never supposed to work?
<cr1901>
And if the latter, what can be improved about this toy example to indicate "I am forwarding an interface to an inner module, and I want glue code to connect() to only part of the interface exposed by the Forwarding module"?
<whitequark[cis]>
you're missing a flipped
<cr1901>
On which argument to connect do you suggest I put the flipped()? We can discuss whether I'm nesting too deep, but it's not clear to me that self.datapath.pc.ctrl.action should be "Out"
* cr1901
tries to work through it
<whitequark[cis]>
well if the code worked, and the commit changed whether a flipped signature creates a flipped interface, and you want it to keep working, you need to flip the interface
<cr1901>
Okay, but I still don't understand why "self.fwd.periph.ctrl.action" is Out().
<cr1901>
The first and third return SignatureMembers(..), and the second one prints SignatureMembers(..).flip()
<cr1901>
When I access self.fwd.periph.ctrl, it returns "self.fwd.periph.ctrl SignatureMembers({'action': Out(<enum 'MyAction'>)})". Why didn't the flip() in self.fwd.periph return "SignatureMembers({'action': In(<enum 'MyAction'>)})"
<cr1901>
?
<whitequark[cis]>
(will look at later)
<cr1901>
No rush. I just wanted to ask while it was fresh in my head. For now, I'll connect manually (which also works in the actual application).
mcc111[m] has joined #amaranth-lang
<mcc111[m]>
Interesting
<mcc111[m]>
I got Amaranth to emit Verilog that Quartus can't parse
<whitequark[cis]>
Quartus is one of the less tested backends
<whitequark[cis]>
this is very possible
<whitequark[cis]>
I had to add a few hacks for it specially
<Wanda[cis]>
... Verilog actually does forbid an empty case
<Wanda[cis]>
I hate this language
<Wanda[cis]>
in all versions, up to SV 2017
<adamgreig[m]>
one weird trick to make code generators hate you
<Wanda[cis]>
galibert[m]: as in, in amaranth? there is no such thing as rw port, you simply do a read port + a write port with the same address and rely on synthesis tool to match them up
<adamgreig[m]>
or in your case two read ports and one write port
<galibert[m]>
Yeah in amaranth. Can it see that I’ll do a read or a write but never both at the same time ?
<Wanda[cis]>
yosys can
<Wanda[cis]>
as for other tools uhhh.
<Wanda[cis]>
(yosys literally asks a sat solver to make sure)
<mcc111[m]>
I'm gonna go eat dinner, if any more information is needed lmk in the issue
<Wanda[cis]>
btw "never both at the same time" is not the only recognized pattern; eg. Xilinx and ECP5 can also do "either read+write, read, or nothing, but not just write without read" and yosys can also recognize that pattern
<Wanda[cis]>
mcc111: I already have more than enough information to deal with this bug