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
_whitelogger has joined #apicula
_whitelogger has joined #apicula
_whitelogger has joined #apicula
<pepijndevos> No idea what you mean with these hex numbers
<pepijndevos> Ohh... are you saying their compression is sort of a crude run length encoding?
<pepijndevos> So it's solved? They provide the dictionary (Is that the proper compression term?) in the header?
<trabucayre> more or less :)
<trabucayre> yep
<pepijndevos> And did you figure out davids question?
<pepijndevos> Do they just use a byte that never occurs?
<trabucayre> line starting with 0x90 (ie boot mode) contains info about (un)compress
<trabucayre> it's my assumption yep
<trabucayre> for line 0x90 is line & (1 << 13) != 0 data configuration is compressed
<trabucayre> for line starting with 0xd10 if uncompress you have 0xffffff
<pepijndevos> Hm... pretty sure that's not true. A lut has 16 bits and is encoded in two rows, so it can have any arbitrary byte, depending on alignment of course
<trabucayre> by changing fs analyzed values for blank are not always same
<daveshah> yeah create a large random design and I bet you'll see those bits
<pepijndevos> I'd try synthing a bunch of LUTs with 0x2b2b in the INIT
<daveshah> I'm sure it's possible to create a bitstream that uses all 256 possible byte valyes
<daveshah> *values
<daveshah> not just LUTs but routing too
<trabucayre> In my mind you analyze your design before compress -> you find 3 possible values not present
<pepijndevos> Yea but that's harder to control from the vendor tool, LUT INIT is something you can just set.
<daveshah> just a load of stuff with random interconnection between them should test a good chunk of routing patterns, fwiw
<daveshah> but yeah if the LUT INIT bits are enough then that's fine
<trabucayre> I'm interessed to have a design where all values are used :)
<pepijndevos> yea...
<daveshah> have you tried something like picorv32 yet?
<trabucayre> no
<trabucayre> I need
<trabucayre> it's fit gw1n-1 ?
<pepijndevos> nope
<trabucayre> :(
<pepijndevos> well, maybe in vendor tools actually.... apicula has no bram yet
<trabucayre> need to try it
<pepijndevos> So in apicula it's like 5k luts
<pepijndevos> Should be pretty easy to copy the attosoc demo into the vendor tools
<trabucayre> to validate my assumption I need to use vendor tool ...
<pepijndevos> just delete the top.v and use attosoc.v as top (top.v has the hardcoded IOB)
<trabucayre> okay
<pepijndevos> https://github.com/YosysHQ/apicula/blob/master/clock_experiments.ipynb this should be a good start if you want to generate a bunch of random designs
<trabucayre> but not now... I'm in holidays... my child too ... It's really difficult to work :(
<pepijndevos> understandable :)
<trabucayre> Next time I'm taking a week's vacation, in a hotel, alone...
Conny40 has joined #apicula
<pepijndevos> *sigh* this is over an hour of nextpnr trying to route attosoc https://paste-bin.xyz/16451
<pepijndevos> No idea why it's soooo much worse than the old nextpnr-generic target.
<pepijndevos> Well, I have *a* idea... not necessarily a correct one. Idea A) due to the reset/enable wires and 2 extra LUTs per tile, it's just more dense than the old target. Idea B) I screwed up super bad and half the wires aren't actually there. Idea C) I just need to tweak the numbers a bit...
<pepijndevos> Though I did try with the exact same numbers as generic...
<daveshah> An log extract (5-10k lines ish) from a --debug --verbose log is much more useful to me than that
<Lofty> pepijndevos: seems like nextpnr is not converging there.