<Degi>
I had "nmigen._toolchain.yosys.YosysError: ERROR: Parser error in line 5734: syntax error" when I tried to drive a signal from comb and sync
<Degi>
How do I tell YoSys that it should compile memories to sysMEM only on ECP5?
<Degi>
(The nMigen Memory())
<agg>
it already should, what's it doing?
<Degi>
Ah I see, I had a large memory with the read port in the comb domain, which it apparently didn't like
<agg>
for the first thing you should usually get a syntaxerror from nmigen saying "trying to drive (sig) from sync, but it is already driven from comb", suggesting something else is going wrong
<agg>
ah, yea, ecp5's brams can't be used as comb memory
<agg>
not sure if any fpga bram can for that matter
<mwk>
nope, none that I know of
<gatecat>
any bram is a comb bram if it's clocked fast enough
<gatecat>
*hides*
<agg>
haha
<agg>
i have definitely done that once >_>
<whitequark>
Degi: you can also use an attribute to force a memory to a BRAM
<whitequark>
ram_block=1
<whitequark>
Degi: regarding "ERROR: Parser error in line 5734: syntax error", please file an issue for the input that produces that, it's an nMigen bug
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #nmigen
<Degi>
Thanks!
<Degi>
Oh, for the nMigen input... That might be a bit hard to get, though I still have the build files
<d1b2>
<garbile> unfortunately, it doesn't seem to work anymore.
<d1b2>
<garbile> This file https://github.com/WRansohoff/rv32i_nmigen_blog/blob/master/rom.py causes this cryptic error: Traceback (most recent call last): File "/home/gk/src/gkrv/rom_sim.py", line 119, in <module> sim.run() File "/home/gk/.local/lib/python3.9/site-packages/nmigen/back/pysim.py", line 1064, in run while self.step(): File "/home/gk/.local/lib/python3.9/site-packages/nmigen/back/pysim.py", line 1053, in step self._settle()
<d1b2>
File "/home/gk/.local/lib/python3.9/site-packages/nmigen/back/pysim.py", line 1041, in _settle while self._delta(): File "/home/gk/.local/lib/python3.9/site-packages/nmigen/back/pysim.py", line 1031, in _delta process.run() File "<string>", line 3, in run TypeError: unsupported operand type(s) for &: 'tuple' and 'int'
<d1b2>
<garbile> And side note: installing nmigen_soc from pip gives an older version that doesn't define Arbiter among others. So I'm using the most recent version from GitHub
<d1b2>
<garbile> Any ideas? I don't know where to start. I've tried commenting out parts of the file to isolate what's causing the error, but I haven't been able to narrow it down
<vup>
@garbile (not sure this actually pings you), I just tried the code you linked and apart from a small change in the `Simulator` interface it just works on the lastest nmigen git version
<vup>
Oh also I am using python3.8, but I don't think this should make a difference
<d1b2>
<garbile> @vut What small change? (and yeah, it pinged me)
<d1b2>
<garbile> Hmm. Same error with that applied. Maybe there's a problem from using the Pip version of nMigen but the Git version of nMigen-SoC
<miek>
you should use the git version of nmigen, the current release is quite old
<vup>
I am pretty sure you are just hitting the bug you already linked in some place, but yes you should probably be using nmigen from git
<d1b2>
<garbile> I'll give that a try!
<d1b2>
<garbile> What's the difference between m-labs/nmigen and nmigen/nmigen repos?
<vup>
nmigen/nmigen is what you want
<vup>
currently m-labs/nmigen is a artefact of the past
<dragonmux>
vup: with that patch, you don't need top open() the VCD for nMigen - it'll take care of that for you as part of sim setup fwiw
<dragonmux>
(also, trailing ',' in the Simulator() call
<dragonmux>
)
<vup>
yeah I was just being lazy :P
<d1b2>
<garbile> Updating to the Git version worked! Thanks!
<dragonmux>
ok, fair.. just wanted to make sure you were aware (and garbile was too)
<vup>
sure
<Degi>
Somehow I get a "ERROR: Conflicting init values for signal 1'0 (\registers [42] = 1'0 != 1'x)." error in 2.11.7. in YoSys when I initialize a few values to a python int x or to a Const(x, shape=3) but with Signal(shape=3, reset=x) it works fine
<Degi>
(I copied the code this time in case it is a bug)