<daveshah>
the question is whether it is "valid" structural Verilog, but I don't think structural Verilog is actually a defined thing
<cr1901_modern>
that's the sysverilog spec?
<daveshah>
No, Verilog 2005
<daveshah>
I don't think it's a new feature
<daveshah>
let me check 01
<cr1901_modern>
Okay, I'm wrong then. Well, ISE doesn't accept that either
<daveshah>
Yeah, same example appears in 2001 too
<daveshah>
I'm surprised by that, it's quite a common pattern
<cr1901_modern>
That being said, note that your example is {a, b} = c + d + e;
<cr1901_modern>
ISE doesn't accept {a, b} = {c, d};
<cr1901_modern>
i.e. I think the destructuring on both sides is what it doesn't like
<daveshah>
That's even stranger
<ZirconiumX>
mwk: Why on earth did you decide to reverse engineer such a cursed compiler?
rohitksingh has joined #yosys
fevv8[m] has quit [Read error: Connection reset by peer]
nrossi has quit [Remote host closed the connection]
pepijndevos[m] has quit [Write error: Connection reset by peer]
promach3 has quit [Remote host closed the connection]
FSM_Dude has joined #yosys
<FSM_Dude>
Hey! Is there anyway here who develops/runs Yosys on a MacBook?
<daveshah>
It's definitely something some people do, don't think any of the core devs use macos though
<FSM_Dude>
Okay! I'm running into a problem since I updated Xcode / MacOS
<FSM_Dude>
I just ran make clean, and rebuilding everything to see if it might solve the issue
<ZirconiumX>
At risk of being snarky, it's difficult to help solve "problems"
<FSM_Dude>
I understand! I actually wanted to ask for help, then thought: maybe cleaning and rebuilding helps
<ZirconiumX>
Sure, but we still don't know what your problem is
<FSM_Dude>
If the problem persists, I'll let you guys know, and give a somewhat broader explanation what exactly goes wrong :)
<FSM_Dude>
Well, basically, when I ran fsm_recode -encoding binary, I get a Thread_Bad_Access
<FSM_Dude>
and then Yosys stops
<ZirconiumX>
This is already a lot more helpful
<ZirconiumX>
Can you post your code somewhere?
<daveshah>
If you don't get to the bottom of it quickly, running with valgrind (if that exists on osx) is often handy for this kind of thing
<ZirconiumX>
I think Valgrind has support for OS X
<FSM_Dude>
Cool, Ill look into it!
<FSM_Dude>
After rebuilding it still happens
<FSM_Dude>
I didn't change any code here
<daveshah>
It's possible that some latent bug has been triggered by a compiler/stdlib update
<ZirconiumX>
It wouldn't be the first bug we've had with fsm.
<FSM_Dude>
The Thread_Bad_Access seems to happen in register.cc
<FSM_Dude>
in Pass::call(RTLIL::Design *design, std::vector<std::string> args)
<FSM_Dude>
I'm fairly new to C++ and Yosys, so sorry for need being of great help...
<ZirconiumX>
Which line?
<ZirconiumX>
It'll say something like "register.cc:XXX"
<mwk>
ZirconiumX: well if it wasn't that cursed, I could perhaps actually use it instead of reversing it
<ZirconiumX>
...You have a point
<FSM_Dude>
line number 294 : pass_register[args[0]]->execute(args, design);
<FSM_Dude>
For now I guess, Ill switch to my linux machine :P
<mwk>
FSM_Dude: could you give us the verilog / ilang code that triggers the bug?
<FSM_Dude>
Can I post it all here?
<FSM_Dude>
Or how do I get the Verilog to you guys
<ZirconiumX>
Copy and paste it to gist.github.com
<ZirconiumX>
Don't paste it into IRC; it will be very spammy and difficult to use
<FSM_Dude>
Okay
<FSM_Dude>
Mind you, it's not my verilog code. Im a student trying to run a set of verilog benchmarks. I'm interested in building new state encoding techniques into Yosys and analyse the outcomes
<FSM_Dude>
To analyse, I use a set of benchmark verilog files :)
<ZirconiumX>
Sure, but anything that takes in Verilog is inevitably going to crash somewhere