pepijndevos changed the topic of #apicula to: Project Apicula: bitstream documentation and tooling for Gowin FPGAs https://github.com/YosysHQ/apicula -- logs https://freenode.irclog.whitequark.org/apicula
rvalles_ has quit [Ping timeout: 240 seconds]
rvalles has joined #apicula
FabM has joined #apicula
FabM has quit [Ping timeout: 256 seconds]
FabM has joined #apicula
_whitelogger has joined #apicula
<pepijndevos_> I'm so confused about relpointers... seems very simple but my brain is mush and gcc yells at me
<pepijndevos_> I have a struct that has a relpointer to an array of structs and I'm trying to get a field from the nth array element. So I do struct->field to get the relpointer, and then struct->field[idx] to dereference the relpointer, and then struct->field[idx].field to get the field, but compiler says no
<daveshah> Yes that seems correct to me
<pepijndevos_> oh actually... editor says no, but compiler says yes now... editor is stupid apparently...
<trabucayre> pepijndevos_: it's seems
<pepijndevos_> hurray segfaults for everyone
<pepijndevos_> ooooh
<pepijndevos_> log_info("alias %s\n", db->id_strs[db->aliases[3].dest_id].get());
<pepijndevos_> Info: alias UNK122
<daveshah> neato
<pepijndevos_> idstrings disregards any constids I might define, but it works :))
<kbeckmann> pepijndevos_: have you had issues with the gowin synthesis tool? i am seeing some weird issues that i can only regard as bugs in the tool. i'm currently trying to integrate the official gowin toolchain into nmigen so we can have a clean starting point before integrating apicula. but it seems the synthesis tool is changing my logic and generating weird incorrect code. so i want to use yosys instead
<kbeckmann> - have you made any progress in yosys beyond 'synth_generic.tcl' or is that good enough?
<kbeckmann> (i don't know why i thought this, but i was thinking that integrating the vendor tools would be easy and a smooth ride :D )
<pepijndevos_> kbeckmann, there is synth_gowin which should output vendor compatible netlists, upstream in yosys
<pepijndevos_> the generic thing is not compatible with vendor tools
<kbeckmann> ohh that's awesome. thanks for letting me know
<kbeckmann> i will give it a shot
<pepijndevos_> If it doesn't work... report a bug and let me know
<kbeckmann> cool. right now i am integrating the IOBUF primitive in nMigen which caused the vendor tool to bork out. will let you know how it goes!
<kbeckmann> pepijndevos_: i have a design that makes yosys generate a LUT1. does this exist? when running the pnr tool with that file, i get a syntax error on that line.
<kbeckmann> ERROR (PA2000) : "/home/konrad/dev/fpga-projects/gowin/nmigen/build/top.vg":779 | syntax error near token '#'
<kbeckmann> LUT1 #(
<kbeckmann> .INIT(2'h1)
<kbeckmann> )
<pepijndevos_> Yes LUT1 is fine... but that style of parameters is not. IIRC it uses this defparam stuff and there should be a command in the flow that converts these...
<kbeckmann> okay
<kbeckmann> i use write_verilog -noattr {{name}}.vg
<kbeckmann> thanks!!
<pepijndevos_> nooo
<kbeckmann> ok i have no idea what i am doing as you can tell..
<pepijndevos_> use the output option of synth-gowin
<kbeckmann> ohhh
<pepijndevos_> -vout will do the correct formatting
<kbeckmann> thanks
<kbeckmann> i am able to synthesize a super simple design now, like having an led on all the time
<kbeckmann> but anything more complex than that seems to break. getting a syntax error on this now
<kbeckmann> assign \cd_sync.timer[2]_LUT3_I0_F [3:2] = { \cd_sync.timer[5] , \cd_sync.timer[3] };
<kbeckmann> looks sane?
<kbeckmann> "syntax error near token ':'"
<kbeckmann> maybe it doesn't like the space
<kbeckmann> oh wait that looks a bit odd, doesn't it? "\cd_sync.timer[2]_LUT3_I0_F [3:2]" that [2] in the middle?
<kbeckmann> i slowly retreat from this, as i really don't understand the syntax here. there seems to be a lot of this style in the generated code, but i haven't seen that before at all.
<daveshah> Its an escaped name, so [ and ] are valid characters like any other
<kbeckmann> thanks, i was just a bit startled by that name. now i get it.
<kbeckmann> i split up that expression into two lines that assign one bit at a time. now it manages to produce a bitstream, however it doesn't seem to work. unfortunately the code is a generated mess so it's kind of hard to track down what's wrong. i'll try writing a simpler design.
<pepijndevos_> ahhh I remember this problem...
<kbeckmann> btw i am running the latest Gowin_V1.9.7Beta
<kbeckmann> i might have newer and cooler bugs that you haven't seen yet ;p
<pepijndevos_> So the Gowin tools can't deal with wide signals. Yosys does break everything up, but sometimes it still generates these odd assignments that freak out the vendor tools
<kbeckmann> ah
<pepijndevos_> Not sure how to fix that...
<kbeckmann> interestingly this only happened once in the very end of the generated file
<pepijndevos_> But yea manually splitting up the assignment should do the trick.
<pepijndevos_> kinda yucky...
<pepijndevos_> Yea I think... it's only for module outputs? All internal signals get broken up
<kbeckmann> seems to be the case yes
<pepijndevos_> Yea so problem is it obviously can't break up the output itself... and there is nothing that I'm aware of that tells yosys to break up the assignment itself, in addition to the nets.
<pepijndevos_> One "fix" would be to only use single-wire outputs on the top level.
<pepijndevos_> The rest all gets flattened anyway.
<kbeckmann> hmm i think i do that already
<kbeckmann> like this module top(rgb_led_0__g__io, rgb_led_0__b__io, lcd_0__r__io, lcd_0__g__io, lcd_0__b__io, lcd_0__vs__io, lcd_0__hs__io, lcd_0__den__io, lcd_0__pclk__io, clk24_0__io, rgb_led_0__r__io);
<pepijndevos_> what's cd_sync.timer[2]_LUT3_I0_F then?
<kbeckmann> it's an internal timer
<kbeckmann> as in, inside the design. the output ios are all 1 bit wide
<pepijndevos_> hmmmmmmm
<kbeckmann> or am i misunderstanding you?
<pepijndevos_> no you're understanding me correctly, my understanding of the problem might be wrong
<kbeckmann> ok!
<kbeckmann> let me see if i can write a minimal test case
<pepijndevos_> If you could make a minimal example and report a bug, I'll try to look at it
<kbeckmann> this generated nmigen code is a bit.. huge
<kbeckmann> yeah i will do so
<pepijndevos_> great
<kbeckmann> thanks :)
<pepijndevos_> Maybe the `flatten` or `splitnets` calls should be in a different place so that these internal nets do get split somehow.
<pepijndevos_> And of course... the toplevel case should also be fixed, but might require some advice from people more familiar with yosys internals, and maybe some more extensive fix.
<pepijndevos_> I really do hope that 1.9.7 did not break all the other things... Gowin hasn't been very stable with... anything
<kbeckmann> i see
<kbeckmann> they changed the tcl commands quite a bit
<kbeckmann> but i figured if i was going to make this nmigen platform support, i might as well go for the lastest version
<pepijndevos_> Yea definitely. For LiteX I also went for the latest one.
<kbeckmann> oh. that platform integration looks quite simple.
<kbeckmann> hm this bug is quite weird. the wide signal that is partially assigned.. there are no references to those bits that are being set. they are just set and never used as inputs anywhere.
<kbeckmann> i have tried to minimize the code but whenever i get below a certain point it starts working again, and it's still quite a lot of code unfortunately
FabM has quit [Quit: Leaving]
<pepijndevos_> that is super weird...
<kbeckmann> yeah.. here are the files if you want to take a look, and again, i'm sorry i can't reduce it further https://gist.github.com/kbeckmann/06e03a466605ce6b8001b3c2b3018104
<kbeckmann> hm hang on a second, let me double check the files
<kbeckmann> updated it now with logs etc.
<kbeckmann> the power-on-reset code seems to be causing the bug, but i have seen it happen when running a different (but larger, so might not be so useful to look at) design without the reset.
_whitelogger has joined #apicula