cr1901 has quit [Killed (NickServ (GHOST command used by cr1901_!~cr1901@2601:8d:8600:911:40ab:efe6:2026:d4c2))]
cr1901_ is now known as cr1901
kristianpaul has quit [Ping timeout: 265 seconds]
kristianpaul has joined #yosys
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ has joined #yosys
singham has joined #yosys
<singham>
Is there a list of non-synthesizable features of Verilog for yosys, nextpnr somewhere?
josuah has quit [Ping timeout: 268 seconds]
josuah has joined #yosys
Raito_Bezarius has quit [Read error: Connection reset by peer]
Raito_Bezarius has joined #yosys
<singham>
Anyone?
<singham>
I ask because in simulation, I'm getting the right results
<singham>
But flashing on my iCE40 board, I get nothing
<singham>
If you've faced such issues, any help will be appreciated
<tnt>
You will get warning for anything that's non-synthesizable.
<tnt>
However sim mismatches are a MUCH wider set than non-synthesizable ...
<tnt>
Post your code somewhere ...
<singham>
It's big
<singham>
How can I see sim mismatches?
<tnt>
Well then hire someone ... but there is no way we can give you a full digital design course over IRC ...
<singham>
I mean in verilog there is synthesizable code right
<singham>
So as long as I write synthesizable verilog, sim should equate synth right?
<singham>
I have done a course on digital electronics, and a course on verilog from IIT KGP on hardware modelling
<jix_>
singham: there's IEEE 1364.1 which defines some synthesizable verilog, but it's much more conservative than what's used in practice and there's no equivalent for systemverilog AFAIK, but even for that restrictive subset there are sim mismatches
<singham>
The paper is paid
<singham>
Is there a list of accepted verilog keywords in yosys
<tnt>
synthesizable != deterministic you can write verilog that's synthesizable but that has behaviors "left to the implementation" and so the sim and synthesis tool are free to take different choices.
<tnt>
And that's excluding all the "real world" things that can change real behavior from sim ( unstable clock / hw limitations / any "external device and IO timings / real world delays / ... )
<singham>
Yes, but the net effect should be same right?!
<singham>
Lowering clock frequency should get rid of those issues, shouldn't it?
<jix_>
even _excluding_ all that, you still can have synthesizable verilog with sim mismatches
<jix_>
if you suspect the issue actually is such a mismatch, you can try to see if you can reproduce the issue with a post synth simulation
<singham>
I think, then, those are the issues with simulation and synthesis tools
<singham>
Any HDLs should go towards perfect simulation and reasonably good synthesis such that final logic is delivered.
<jix_>
it's an issue of verilog itself really, if you follow the standards you can still get mismatches for perfectly valid verilog
<singham>
if there's an if else statement within always block, does it need begin end
<singham>
always @(posedge clk) if foo this; else that;
ec has quit [Ping timeout: 255 seconds]
<singham>
Is this syntactically correct or
<singham>
always @(posedge clk) begin if foo this; else that; end
<singham>
Above format is needed?
<tnt>
If it was not syntactically correct, it wouldn't have built.
ec has joined #yosys
<jix_>
singham: If you're looking for help, I'd really recommend you try to reproduce the issue with a design that you are willing to share.
<singham>
tnt: Alright
<singham>
It is over 7 files.
<singham>
How can I share it?
<jix_>
upload it somewhere public (e.g. github or a pastebin) and share a link
<tpb>
Title: Michael Schröder / xv6-riscv-fpga · GitLab (at gitlab.com)
<jix_>
so this is not your own code? given that this was developed using yosys and seems to be working fine for the author, I'm fairly confident that the issue has nothing to do with what yosys and nextpnr are doing
<singham>
That is the assumption, but since I was unable to reproduce it on my board, I'm trying to debug it.
<singham>
You see, I'm on the 4th stage of what you're suggesting
<singham>
jix_ and tnt Thanks folks. I will leave for now.
singham has left #yosys [#yosys]
bjorkintosh has quit [Ping timeout: 276 seconds]
jix_ is now known as jix
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #yosys
bjorkintosh has joined #yosys
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
DiffieHellman has quit [Ping timeout: 255 seconds]
DiffieHellman has joined #yosys
<tnt>
Is there an attribute to prevent yosys from recoding a FSM ?
<jix>
tnt: untested, just from looking at the source: (* fsm_encoding = "none" *)
<tnt>
jix: tx !
so-offishul has joined #yosys
so-offish has quit [Ping timeout: 250 seconds]
so-offishul has quit [Ping timeout: 268 seconds]
so-offish has joined #yosys
so-offishul has joined #yosys
so-offish has quit [Ping timeout: 276 seconds]
adjtm has joined #yosys
cr1901_ is now known as cr1901
so-offishul has quit [Quit: Leaving]
so-offish has joined #yosys
<so-offish>
Sup ya'll
<corecode>
y'all*
<so-offish>
Sup y'all* ty
cr1901 has quit [Read error: Connection reset by peer]
adjtm has quit [Read error: Connection reset by peer]
cr1901 has joined #yosys
<bl0x>
Sup all y'all o/
<so-offish>
hi!
<so-offish>
Ok, I can officially crash nextpnr reliably. I am willing to go build it from source and turn on all debug options - is there a certain build option that would provide a log for the devs or anything? (nextpnr-ecp5)