hellslinger has quit [Remote host closed the connection]
fsasm has joined #yosys
m4ssi has joined #yosys
jakobwenzel has joined #yosys
strongsaxophone has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
strongsaxophone has quit [Ping timeout: 258 seconds]
dys has joined #yosys
vidbina has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined #yosys
X-Scale` is now known as X-Scale
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` has joined #yosys
X-Scale` is now known as X-Scale
Cerpin has quit [Ping timeout: 246 seconds]
mwk_ has joined #yosys
mwk has quit [Ping timeout: 246 seconds]
noopwafel has joined #yosys
fsasm has quit [Ping timeout: 272 seconds]
develonepi3 has joined #yosys
mwk_ is now known as mwk
Cerpin has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 260 seconds]
N2TOH_ has quit [Ping timeout: 265 seconds]
emeb has joined #yosys
vidbina has quit [Ping timeout: 258 seconds]
vidbina has joined #yosys
N2TOH has joined #yosys
fsasm has joined #yosys
[Ristovski] is now known as Ristovski
m4ssi has quit [Ping timeout: 240 seconds]
m4ssi has joined #yosys
citypw has quit [Ping timeout: 255 seconds]
m4ssi has quit [Ping timeout: 260 seconds]
ZipCPU has quit [Ping timeout: 240 seconds]
m4ssi has joined #yosys
rohitksingh has joined #yosys
ZipCPU has joined #yosys
strongsaxophone has joined #yosys
m4ssi has quit [Ping timeout: 265 seconds]
m4ssi has joined #yosys
vidbina has quit [Ping timeout: 240 seconds]
m4ssi has quit [Ping timeout: 240 seconds]
dys has quit [Ping timeout: 240 seconds]
az0re has quit [Remote host closed the connection]
C-M has quit [Quit: Lost terminal]
seraxis has quit [Quit: おやすみ]
seraxis has joined #yosys
seraxis has quit [Client Quit]
seraxis has joined #yosys
Sarayan has quit [Ping timeout: 272 seconds]
twnqx has joined #yosys
<twnqx>
hello. what does the message "ERROR: Multiple edge sensitive events found for this signal!" mean - edge sensitive events caused by said signal, or changing said signal?
<awygle>
i would assuming changing
<awygle>
since that's what would be an error
<twnqx>
me too, but there is exactly one in my code
<twnqx>
also, isn't it pretty common to have "always @(posedge a or posedge b)"? i am doing that all the time in xilinx ISE compiled stuff
<twnqx>
mostly in the form of "@(posedge reset or posedge clk)"
<mwk>
twnqx: your problem will be easier to diagnose if you show the relevant code
<mwk>
and what are doing? this code seems to synth fine here
<twnqx>
would that move progval into the sensitivity list as it's purely combinatorical?
<twnqx>
well, it's only a part or the total code
<twnqx>
yosys -p "synth_ice40 -top top -blif ./build/ledpwm.blif" ledpwm.v would be the command
<daveshah>
FWIW, you should always be doing `always @*` rather than `always @(signal)` for combinational always
<twnqx>
mh let me clean out the reset signal, which the 384 doesn't have anyway
<daveshah>
otherwise you can end up with horrible sim/synth mismatches
<daveshah>
although I don't think that's the bug here
<twnqx>
that would be news to me, used @signal since... forever, with no mismatches with synplify/iverilog/ISE ever
<twnqx>
but ok
<mwk>
twnqx: the code you pasted works for me with synth_ice40 (after adding a blackbox for LEDMASK)
<daveshah>
If you use @(signals) then in simulation it is only updated when those signals change - but in synthesis that is not the case, it is treated like @*
<mwk>
are you using current yosys?
<twnqx>
0.9
<twnqx>
not git head
<mwk>
could you give me an actual reproducible complete command line + file that causes the error, then?
<twnqx>
soon, need to finish removing dead code
<twnqx>
since i learned that 384s can't generate a power-on reset :(
<daveshah>
None of the iCE40s can
<twnqx>
how do you set initial values in registers then, using initital?
<daveshah>
Oh, they all have a power on reset in that sense - you can use initial or `reg x = initval`
<daveshah>
There isn't an explicit power on reset signal though
<daveshah>
Strictly speaking, all registers are set to 0 at power on, but Yosys can fake 1-initialised registers by wrapping them in NOTs
<twnqx>
yeah, i'll rather assume 0-initialized. it's not that bad.
<twnqx>
still need to figure out SB_IO usage for this
<twnqx>
nah, something is definitely wrong here
<twnqx>
... is verilog not case sensitive?
<mwk>
twnqx: can you please give me a testcase that reproduces the actual error that you're complaining about?
<mwk>
the code that you linked has a clear syntax error
* twnqx
headdesks
<twnqx>
sorry
<mwk>
and if I fix the syntax error, it synthesizes fine
<twnqx>
i was using a different copy in another user's directory, i was wondering why there was no error just now
<twnqx>
so i removed enough code to make it compile, just didn't notice
<twnqx>
is abc mandatory?
<mwk>
kinda
<mwk>
there are experimental abc-less flows
<twnqx>
so uh.. how do i make it find the abc binary?
<twnqx>
i just placed it in $HOME/bin
<mwk>
hmm
<mwk>
it should be called yosys-abc and be in the same directory as the yosys binary
<twnqx>
ah, so it's an issue with the gentoo ebuild :P ok, thank you, i'll look into building yosys the right way
<twnqx>
(who actually thinks that git pulling during compilation is a practical idea? compilation is absolutely sandboxes normally...)
<ZirconiumX>
twnqx: if you patch Yosys you can produce something that produces synthesis better than default but worse than ABC
<ZirconiumX>
Depends what you're targeting though
<twnqx>
i am just trying to figure out what i have to do to compile yosys in a fully sandboxed environment, that is, withoput network access
<twnqx>
and it seems that i have to just clone abc into the right place and check out the right revision
<ZirconiumX>
Yeah, basically.
<somlo>
twnqx: there's the ABCEXTERNAL environment variable you can use if you want to use your own ABC
<twnqx>
i noticed, but i'd still prefer to have the right revision
<twnqx>
easy anough to adobt the build script
<somlo>
the risc of course is that you've got an abc older than the minimum required by yosys -- so check the yosys makefile for the required (presumably "or later") abc commit ID
<tpb>
Title: Use flowmap instead of gate2lut in noabc modes by ZirconiumX · Pull Request #1691 · YosysHQ/yosys · GitHub (at github.com)
<ZirconiumX>
FlowMap is interesting, if a bit impractical.
<twnqx>
ahahaha and there's a typo in 0.9 that will make preparing the exact revision impossible :P (it's lacking the last character of the git commit)
<ZirconiumX>
Uh, git will accept it just fine I think
<twnqx>
sure, but since it checks for that exact revision, the check will fail
<ZirconiumX>
Which is why we generally don't use the releases as such
<twnqx>
well, the Makefile is pretty adamant about that exact revision (unless setting ABCREV to default)
<ZirconiumX>
Yeah, because ABC has no release system at all
<twnqx>
:) and that's a working ebuild
<twnqx>
now for the next hurdle... nextpnr
<ZirconiumX>
There was a recent PR to make building ECP5 much easier
<twnqx>
i just have an ince40 384
<twnqx>
ok, that's not drop-in compatible with arachne...
<ZirconiumX>
lp384?
<az0re>
How would everyone feel about a patch adding more precise source file location information to AST and RTLIL nodes? Specifically, AST node locations would be represented as {first_line, first_column, last_line, last_column}. I have used this in previous academic work and I think others might find it useful. The only problem is it touches rather a lot of code...
<ZirconiumX>
It would be a pretty wide-ranging change
<ZirconiumX>
You'd have to replace the parser, I think
rohitksingh has quit [Ping timeout: 265 seconds]
<ZirconiumX>
Maybe you can give Yosys good syntax error messages while you're at it :P
<az0re>
No, no need to replace the parser. Some modifications are necessary, but nothing really major. Mainly the YYLTYPE needs to be defined as a struct of four ints, and anything touching `linenum` needs to be changed to e.g. `location->first_line` or something better (like a precise file:column range).
rohitksingh has joined #yosys
<az0re>
> Maybe you can give Yosys good syntax error messages while you're at it :P
<az0re>
Heh, well, I've always thought Yosys's syntax errors are great. But maybe my perception is jaded by my experience with syntax errors using ABC... ;)
<ZirconiumX>
Try using Rust for a few months
<ZirconiumX>
It becomes your benchmark of compiler error quality
<az0re>
Some day I will, for sure
fsasm has quit [Ping timeout: 255 seconds]
<twnqx>
success! sometimes you just need to step back and clear your mind by doing something completely different.
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 240 seconds]
strongsaxophone has quit [Ping timeout: 265 seconds]
heijligen has quit [Remote host closed the connection]
N2TOH_ has quit [Read error: Connection reset by peer]