ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
_whitelogger has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
OmniMancer has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
emeb_mac has joined ##openfpga
_whitelogger has joined ##openfpga
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 252 seconds]
_whitelogger has joined ##openfpga
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 246 seconds]
Bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
Cerpin has joined ##openfpga
<Cerpin>
Hi, got another verilator issue -- is there anything that would cause large regs w/ both packed and unpacked dimensions not to end up in one's vcd?
<Cerpin>
I and a person I'm working with are both having this issue...
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
<Sprite_tm>
Hmm - is it normal that a 16K block of inferred memory takes Yosys half an eternity to 'create decoders' for?
futarisIRCcloud has joined ##openfpga
emeb_mac has quit [Ping timeout: 240 seconds]
<tnt>
Sprite_tm: that's because it didn't "infer" it :p
<tnt>
usually that means that yosys didn't map it to a real block RAM and is creating that memory as flip flops ... like a 131072 of them + all the muxing and enabling logic for it ...
<Sprite_tm>
Ugh :/ again.
<Sprite_tm>
Kinda starting to wonder if the entire 'inferring block ram is great! is such a hot idea... I keep running into a 'computer says no' when I try.
<tnt>
I pretty much gave up on it except for the trivial case.
<tnt>
Mmmm ... here yosys actually inferred 4 * DP16KD
<Sprite_tm>
...Huh. DP16K is a Ice40 thing, right?
<tnt>
nope. SB_RAM40_4K is ice40
<tnt>
DP16Kd is ecp5
<Sprite_tm>
And if you set WORDS to 4096? That's what my SOC uses.
<Sprite_tm>
Ooooh, I think the readmemh is the issue here.
<Sprite_tm>
If I use that to set an initial, the thing takes long. If not, it just soldiers on.
<Sprite_tm>
Ah, it's the combo of readmemh and the loop that sets everything to 0xdeadbeef. I think yosys borks on that, and you don't get that issue because you're not passing an initial hex file.
<Sprite_tm>
Damn, that something stupid as the initialization can break RAM inference...
<tnt>
actually here, it's the for loop that fails, always.
<Sprite_tm>
Ah, that may also be true, I commented out one of the two.
<Sprite_tm>
Still weird... I'd say the initialization block should lead to a static, known pattern for the RAM, so I don't see why making it into BRAM would fail.
<tnt>
apparently it actually still infers it, but later in the synth process.
<tnt>
Looks like it always generate it as FF first, then convert to bram ?
<tnt>
and so build time increase exponentially with ram size :/
<Sprite_tm>
Ah, that could be, tbh, I just ctrl-C'ed as soon as I sar the thing crunching on the decoders.
<tnt>
like at size 2048 it takes forever but completes with brams inferred ...
<Sprite_tm>
Wheee, it works! It's a long time I've been so happy to see a single LED light up.
gsi__ is now known as gsi_
<tnt>
you needed 8 brams to light a led ? :P
<whitequark>
i need 1 Mbit of PSRAM to do that. checkmate
* Hellsenberg
has lots of questions
<Sprite_tm>
whitequark: The LED is actually because the cache can correctly address a range of 64K of PSRAM :P
<Sprite_tm>
It's essentially a 'memory test OK' LED.
<daveshah>
The problem here is Yosys effectively expanding the for loop into thousands of individual initial statements
<Hellsenberg>
ah, that makes lots of sense
<daveshah>
I think there are supposed to be some optimisations for common cases here, but it seems to be missing them for some reason
<Sprite_tm>
Hmm, gotcha.
<Sprite_tm>
It's a bit of a shame; seemingly it does collate all of them eventually, but if you have an omghuge amount of memory it's gonna take a while.
<Sprite_tm>
Hmm, how do I read nextpnrs critical path report, btw? My maximum clk is getting dangerously close to my real clk...
_whitelogger has joined ##openfpga
<Sprite_tm>
Ah, nm, I think I figured it out by staring long enough at the lines. I initially thought it gave me multiple critical paths, one for each line, but seems all lines form one critical path.
<daveshah>
Yes
<daveshah>
There will be other critical paths printed between clock domains, and from clock domains to "async" (top level IO)
<daveshah>
The two numbers by each item are delay for that item and cumulative delay both in ns
<Sprite_tm>
Gotcha.
<Sprite_tm>
It's unfortunate that it takes an entire rebuild to see if something you did broke up the critical path... ah, that's life I guess.
<daveshah>
Yes, one day we will have partial rebuilds but I've got no idea when
<Sprite_tm>
That would be extremely awesome :) but I'm not holding my breath. Guess I'll just use my intuition, good excuse to sharpen that a bit.
<tnt>
Heh, viewing the top-N path would already give you a better clue. The histogram is a good start and very useful to give you a rough idea at least.
<Sprite_tm>
Ah? I had no clue the histogram did something useful? How do I read it?
<tnt>
Well, if you have only a few path in the smallest interval, it's a good indication that improving those will yield a good higher fmax with minimal changes. If you have hundreds ... well not so much.
<Sprite_tm>
That's probably capable of just getting a small bit of improvement?
<daveshah>
Out of curiosity, what is your target frequency?
<daveshah>
Does look like there isn't much to be done
<tnt>
yeah it's fairly well balanced.
<Sprite_tm>
48MHz. I seem to be OK now (60MHz max) but I tweaked something trivial before (which, obviously, I now can't reproduce anymore... grrrr) and I was down to 46.
<daveshah>
Yeah, PnR algorithms are slightly pseudorandom
<daveshah>
You can manually tweak this with --seed to nextpnr
<daveshah>
Also make sure --speed is set to the speed grade (6, 7, 8) of your part, it defaults to 6 (slowest)
<whitequark>
if you find yourself using --seed it is a sign you're doing something badly wrong
<whitequark>
usually, anyway
<tnt>
yeah ... I use seed from time to time. but when I do I make sure using a random one passes most of the time and there is just a few "bad ones" ...
<tnt>
if you need to go through 50 seed to get one that meets timing, that's a bit stretching it :p
<Sprite_tm>
Hehe, perhaps OK if you know you're doing the very final build and want to eke a few more MHz out of it.
<Sprite_tm>
I think it was just a glitch, I can't reproduce it anymore. 60MHz seems about par-for-the-course for my design, so I'm happy to have that again.
<Sprite_tm>
Hehe, lol @ 'for trial in [bunch of numbers]' :)
<TD-Linux>
daveshah, lol yeah I also stumbled across that (I have that system)
Asu has joined ##openfpga
m4ssi has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
lopsided98_ has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
futarisIRCcloud has joined ##openfpga
Asu has quit [Ping timeout: 252 seconds]
rohitksingh has quit [Ping timeout: 268 seconds]
Asu has joined ##openfpga
Bike has joined ##openfpga
rohitksingh has joined ##openfpga
_whitelogger has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
Asu is now known as ASU
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 3 commits to master [+2/-0/±8] https://git.io/fjtff
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan 439a920 - revC1: add MG2040 symbol and footprint
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan 7bb2843 - revC1: fix some ERC errors
<sorear>
2.3G for 7 years of logs? is it compressed somehow?
<whitequark>
nope, it is just sql
<whitequark>
postgres style tab separated values, one line per record
<whitequark>
that includes joins/quits even
<emeb>
it's a very usable interface - I assume you built that from scratch?
<whitequark>
yes
<whitequark>
i was really annoyed and had nothing better to do
<whitequark>
i remember sitting in a cafe, i think i wrote it in about 2 days?
<whitequark>
it's been basically unchanged since, save for minor maintenance
<emeb>
new adage: annoyance is the mother of invention.
<Hellsenberg>
definitely
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
<cpresser>
has anybody in here experience with manually applying conformal coating? I am thinking of getting this on on digikey: - .smali ist schwer zu lesen
<cpresser>
- mal nach .java decompilieren
<cpresser>
damm,, clipboard-fail. wanted to paste Digikey "473-1388-ND"
<Hellsenberg>
java-based conformal coating
<whitequark>
i've seen a few devices like that
<whitequark>
absolutely disgusting
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
sxpert has quit [Ping timeout: 250 seconds]
sxpert has joined ##openfpga
<emeb>
my first job was working on hi-rel flight hardware. all boards we did were covered in "elephant snot" conformal coating per NASA requirements.
<emeb>
Reworking those boards if they failed acceptance testing was a huge PITA.
<whitequark>
... elephant snot?
<emeb>
just what our technicians called it.
<emeb>
some sort of silicone-based clear gunk
OmniMancer has quit [Quit: Leaving.]
OmniMancer has joined ##openfpga
OmniMancer has quit [Read error: Connection reset by peer]
<TD-Linux>
cpresser, that's acrylic conformal coat, you can also get it in spray cans
<TD-Linux>
it's a very thin conformal coat, you can easily solder through it
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
Asu has quit [Ping timeout: 250 seconds]
Asu` has joined ##openfpga
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined ##openfpga
emeb has quit [Quit: Leaving.]
emeb_mac has joined ##openfpga
carl0s has joined ##openfpga
emeb_mac has quit [Ping timeout: 250 seconds]
Asu` has quit [Ping timeout: 250 seconds]
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 252 seconds]
kuldeep has quit [Quit: Its never too late!]
kuldeep has joined ##openfpga
<flammit>
FYI - regarding the ecp5 OTP fuses, TN1260 references a couple of SPI slave commands (LSC_{PROG|READ}_CIPHER_KEY} which also seem to be valid instruction codes on jtag
<daveshah>
oh interesting
<flammit>
yup it's a start, but the documentation is way less helpful than the mxo2/3 equivalents, though they seem to be similar. i.e. UIDCODE_PUB(0x19) still works on ecp5
<flammit>
the BSDL shows a bunch of private opcodes too
<daveshah>
there are quite a few debug primitives in the fabric
<daveshah>
a serious amount of factory testing goes on I think, almost all JTAG based
zem has quit [Ping timeout: 255 seconds]
zem has joined ##openfpga
rohitksingh has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
mumptai_ has quit [Quit: Verlassend]
parport0 has quit [Ping timeout: 244 seconds]
parport0 has joined ##openfpga
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 245 seconds]
lutsabound has quit [Quit: Connection closed for inactivity]
carl0s has quit [Ping timeout: 256 seconds]
lutsabound has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
futarisIRCcloud has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]