Lofty changed the topic of #prjmistral to: Project Mistral: Yosys (and hopefully nextpnr) on Cyclone FPGAs - https://github.com/ZirconiumX/mistral - logs: https://freenode.irclog.whitequark.org/prjmistral
fdalleau`` has quit [Ping timeout: 258 seconds]
fdalleau`` has joined #prjmistral
fdalleau` has joined #prjmistral
fdalleau`` has quit [Read error: Connection reset by peer]
chipb has quit [Quit: chipb]
chipb has joined #prjmistral
peeps[zen] has joined #prjmistral
peepsalot has quit [Ping timeout: 240 seconds]
fdalleau`` has joined #prjmistral
fdalleau` has quit [Ping timeout: 272 seconds]
fdalleau`` has quit [Quit: It is time for you to leave]
fdalleau`` has joined #prjmistral
fdalleau`` is now known as fdalleau
fdalleau has quit [Quit: Coyote finally caught me]
<Sarayan> hmmm, recommendation to embed binary files as portably as possible?
<Lofty> Embed where?
<Lofty> Sarayan: ^
<Sarayan> in a library
<Sarayan> in the library
<Sarayan> there's roughly 200M of routing tables, and if I try to generate them I'll be still on that next year
<Lofty> ...Then I'd really rather wait until next year, honestly
<Lofty> I realise like nextpnr generates binary blobs, but those come from text files
<Sarayan> Oh they start from a text file
<Sarayan> but parsing them takes a while
<Lofty> Do you *have* a parser?
<Sarayan> pushing...
<Sarayan> done
<Sarayan> mkroutes.sh will generate c++ files which embed bz2-compressed versions of the binary tables from the text tables in data/*
<Sarayan> but they take way too much time and memory to compile to .o
<Sarayan> you can check route-to-c.py for the c source generator
<Sarayan> I really hate external files, they're never where you look for them
<jevinskie[m]> https://github.com/graphitemaster/incbin or maybe cook something up with LIEF to craft ELF/PE/macho
* sorear grumbles about how we've gone from "lol 20GB vivado install" to "let's compile in 100s of MBs of tables per FPGA device because designing a better data representation is too much work"
<Lofty> Well, we *are* getting there
<Lofty> And I mean, yeah, this is 222M compressed
<jevinskie[m]> External files can be a pain
<jevinskie[m]> If you want to go wild, embed a uncompressed zip into the object file and mmap a simple bundle directory structure :P
<Sarayan> sorear: I generated that from what is 202G of tables in quartus
<sorear> 202 GB??
<Sarayan> jevinskie[m]: that would be ~3G iirc, a little too much
<Sarayan> sorear: yes
<Sarayan> galibert@tata:/unsaved/dumps #8 >du -h asm
<Sarayan> 202Gasm
<Sarayan> and it's 200M for all 7 dies
<jevinskie[m]> Impressive gains (loses?) :)
<sorear> is this for a single product generation in both cases?
<Lofty> I'd imagine so, yes
<Sarayan> there is some loss, I'm going to need other tables next to it, but they'll be small
<sorear> I imagined that the huge vendor sdks supported all product generations, and so our budget for bytes per product generation was small (few MB)
<Sarayan> it's the actual routing stuff in full though, what's lost is for instance on which nodes the iob plug on
<Sarayan> the full cyclone v support data in quartus lite to 7.7G, it's a compressed format
_whitelogger has joined #prjmistral
<Lofty> It might be faster for me to write a whole new generator, I think :P
<Lofty> Mmm
<sorear> what is the download and on-disk size of a full quartus install?
<Lofty> $ du -h
<Lofty> . Infinity
<Lofty> Good question
<bwidawsk> sorear, Lofty: I bet chipb could tell you
<Lofty> 1.6GB base download plus 1.3GB for the Cyclone V family
<sorear> and it uncompresses to 7.7G?
<bwidawsk> it's quite a bit larger if you go up to pro, iirc