<emeb_mac>
lol - tried using the up5k PLL as a clock for generating video.
<emeb_mac>
So much jitter - monitor was shimmering like crazy.
<emeb_mac>
Switched to using xtal osc for video clock - rock steady.
rohitksingh_work has quit [Ping timeout: 250 seconds]
rohitksingh_work has joined #yosys
danieljabailey has joined #yosys
pie__ has joined #yosys
pie___ has quit [Ping timeout: 255 seconds]
citypw has joined #yosys
danieljabailey has quit [Ping timeout: 245 seconds]
gsi__ has joined #yosys
gsi_ has quit [Ping timeout: 272 seconds]
s3ntry has joined #yosys
futarisIRCcloud has joined #yosys
emeb_mac has quit [Ping timeout: 244 seconds]
s3ntry has quit [Read error: Connection reset by peer]
s3ntry has joined #yosys
m4ssi has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
leviathanch has joined #yosys
citypw has quit [Ping timeout: 244 seconds]
<cr1901_modern>
When did icetime start using such an obscene amount of memory during compilation? I can't even get it to compile in 2GB RAM + 2GB swap anymore
<tnt>
icetime ?
<cr1901_modern>
yes, icetime
<cr1901_modern>
it's taking up 3GB of virtual memory just to compile on my Pinebook
<cr1901_modern>
and chances are it just crashed the system, so now I have to do it ALL OVER AGAIN
<cr1901_modern>
goddamnit
<tnt>
Ah yeah indeed all the timings are in a auto generated c file that gets compiled ...
<cr1901_modern>
prob been compiling close to 40 mins now
<cr1901_modern>
And I _know_ ppl used to native compile yosys and icestorm on their Pi 3s
<cr1901_modern>
and that had half the memory
<cr1901_modern>
hell I compiled icestorm on a 10 year old netbook w/ 1GB RAM
<tnt>
Originally it only supported a few chips. Each new chip support has been growing the timing database.
<cr1901_modern>
greeeeat
<cr1901_modern>
The bitter irony of it all is that it would still take me longer to setup a cross compile environment thatn it would to just wait this out
<cr1901_modern>
b/c gcc is such an absolute clusterf***
<tnt>
instead of making one large file, it splits it into one per device
<cr1901_modern>
tnt: Thanks... and noted. I'll try that next. Perhaps it can be a compile-time option
* cr1901_modern
is probably killing a USB flash drive doing this
<tnt>
The UP5k is probaly the biggest culprit here because of all the DSP configuration variants and the high number of in/out ports ... (and timings are from every in to every out so N*N)
<cr1901_modern>
tnt: I'll try that patch later today, thanks
<cr1901_modern>
I'm curious to see whether compilation completes or dies
<tnt>
hehehe :)
<cr1901_modern>
This of course doesn't solve the problem of bbasm taking a long time, but afaik those can be compiled ahead of time and are arch-agnostic?
<tnt>
yeah, the bba are arch agnostic.
<tnt>
But I thin there is a way to not have them built-in into the binary but have them separate as binary files.
<tnt>
Those binary files are _not_ fully arch agnostic, but if the endianness is the same, it should be good enough.
<cr1901_modern>
while I would love to see nextpnr run on a big endian arch, it's not my main concern right now
rohitksingh_work has quit [Read error: Connection reset by peer]
AlexDaniel has quit [Ping timeout: 272 seconds]
rohitksingh has joined #yosys
AlexDaniel has joined #yosys
rohitksingh has quit [Remote host closed the connection]
emeb has joined #yosys
phire has quit [Ping timeout: 264 seconds]
phire has joined #yosys
PyroPeter has joined #yosys
develonepi3 has joined #yosys
danieljabailey has joined #yosys
<mwk>
external bba is broken on ice40 on master right now though :(
<tnt>
really ?
<mwk>
and tbh I have no idea what is the "proper" procedure to obtain the external chipdbs
gsi__ is now known as gsi_
* mwk
just snatched the .bba files from a non-external-chipdb nextpnr compile tree and manually bbasm'ed them
<emeb>
tnt: I assume you've gotten it working for yourself?
<tnt>
Yeah. But it's a sample of 1 board, so curious to see if it works for others, on other board and other hosts.
<emeb>
cool - I'm very curious to see if I can make this work.
<tnt>
It's not a bootloader atm .... it just enumerates a couple of useless endpoints, but the hw is there, just need a DFU firmware :p
<emeb>
tnt: sure, that makes sense. I just want Linux to give me happy reports in the dmesg...
<tnt>
(you'll need to build and flash the riscv fw in the fw/ directory in addition ot the hw)
<emeb>
Aha - a bit of extra work. I assume the firmware goes into the SPI flash?
<tnt>
yes, at the 1M offset. The makefile has a 'make fwprog' target, but of course that uses iceprog ...
<emeb>
that's fine - I have to use iceprog to load the flash.
<emeb>
my little usb/spi board only knows the simple protocol for loading the sram in the up5k
<emeb>
tnt: getting an error during make in yosys: ERROR: Module `SB_RAM40_4K' referenced in module `usb_trans' in cell `mc_rom_I' does not have a parameter named 'INIT_FILE'.
<emeb>
is my yosys out of date?
<tnt>
yeah :/
<tnt>
That got merged last week.
<emeb>
OK - is it safe to pull & rebuild? I saw some stuff earlier today about bugs in the git repo...
<tnt>
yeah, should be safe.
<tnt>
it's only nextpnr that has an issue and it's only if you try to use external chipdb which isn't the default option
<emeb>
kk
<tnt>
but you don't need to rebuild next-pnr, just yosys.
<emeb>
right
<emeb>
livin' large on the bleeding edge...
<tnt>
:)
maikmerten has quit [Remote host closed the connection]
<emeb>
yosys is happier now.
<emeb>
just need to tweak the .pcf and top level for my board.
<emeb>
heh - timing just barely fails
<tnt>
emeb: you might need to tweak the PLL settings if your ref is 16 MHz btw.
<tnt>
emeb: try another seed for timing. Here is succeeds like 90% of the time but sometimes it's unlucky ...
<emeb>
tnt: yeah - was just looking at the sysmgr.v
danieljabailey has joined #yosys
<emeb>
maybe my older nextpnr isn't able to make timing - tried lots of seeds and the 24MHz clock always fails by a small amount. backing off the requirement to 24MHz to see if it'll finish.
<tnt>
emeb: how small ?
<emeb>
tnt: missing by < 1MHz
<tnt>
Meh, should be fine.
<emeb>
but then I backed off constraint from 25 to 24 and it still missed - seems like the constraint affects the effort the algo exerts.
<emeb>
and since that failure results in an error condition on exit from nextpnr, make halts.
<tnt>
just retype make, it'll go through.
<emeb>
yep
emeb_mac has joined #yosys
emeb_mac has quit [Client Quit]
<tnt>
emeb: any success ?
cr1901_modern has quit [Ping timeout: 245 seconds]
GuzTech has quit [Ping timeout: 246 seconds]
Cerpin has quit [Quit: leaving]
cr1901 has joined #yosys
<cr1901>
tnt: Thought I'd give an update on your patch... indeed, up5k is the culprit here. With your patch, I still requires 2GB of swap. However, the laptop is marginally usable now instead of completely and utterly unusable. Thanks to your patc
<cr1901>
h*
<cr1901>
In fact, it's compiling right now as I type :)
<cr1901>
1878 MB RAM/1529 MB swap
<cr1901>
and I still have a responsive system (for now!)