13:23 <pepijndevos_> kbeckmann, waat? I'm definitely fuzzing those with the vendor tools exactly like that

13:24 <kbeckmann> hmm

13:24 <pepijndevos_> https://github.com/YosysHQ/apicula/blob/master/apycula/tiled_fuzzer.py#L124

13:24 <kbeckmann> maybe they broke it in the latest version?

13:25 <pepijndevos_> I'd make a simple example and compare what the vendor IDE synthesizes and compare to your code.

13:26 <kbeckmann> like so https://gist.github.com/kbeckmann/2eeeb90afbf2b6ddef6cf9ff9eee3c92

13:26 <kbeckmann> hm

13:27 <kbeckmann> now i am confused again.

13:28 <kbeckmann> but adding `opt_clean -purge` before write_verilog removes those wires and makes the PnR tool happy

13:44 <kbeckmann> hrm, looking at this log today it seems nmigen has generated some odd verilog. the top module has the signal `led_0__io` which is passed directly into the module's IO port, which is then passed straight to IOBUF.IO() which is perfect. the problem seems to stem from yosys that created the line in the end `assign \pin_led_0.led_0__io = led_0__io;`

13:47 <kbeckmann> actually the nmigen generated verilog looks fine, seems it's yosys output that is the only problem here where it created `\pin_led_0.led_0__io ` for some reason.

13:48 <pepijndevos_> oh weird...

13:49 <kbeckmann> i don't want to disctract you as i have a workaround..

13:49 <kbeckmann> we can come back to this later, so you can work on nextpnr in peace :)

13:49 <pepijndevos_> :))

13:50 <pepijndevos_> Making sure Yosys actually works is also important though. But ok, happy to come back to it later

13:52 <pepijndevos_> Currently writing more bba stuff, fully expecting to rewrite a lot of it later. My db is very dict heavy, and I do not yet oversee how things will be indexed on the nextpnr side. Easy enough to add indexes later.

13:52 <kbeckmann> ah, bba is Binary Blob Assembler

13:52 <pepijndevos_> yea

14:39 <kbeckmann> i tried to add an instance of rPLL but yosys won't let me. i guess synth_gowin doesn't implement this yet, i could try to add it? if so, where would i start looking?

14:48 <pepijndevos_> Oh yea... you just need to add it as a primitive

14:49 <pepijndevos_> add it here basically https://github.com/YosysHQ/yosys/blob/master/techlibs/gowin/cells_sim.v

14:50 <pepijndevos_> they get read here as blackboxes https://github.com/YosysHQ/yosys/blob/master/techlibs/gowin/synth_gowin.cc#L174

14:51 <pepijndevos_> there may or may not be simulation models inside Gowin that you could take inspiration from, but just a blackbox with the ports from the manual is fine.

14:51 <pepijndevos_> I also saw they deprecated a bunch of block, which basically just seem renames.

14:53 <kbeckmann> thanks! i will take a stab at it and make a pr

14:53 <pepijndevos_> for example.... gowin1.9.6/IDE/simlib/gw1n/prim_sim.v

14:53 <kbeckmann> ah

14:54 <pepijndevos_> Any resemblance between those models and techlibs/gowin/cells_sim.v is of course purely incidental ;)

14:54 <kbeckmann> heh

14:54 <kbeckmann> but shouldn't there be a gowin-specific file for cells only found in gowin fpgas?

14:54 <kbeckmann> oh sorry

14:54 <kbeckmann> i somehow thought the cells_sim.v was generic

14:55 <kbeckmann> ok but this should be fairly straight forward to do

15:53 <kbeckmann> is there a way to assert that parameters are valid? e.g. parameter CLKOUTD_SRC = "CLKOUT"; //CLKOUT,CLKOUTP

15:54 <kbeckmann> would be nice to have some sort of assert that if the users specifies something else, it will warn about that immediately

18:19 <pepijndevos_> Uh, what about normal verilog asserts? No idea if that does what you want

22:59 <kbeckmann> i was looking in the existing code and the parameters don't seem to be checked anywhere except for one place where it is done in formal. i basically just want a way for yosys to tell the user they are doing something wrong, instead of the PnR tool. but i guess it's not a normal use case so let's not do it.