emeb_mac has quit [Ping timeout: 246 seconds]
flea86 has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
gruetzkopf has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
gruetzkopf has joined ##openfpga
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
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> anything more complex than that and I don't bother.
<tnt> Also, I always isolate it in a separate module, never except it to "find it" in a file doing other stuff.
<Sprite_tm> Gotcha.
<Sprite_tm> It does infer something halfway decent when it's *really* simple, but it b0rks on what I think is the wite byte select...
<tnt> Do you have your code somewhere ?
<whitequark> yosys really needs a "this ram needs to be a block ram" attribute
<Sprite_tm> tnt: http://j0h.nl/YMsB
<tnt> is that for ecp5 or ice40 btw ?
<Sprite_tm> ECP5
<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> Hmmm...
<Sprite_tm> Info: [ 4285, 5077) |***************+
<Sprite_tm> Info: [ 5077, 5869) |************************************************************
<Sprite_tm> Info: [ 5869, 6661) |*********+
<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
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan b9794b5 - revC1: add ESD protection to IO banks
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/fjtfk
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 705033b - gateware.fx2_crossbar: rename FIFOs to reflect their function. NFC.
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark ffdc0ae - gateware.fx2_crossbar: simplify and clarify. NFCI.
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtfL
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan e8fcc6f - revC1: fix U32 reference size
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjtfZ
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 28f520d - revC1: s/LVDS Bank/LVDS/
Asu` has joined ##openfpga
ASU has quit [Ping timeout: 245 seconds]
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjtfP
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark 02cf946 - gateware.fx2_crossbar: factor out more logic into _FX2Bus. NFC.
<_whitenotifier-1> [Glasgow] whitequark closed issue #118: Improve ESD immunity - https://git.io/fjIUq
<_whitenotifier-1> [Glasgow] whitequark commented on issue #118: Improve ESD immunity - https://git.io/fjtfX
<_whitenotifier-1> [Glasgow] whitequark reopened issue #118: Improve ESD immunity - https://git.io/fjIUq
<_whitenotifier-1> [Glasgow] whitequark commented on issue #118: Improve ESD immunity - https://git.io/fjtfb
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fjtJX
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 4af0475 - revC1: add a TVS protection diode to SYNC
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±4] https://git.io/fjtJD
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 59c960b - revC1: add a TVS protection diode to SYNC
<_whitenotifier-1> [Glasgow] marcan commented on issue #118: Improve ESD immunity - https://git.io/fjtJy
<_whitenotifier-1> [Glasgow] marcan closed issue #118: Improve ESD immunity - https://git.io/fjIUq
lutsabound has joined ##openfpga
_whitelogger has joined ##openfpga
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
ayjay_t has quit [Read error: Connection reset by peer]
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±5] https://git.io/fjtU0
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark c4ec091 - revC: tiny changes to text placement on schematic for readability.
ayjay_t has joined ##openfpga
emeb has joined ##openfpga
<emeb> nice to see foboot is out there now. digging around in the design now to see if I can hack it to fit on my board.
<whitequark> i figure i'll remove the notifications now, since glasgow has its own channel
<Hellsenberg> sounds wise
<emeb> whitequark: thanks so much for hosting the logs of this chl!
<emeb> very useful
<whitequark> oh yeah, i host a lot of logs
<whitequark> it's just sitting there since like... 2011..?
<whitequark> when did i write that
<emeb> yes - I popped up a level and saw all the stuff that's archived - you must have big disks.
<whitequark> Nov 16, 2011
<whitequark> and nope
<whitequark> -rw------- 1 root root 211M Apr 7 00:00 irclog_esper.sql
<whitequark> -rw------- 1 root root 2.3G Apr 7 00:00 irclog_freenode.sql
<emeb> apparently I overestimated the irc traffic
<whitequark> 24285026 irclog_freenode.sql
<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
<Adluc> this shit is quite good for resoldering https://www.sos.sk/products/kontakt-chemie/plastik-70-400ml-33229
<Adluc> quite common in EU
<TD-Linux> yeah that's basically the same thing
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 268 seconds]
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]
ayjay_t has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 250 seconds]
Asu` has quit [Quit: Konversation terminated!]
SpaceCoaster has quit [Ping timeout: 250 seconds]
SpaceCoaster has joined ##openfpga
sxpert has quit [Ping timeout: 264 seconds]
sxpert has joined ##openfpga
dj_pi has joined ##openfpga