clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
meawoppl has joined #yosys
<meawoppl> greeting humans
<meawoppl> anyone around in here?
citypw has joined #yosys
<meawoppl> anyone alive?
<meawoppl> I am looking for some help with nextpnr, does this channel do that?
mangelis has quit [Ping timeout: 240 seconds]
meawoppl has quit [Remote host closed the connection]
meawoppl has joined #yosys
<meawoppl> When I get assertion failures in nextpnr, is this the place to talk about them?
<sorear> either here or ##openfpga
<sorear> but if you can’t stay online for more than 50 minutes you may have better luck with email or github issues
<sorear> idk who else is awake at this hour
<ZipCPU> At least the channel is recorded, so there is a chance he might see that someone responded to him
<meawoppl> I'll give it a go tomorrow AM when i reboot into linux again, until then i am stuck with the windows toolchain :/
<sorear> Nearly certain nextpnr supports Windows
Jybz has joined #yosys
meawoppl has quit [Remote host closed the connection]
FabM has joined #yosys
FabM is now known as FabM_cave
dys has joined #yosys
m4ssi has joined #yosys
fsasm has joined #yosys
d0nker5 has quit [Ping timeout: 250 seconds]
d0nker5 has joined #yosys
develonepi3 has joined #yosys
meawoppl has joined #yosys
<meawoppl> so, if I am having an assertion fault in nextpnr, what do I share to reproduce it? a .json and the flags I used?
<meawoppl> I basically seem to seg-fault nextpnr anytime I use a module with parameters
<ZirconiumX> What are you using to synthesise for nextpnr? Yosys, right?
<meawoppl> yosys, yes
<ZirconiumX> Given that using a module with parameters is amongst the most common Verilog operation, I suspect it's not the problem here
<ZirconiumX> The JSON, the assertion error, that command lines of both Yosys and Nextpnr and possibly the input HDL
<meawoppl> gotcha, I will reboot into linux land in a bit post those here
<meawoppl> they are specifically related to the ice40 builtin modules (tristate buffers and led driver) if that helps any
<ZirconiumX> Not as such
<whitequark> are your nextpnr and yosys up-to-date?
<meawoppl> yeah, I built both from source this week
<meawoppl> I also made a .deb for nextpnr, and I am tempted to roll a ppa for all these tools to make them apt friendy
<meawoppl> aiit, power-cycling to linux, brb
meawoppl has quit [Remote host closed the connection]
pie_ has quit [Ping timeout: 265 seconds]
meawoppl has joined #yosys
<meawoppl> heyo, I got caught in windows update land :/
<meawoppl> aiiit, so I am invoking yosys as the following:
<meawoppl> `yosys -s integrate.ys`
<meawoppl> the script has only a few lines:
<meawoppl> ```
<meawoppl> `
<meawoppl> `read_verilog source/impl_1/*.vsynth_ice40 -top top -blif magicschoolbus.blifwrite_json magicschoolbus.json`
<meawoppl> bah, that is getting munged:
<meawoppl> `read_verilog source/impl_1/*.v`
<meawoppl> `synth_ice40 -top top -blif magicschoolbus.blif`
<meawoppl> `write_json magicschoolbus.json`
<meawoppl> that is all ^^
<meawoppl> when I run nextpnr I call the following:
<meawoppl> `nextpnr-ice40 --up5k --package sg48 --json magicschoolbus.json --pcf pins.pcf --asc output.asc`
<meawoppl> the output looks like this:
<ZirconiumX> meawoppl: Why not just `yosys -p "synth_ice40 -top top -json magicschoolbus.json" source/impl_1/*.v`?
<tpb> Title: nextpnr bug? · GitHub (at gist.github.com)
<ZirconiumX> That seems a bit simpler :P
<meawoppl> yeah that is better
<ZirconiumX> daveshah: ^
<whitequark> can you show the code?
<daveshah> Yeah this is obviously a bug
<meawoppl> whitequark I don't think I can share it without stripping a bunch of material
<meawoppl> the observation I wanted to put forward is that if I take the parameters out of the ice40 modules the pnr call succeeds, which I find interesting
<daveshah> No one will fix it without the code
<meawoppl> kk, let me try to make a minimal repro
<meawoppl> eta ... 5 or so?
<meawoppl> also, thanks!
<meawoppl> alright, that was much easier than I thought to strip down
<meawoppl> making it 1-command reproduction
<tpb> Title: GitHub - meawoppl/nextpnr-bug-repro: Not much to this all (at github.com)
m4ssi has quit [Remote host closed the connection]
<meawoppl> @da
<meawoppl> daveshah, if you clone the above and run `reproduce.sh` it should show the problem I am having
<daveshah> Having a look now
<tpb> Title: nextpnr-bug-repro/LedController.v at master · meawoppl/nextpnr-bug-repro · GitHub (at github.com)
<daveshah> this is silly but it is for compatibility with the Lattice tools
<daveshah> let me add a better error though
<meawoppl> oh, are parameter literals treated strangely somehow?
<daveshah> yes
<daveshah> this is very specific to the UltraPlus primitives
<daveshah> the SiliconBlue era primitives (LUTs, RAMs, SB_IO, PLLs) don't do this - only the LED driver and UltraPlus hard IPs do
<meawoppl> gotcha, howabout the high-freq osc?
dys has quit [Ping timeout: 276 seconds]
<daveshah> that's string style too
<meawoppl> woah, I think it all just worked.....
<meawoppl> thanks so much daveshah
<meawoppl> how can I contribute to this project? It is going to save me a ton of time I can already tell
<corecode> hi
<daveshah> meawoppl: first step is to keep the issue reports coming :) (I've just improved the error message in this case)
<daveshah> also have a look at open Yosys/nextpnr issues
<daveshah> hi corecode!
<corecode> hi dave
<corecode> you coming to congress this year?
<daveshah> no, I won't be
<corecode> boo
<corecode> last year there were a lot of people doing icebreaker tutorials
<meawoppl> is that the one in Munich?
<corecode> leipzig
<corecode> are there any ultra bugs that need attention?
<daveshah> Not sure, I have not tried the ultra support myself
<corecode> i am using it
pie_ has joined #yosys
<meawoppl> daveshah, one other question if you have some bandwidth
<daveshah> sure
<meawoppl> what is the right way to do a bidirectional pin (read and write) where the "high" needs to be high-impedance? (already has external pullup)
<corecode> instantiate a pin gpio instance and change OE
<daveshah> What you have looks alright to me
<daveshah> oh yeah, you can just have the output data set to 1'b0 as corecode
<daveshah> says
<daveshah> I did this for I2C a while ago
<tpb> Title: MARLANN/cameraif.v at master · SymbioticEDA/MARLANN · GitHub (at github.com)
<corecode> yep looks like what i suggested
<corecode> would be nice if you could express this in verilog and reliably get the right IO instantiated
<meawoppl> corecode and daveshah thanks for the leads
<meawoppl> can I keep pestering this channel with veriolog questions?
<corecode> i guess
<corecode> there is also ##verilog and ##fpga
<corecode> ymmv
<ZirconiumX> Also ##openfpga
citypw has quit [Ping timeout: 240 seconds]
<meawoppl> thanks!
m4ssi has joined #yosys
d0nker5 has quit [Ping timeout: 268 seconds]
d0nker5 has joined #yosys
d0nker5 has quit [Ping timeout: 268 seconds]
d0nker5 has joined #yosys
m4ssi has quit [Remote host closed the connection]
mmicko has joined #yosys
fsasm has quit [Ping timeout: 252 seconds]
steeeels has joined #yosys
<steeeels> Hi all, I have rather silly question and tbh it's more verilator related one, but still. Could anyone tell me if there's something wrong with this piece of code: https://pastebin.com/w6fWKUfa The reason I'm asking is that it works 100% fine if I pass --public option to verilator and doesn't work w/o it.
<tpb> Title: [VeriLog] module lfsr_rnd #( parameter POLY = 32'h80200003 ) ( input wire - Pastebin.com (at pastebin.com)
<whitequark> seems fine to me. how does it break?
<steeeels> In case I run verilator w/o --public option, every signal is zero, except POLY of course, please check these screenshots: https://imgur.com/a/A3hZtJo
<tpb> Title: Imgur: The magic of the Internet (at imgur.com)
<steeeels> The generated c++ code by verilator looks more or less similar, at least for those signals. It's hard to tell for sure for 10k lines of code
<whitequark> it generates 10kloc for that one module?
<steeeels> Nope. The SoC generates 10k LOC, but the issue is with lfsr module.
<whitequark> are you sure there is a problem in lfsr module and not something else?
<whitequark> it might be visible in the lfsr module but have its cause elsewhere
<steeeels> I believe so, yes. At least the code executes unless it tries to read something non-zero from random generator, which in this case is impossible. I'll try to minimize the reproduction and create a topic on veripool
<steeeels> Thanks
pie_ has quit [Ping timeout: 276 seconds]
steeeels has quit [Remote host closed the connection]
fsasm has joined #yosys
indy has quit [Ping timeout: 240 seconds]
indy has joined #yosys
ZipCPU has quit [Excess Flood]
ZipCPU has joined #yosys
pie_ has joined #yosys
FabM_cave has quit [Ping timeout: 268 seconds]
pie__ has joined #yosys
russell-- has quit [Ping timeout: 268 seconds]
pie_ has quit [Ping timeout: 268 seconds]
Jybz has quit [Quit: Konversation terminated!]
fsasm has quit [Ping timeout: 265 seconds]
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 276 seconds]
X-Scale` is now known as X-Scale
gorbak25 has joined #yosys
gorbak25 has quit [Quit: gorbak25]
tpb has quit [Remote host closed the connection]
tpb has joined #yosys