<azonenberg> rqou: is it possible you muxed things wrong?
<rqou> it's possible?
<rqou> but all the other devices seem to be fine
<azonenberg> Hmm weird
<azonenberg> Double check your mux settings i guess
inoor has quit [Ping timeout: 260 seconds]
<rqou> yeah i get a whole bunch of "Unexpected idcode after end of chain" using the 64
<rqou> even when it's the only one in the chain
<azonenberg> but it does detect the 64?
<azonenberg> or no
<rqou> yes it does
<rqou> but then everything after it breaks
<azonenberg> huh weeeird
<azonenberg> I'm busy right now but in a bit, send me the dip switch settings you used and i'll try to reproduce
<rqou> anyways, the 32a works fine and can be programmed via a svf
<azonenberg> Ok
<rqou> azonenberg: your 4-layer boards have way more thermal mass than I expect and I keep burning my fingers :P
<azonenberg> Lol
<azonenberg> Wait till you get your hands on a 6 or 8
<lain> lol yeahhh
promach__ has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 240 seconds]
SpaceCoaster has joined ##openfpga
promach__ has quit [Quit: Leaving]
<rqou> azonenberg: i figured out why the china pin headers are cheap
<rqou> they melt a lot more easily and solder doesn't wick onto them as reliably
<rqou> cue the "i told you so?"
clifford has quit [Ping timeout: 268 seconds]
<lain> regarding the solder wicking, have you soaked them in flux?
<lain> :P
<lain> flux is the soldering cure-all
<lain> it's no-clean but it leaves a residue (which I usually clean with distilled water and then an iso rinse to dry)
<rqou> i tried flux, it still sucks
<lain> what kind of flux though
<lain> I used to use kester flux pens but I have concluded they are worthless
<lain> paste flux 4 lyfe
<rqou> i believe we have the exact same product
<lain> ah ok, I wonder what china did to the pins to make them not wick lol
<lain> that's impressive
<azonenberg> Indeed
<azonenberg> Oook so done with work for the time being
<azonenberg> Gonna try and bang out this rework CTF board in the next hour or two
<azonenberg> its almost done
<azonenberg> then once thats out of the way i'll figure out what to do next
<rqou> azonenberg: ok fyi freescale kinetis cortex-m does NOT have the "bypass flash security by single-stepping just right" bug
<rqou> so they also did it right
<rqou> it apparently locks out access to the entire cpu core when security is enabled
<rqou> so so far the only "herp derp" flash security i know of is the nrf51
inoor has joined ##openfpga
[X-Scale] has joined ##openfpga
<rqou> azonenberg: why do you inconsistently use square pin-1 pads?
<azonenberg> I almost never use them in current designs, preferring silkscreen marks
<rqou> this board has neither consistently :P
<azonenberg> Didn't think any of my footprints still had them
<rqou> the dipswitches have them
<azonenberg> ah interesting
<rqou> the physical mounting also doesn't match the pin-1 hole :P
<azonenberg> Lol
X-Scale has quit [Ping timeout: 272 seconds]
[X-Scale] is now known as X-Scale
<rqou> yeah that was super confusing thanks
<lain> these days the density is so high I often can't even fit silkscreen indicators, though I do try to
<lain> but I always have an assembly drawing layer which fits the pin 1 indicator and refdes inside the footprint, and is intended to be printed scaled up to fill 11x17 regardless of pcb size
<lain> that works well :P
<rqou> btw is there a way to do jed->svf without having to open the impact gui?
<rqou> ahh shit jed files have checksums don't they
<azonenberg> Yes, they do
<azonenberg> I have a jed file writer
<azonenberg> lain: yeah i've started using silk less in my high-density designs
<rqou> hmm impact doesn't seem to care
<azonenberg> lolol
<azonenberg> of course it doesnt :p
<rqou> hmm so for the output mode, i just tried 1001 and it seems to behave identically to 1000
<rqou> so the illegal values might just be illegal
<lain> illegal values are just hidden features waiting to be discovered
<rqou> but here it doesn't seem to do anything interesting
<lain> note that self-destruct is a feature
<rqou> arrgh can i run impact from the command line?
<rqou> oh i just found an xst bug
<rqou> ugh i should just try synthesizing .jed files completely by hand at this point
<rqou> i can't get xst to do what I want
<lain> if you want a job done right...
<rqou> yay it's the 1980s again and we're programming CPLDs using graph paper and worksheets
<lain> the xilinx code probably just fires up a tiny room simulation with an engineer doing that by hand anyway
<lain> that would explain why it's so slow and error-prone
Bike has quit [Quit: out]
<rqou> wait
<rqou> only the diagnostics were broken
<rqou> it actually did what i wanted
<rqou> no wait
<rqou> the diagnostics are always broken
<rqou> but it produces the expected output when there is an extra ! added
<lain> I just found a bug in my vhdl that makes me wonder how it ever worked
<lain> I honestly don't know why this worked in any of my test cases
<lain> probably fixing it will demonstrate that my tests are wrong
<lain> woo.
<rqou> hmm wtf
<rqou> impact is doing something wrong
<rqou> hmm now i'm definitely not sure of my results
<rqou> i need to test again
<rqou> azonenberg: i just tested INz
<rqou> 01 seems to disable driving the ZIA
<rqou> but macrocell direct input is still enabled
<rqou> strangely enough, 10 seems to be the same as 00 (both ZIA and direct input seem to work)
inoor has quit [Quit: inoor]
<azonenberg> rqou: one-hot something?
<rqou> sure
* azonenberg looks
<rqou> one bit can be input buffer enable and the other can be zia enable
<rqou> but zia enable seems to force the input being enabled in that case
<rqou> and the direct path doesn't seem to be able to be disabled
<azonenberg> ok so to confirm
<azonenberg> InZ = 01
<azonenberg> using the input combinatorially through the zia fails
<azonenberg> but using it into a register via the direct path works
<rqou> yes
<azonenberg> FBVAL 00 and 01, do we know what those do yet?
<rqou> going to check that next
<azonenberg> conjecture: 10 drives macrocell output to ZIA
<azonenberg> 00 is a bus fight
<azonenberg> sorry i meant, 01 drives macrocell to ZIA
<azonenberg> So, two bit active low one-hot mux
<azonenberg> 11 = floating (or tied off somehow)
<azonenberg> 10 = FF, 01 = macrocell
<azonenberg> 00 = ff and macrocell
<azonenberg> My suggestion is, try 01
<azonenberg> if that works as combinatorial feedback, don't test 00
<azonenberg> as that might break things
<azonenberg> (we can generate all valid logic states without using it)
<rqou> right
<rqou> i still need to set up a file to test this
<rqou> azonenberg: iMPACT doesn't have a real JED parser
<rqou> you can't add extra blank lines or Notes
<azonenberg> lolwut
<azonenberg> it requires their exact format?
<rqou> yeah
<azonenberg> lololol
<rqou> or it'll get a "Data mismatch"
<azonenberg> that explains it not checking the checksums
<azonenberg> it literally scanfs the file :D
<azonenberg> our tools are going to be so much better than the xilinx ones its amazing
<azonenberg> lol
<rqou> yeah probably
<rqou> just need to harass alanmi to add that weird xor gate to abc
<rqou> (or you can use a naive O(2^n) algorithm to do it :P :P )
<azonenberg> lolol
<azonenberg> i have ideas on how to do it in post-process optimization
<azonenberg> but we'll see what happens
<azonenberg> First step is to support the xor for plain old xor operations
<azonenberg> and the fast path
<rqou> unfortunately alanmi doesn't seem to have office hours
<rqou> he's not a professor
<azonenberg> wait, is he at berkeley?
<rqou> yeah
<azonenberg> :D
<rqou> berkeley did abc
<azonenberg> by all means track him down lol
<rqou> the slowest part of all of this testing has got to be waiting for impact to open
<rqou> it takes longer to open impact than to actually program the part
<rqou> oh wtf
<rqou> 00 looks to be the "combinatorial feedback" path
<rqou> 01 seems to do nothing
<rqou> (didn't brick at least)
<rqou> azonenberg
<rqou> so it looks to be a mux and an enable
<rqou> here's the jed just to be sure i didn't mess something up
<rqou> the idea is that the FF in FB1_13 (1-based numbering) is fed from the input buffer
<rqou> but PTC is inverted
<rqou> so changing the FB bits from 10 to 00 causes led0 to either match PMOD0 or be inverted PMOD0
<azonenberg> Innteresting
<azonenberg> sec
<azonenberg> Soo
<azonenberg> your conjecture is, bit 13 (left of fbval) is a mux of xor gate (0) or flipflop (1)
<azonenberg> bit 12 (right of fbval) is 0 to drive the ZIA and 1 to float
<azonenberg> (or tie constant or something)
<rqou> that's what it looks like
<azonenberg> This suggests InZ is the same
<azonenberg> or no sorry
<azonenberg> nvm
<rqou> except that the inz 10 case is weird
<azonenberg> Ok so
<azonenberg> When bit 12 is 1
<azonenberg> what does that zia line read as?
<azonenberg> is it a constant 0/1 or does it float and do weird things?
<rqou> seems to be a constant 0
<rqou> i touched the chip a bit and it didn't toggle or anything :P
<azonenberg> And with InZ
<azonenberg> 01 / 10 / 11
<azonenberg> reads constant 0 too?
<rqou> so when InZ is 10 it seemed that the zia was still being driven as normal
<rqou> when it was 01 or 11 the result seemed to be 0
<azonenberg> So in that case
<rqou> yeah i just did a really unscientific test of a) breathing on it and b) putting freeze spray on it
<rqou> it's not "glitchy"
<azonenberg> it looks like the rightmost bit is 0 to drive the ZIA and 1 to tie it to zero
<azonenberg> The left bit is 0 to drive the flipflop and 1 to tie it off
<azonenberg> With 10 does the flipflop update?
<azonenberg> if the FF stays constant zero we can confirm
<rqou> 10 on what?
<rqou> InZ
<azonenberg> Yes
<rqou> the ff and zia output both seem to work in the 10 case
<azonenberg> And with 11?
<azonenberg> also with 10 are you testing the ff direct path?
<azonenberg> or through the macrocell
<rqou> there was one led that is pad->zia->PTC->xor->output
<rqou> the other LED is pad->FF->zia->PTC->xor->output
<azonenberg> Ok
<rqou> where the FF is in the same macrocell as the input pad
<azonenberg> Innnteresting
<rqou> that was the thing where xst wouldn't do it unless you had a !
<rqou> it would still issue a warning if you wrote !
<rqou> but it would place the FF in the input macrocell
<rqou> otherwise it prefers to put the FF in the output macrocell
<azonenberg> ah interesting
<rqou> wait a sec
<rqou> how did i not notice this before?
<rqou> 11 seems to not actually disable the input
<rqou> the direct path still works
<rqou> wtf
<azonenberg> innteresting
<azonenberg> So
<azonenberg> New theory: direct path does not have a mux
<rqou> and the left bit seems to be useless
<azonenberg> Left bit does nothing, right bit enables ZIA driver
<rqou> why does it have such a bit?
<azonenberg> Very good question
<azonenberg> i'd say always set it the way XST does
SpaceCoaster has quit [Quit: ZNC - http://znc.in]
<rqou> we really need a proper delayer of the macrocell now
<azonenberg> Yes, we do
<azonenberg> There's lots of open questions
<azonenberg> i plan to fib delayer one as soon as our chiller gets fixed
<rqou> you sure we're not missing a feature?
<azonenberg> No, i'm not sure
<rqou> but i can't think of any other features left
<rqou> oh wait
<rqou> are there two different thresholds on input?
<azonenberg> Yes, but that's a different fuse
<azonenberg> for global iostandard
<azonenberg> Fuse #12274-12278
<azonenberg> InZ seems to not be "input impedance"
<azonenberg> it seems to be "input to ZIA"
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou> it seems very strange that there would be a vestigial bit that doesn't seem to do anything
<azonenberg> I suspect it does something
<azonenberg> i just dont know what
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vHGl2
<openfpga-github> openfpga/master b5c1151 Andrew Zonenberg: Updated xc2c32a bitstream notes
<rqou> anyways, it seems we now have all of the features
<rqou> the only thing left is "mysteries"
<rqou> which we don't care that much about
<rqou> e.g. disabling the zia saves power but doesn't actually change functionality
<rqou> it's interesting that i couldn't convince the xilinx tools to use combinatorial feedback
<rqou> it either figured out that it didn't have to or thought that it couldn't
<rqou> azonenberg: btw here's my xc2c64a jumper settings: https://goo.gl/photos/ZytMTsZL7DerBtD16
<rqou> maybe you can figure out why openocd seems to get super confused
<azonenberg> Ok so... TGT1_SRC is 3'b100 which is JTAG0, which is the FTDI
<azonenberg> JTAG0_SRC is 3'b001 which is TGT1, the XC2C64A, that makes sense
<azonenberg> For lulz
<azonenberg> try setting TGT0_SRC, TGT2_SRC, TGT3_SRC, JTAG1_SRC to 3'b111
<azonenberg> (if its not set up this way already)
<azonenberg> Other than that, no idea
<azonenberg> i'll try reproing on my board when i get achance
<azonenberg> its in the garage now
<azonenberg> oook so, rework challenge board now has full netlist connectivity except for the deliberate opens
<azonenberg> now to start adding shorts :p
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1 has joined ##openfpga
<rqou> i already have everything else set to 3'b111
<azonenberg> huh no idea then
indy has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
_whitelogger has joined ##openfpga
<rqou> hmm i just looked at the physical die map again
<rqou> why are there only 8 rows for each or array?
<rqou> the bits are interleaved rather strangely
<azonenberg> Yes they're interleaved
<azonenberg> they wanted to keep the sram the same size
<rqou> the 128 is still pretty wtf
<azonenberg> yeah i wanted to get the 32 100% done first
<azonenberg> then work on figuring out the rest
<rqou> but pretty pictures :P
<rqou> btw is st's active mesh known to be weak or something? :P
digshadow has joined ##openfpga
<azonenberg> Fairly so, yes
<azonenberg> But it mostly was a very recognizable one
<azonenberg> infineon likes straight lines, renesas is pretty random looking
<azonenberg> as is atmel iirc
<azonenberg> (modern st mesh may be better, this is like the classic mesh from the days of tarnovsky)
<whitequark> infineon? renesas? atmel? what do these have all in common
<whitequark> cpus?
<azonenberg> smartcard meshes
<azonenberg> we're talking about my rework CTF board, i put active mesh over one of the problems to make it more challenging
<azonenberg> The mesh is based on ST's smartcard mesh
<azonenberg> anyway, rework CTF board sent to fab
<azonenberg> Back to coolrunner stuff
<azonenberg> rqou: did you look at my updated bitstream spec? pushed that to github an hour or so ago
<azonenberg> whitequark: also did you see i now have DAC support in greenpak
<azonenberg> driving from counters
<azonenberg> i can even infer a counter in behavioral verilog and have the output drive the DAC, however this only works for down counters with reset but no clock gating
<azonenberg> up-down or clock gated counters currently require primitive instantiation of GP_COUNTx cells
<azonenberg> but you can drive the dac with them
digshadow has quit [Quit: Leaving.]
<azonenberg> At this point the only real things left to do on the slg4662x are PWM mode of DCMPs, driving the DCMP with ADC output, parallel output from SPI to fabric, wake-sleep timer stuff (not quite sure how this works yet), ADC, counter cascading and support for off-chip clock inputs
<whitequark> azonenberg: cool!
<whitequark> yeah DCMP and ADC are something i want too...
<azonenberg> I have the DCMP working as a comparator driven by constant values and counters
<azonenberg> Just not input from ADC, or PWM mode
<azonenberg> i forget if i have input from SPI yet
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Chicks dig it]
<azonenberg> Now that i have another yak shaved, i probably wont do much more coding on it tonight but i should make progress this weekend
* azonenberg has too many projects...
<Spida> :-)
<rqou> hey azonenberg review my documentation :P
<azonenberg> rqou: That's next on the list
<azonenberg> Did you push to main or your repo?
<rqou> not sure
<rqou> there's a PR
<rqou> i'm bad at maintaining branches
<rqou> btw while writing it i realized something interesting
<rqou> why weren't --unused-pull and --unused-drive .pcf options?
<azonenberg> They should probably be added there too
<azonenberg> make a ticket
<azonenberg> rqou: your UNUSED_DRIVE attribute has TOC label "shreg-extract"
<azonenberg> on 790
<azonenberg> replace "ohm" with the proper symbol
<azonenberg> like $10 k\Omega$
<azonenberg> on 803-805
<azonenberg> Same thing for UNUSED_PULL the label needs to be unique
<azonenberg> Otherwise looks good
<rqou> oh huh copypasta error
<openfpga-github> [openfpga] rqou opened issue #89: Unused pull direction/drive should be configurable in the .pcf https://git.io/vHGu1
<rqou> so i'm just browsing the coolrunner datasheet to see if i've missed anything
<rqou> and apparently coolrunners only guarantee 1k program/erase cycles
<rqou> that's super low
<rqou> also, supposedly it's possible to program only the sram cells
<rqou> iMPACT doesn't seem to do that though
<azonenberg> Yes its possible to
<azonenberg> i think impact has a "program sram" option, no?
<azonenberg> and 1k is still 999 times more than a greenpak :
<azonenberg> :p *
<rqou> i can't find the "program sram" option
<azonenberg> interesting
<rqou> but impact isn't the most discoverable tool ever
<azonenberg> iirc you should be able to do ISC_ENABLEOTF or something to do that
<azonenberg> i have the flash-only programming alg implemented in jtaghal (but not ported over to the new library yet)
<azonenberg> i dont think i ever did the sram mode
<azonenberg> but it would be easy to implement
<rqou> yeah i can't find it
<rqou> maybe impact doesn't implement it because they suck
<azonenberg> lolol
<azonenberg> oh no its not ISC_ENABLEOTF
<azonenberg> its ISC_SRAM_WRITE
<azonenberg> i implemented partial reconfiguration but had some difficulties
<azonenberg> it wasnt reliable
<azonenberg> i dont know if full-chip sram writing has bugs
<azonenberg> or if i was doing it wrong
<azonenberg> or if partial is buggy but full chip works fine
<azonenberg> antikernel/legacy-trunk/tests/CR2PartialReconfigTest/main.cpp has some example code
<azonenberg> also, as far as why the OR array is structured the way it is
<azonenberg> the PLA SRAM is 112 bits wide
<azonenberg> For the AND array, that's 2 bits for each of 56 pterms
<azonenberg> one PLA input per row
<azonenberg> one product term per 2 columns
<azonenberg> For the OR array, it's rotated 90 degrees
<azonenberg> Two bits for each of 56 pterms
<azonenberg> two OR array outputs per row
<azonenberg> iirc it's interleaved so the top row of OR array sram is OR array outputs 0 and 1
<azonenberg> next row is 2 and 3
<azonenberg> etc
<rqou> hmm it seems like to get the best possible result the fitter and yosys need to go back and forth a bit?
<azonenberg> I think this is true of PLDs in general
<azonenberg> not just CPLDs or coolrunner
<azonenberg> The best optimization will probably be done in cr2par (as i expect the tool to be called)
<azonenberg> the yosys optimizer will do the best job it can then the fitter will tweak as needed for the target device
<rqou> but when we get to this point we probably want to use abc or yosys again
<rqou> unless you want to manually reimplement tweaks
<rqou> btw the combinatorial feedback that we discovered exists?
<rqou> the datasheet says "The macrocell combinational functionality is retained for use as a buried logic node if needed"
<rqou> so it's intended
<rqou> cpldfit is just being dumb
<azonenberg> Yes
<azonenberg> well, if we can optimize better than the xilinx fitter
<azonenberg> i wouldnt be surprised
<azonenberg> and initially i want to focus on functional results
<azonenberg> improving QoR comes after we have R to measure Q of :p
<rqou> huh apparently on the larger parts Vref eats up io pins
<azonenberg> Yes, if you use SSTL
<azonenberg> this is true of FPGAs too
<azonenberg> if you use SSTL they tie the pin to vref, if not its a gpio
<rqou> the datasheet seems to be saying _any_ pin can be a vref
<azonenberg> uh, that sounds wrong
<azonenberg> let me see
<azonenberg> oh, interesting
<azonenberg> XAPP382 page 9
<azonenberg> it looks like yes, any pin can be a vref
<azonenberg> you may need >1 per bank
<azonenberg> One vref can drive up to six SSTL input buffers
<azonenberg> and no SSTL input buffer can be more than six bond pads away from a vref
<rqou> this'll be fun when we get to it
<azonenberg> So, the first rule is easy
<azonenberg> DRC fail if you have more than 6*n SSTL input pins in a given bank
<azonenberg> Verifying the second post-placement is easy too
<azonenberg> trying to pick a valid placement without constraints is harder
<azonenberg> but i can probably code it up somehow
<rqou> no i was thinking about RE-ing the control signals being fun
<azonenberg> oh
<azonenberg> i doubt it'll be too bad
<azonenberg> probably new inz bits
<azonenberg> or something
<azonenberg> on that note, let's not assume inz/oe etc bits have the same meaning across densities
<azonenberg> re-verify every mode for each device
<rqou> oh huh i just saw this in the fitter report:
<rqou> Pterm Limit : 36
<rqou> so there's a heuristic to make logic not use too many pterms
<rqou> that might be why i was having trouble forcing the combinatorial feedback
<azonenberg> no, i dont think so
<azonenberg> i think that's a rule to not use more than 36 pterms *per function block*
<azonenberg> of the 40 available
<azonenberg> i read a paper on coolrunner xpla3 routing fabric that shows what they clearly carried through to coolrunner-2
<azonenberg> basically they created a fabric that was guaranteed 100% routable for any (say) 36 of the 40 inputs
<rqou> ah so it keeps 4 "oh shit" pterms?
<azonenberg> then had a small number of unroutable pathological cases using 37-40 cannot be routed (although the vast majority can)
<rqou> i think i remember reading about that years ago
<azonenberg> So, this restriction ensures all designs are routable if they dont load the logic down too heavily
<azonenberg> once you have 36 pterms in every FB used
<azonenberg> if you have to add more
<azonenberg> there's a small risk of the design becoming unroutable
<azonenberg> but its better to spread logic across FBs if you have 38-40
<azonenberg> 37-40*
<azonenberg> if you have extra unused FBs available
<azonenberg> than to cram it all in one
<rqou> heh this reminds me of a fun story from my father
<rqou> years and years ago he somehow knew a guy who knew a guy who was doing some "research stuff" with an fpga
<rqou> and they had a design that utilized the fpga to exactly 100% utilization
<rqou> (it fit because it was some regular tiled structure)
<rqou> and then the tools blew up because nobody tested that
<rqou> you had to leave one last lut open because of a bug
<azonenberg> lolol
<azonenberg> I cant say i've ever pushed a xilinx fpga to 100% lut load
<rqou> supposedly the FAE basically just shrugged and said "oops"
<azonenberg> i think i may have hit 100% slice load on a xc3s50a once
<azonenberg> but each slice had some unused luts/ffs
<rqou> xilinx doesn't seem to like packing too much stuff into a slice
<azonenberg> well
<azonenberg> there's control set issues
<rqou> iirc the j-core guys are at 90-some % slice load but only around 50-60 % lut load
<azonenberg> typically you only have one clock enable per slice
<azonenberg> you can use it or not
<azonenberg> So if you have two FFs with different clock enables, you can't pack both into a single slice
<azonenberg> and if the number of FFs driven by a given clock enable is not a multiple of four
<azonenberg> you're guaranteed to get unused FFs
<azonenberg> as far as luts, some of that may be routing congestion
<azonenberg> i've never actually tried writing a par tool for lut fabric
<azonenberg> if i had, i imagine i'd understand it better
pie_ has quit [Ping timeout: 255 seconds]
<rqou> the xilinx tools seem to produce objectively crappy output a large amount of the time
<rqou> (without tweaking at least)
<azonenberg> Lol
<azonenberg> oh, like the time they put a ROM on the far side of a spartan6
<azonenberg> from all of the addressing and stuff that used the output
<azonenberg> needless to say it failed timing catastrophically
<azonenberg> oh, so with the coolrunner stuff
<rqou> i went through the datasheet again
<azonenberg> they actually provide min/max timing delays on everything
<azonenberg> and setup/hold times
<rqou> i think we have everything known
<azonenberg> So we should be able to make a static timing analyzer too
<azonenberg> And do timing driven placement
<rqou> there's no "surprise forgot about this feature"
<rqou> yeah, there are timing numbers
<rqou> i don't know if that's what the blob itself uses
<azonenberg> We'll find out i guess :p
<azonenberg> anyway, i need to sleep
<rqou> yeah i should too
<rqou> anyways, my work on vhdl has made me really wary of "surprise, forgot about this feature"
pie_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 260 seconds]
clifford has joined ##openfpga
Hootch has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<egg|egg> rqou: any new grammatical issues?
pie_ has joined ##openfpga
Zarutian has joined ##openfpga
m_w has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
azonenberg_work has joined ##openfpga
X-Scale has joined ##openfpga
lexano_ has quit [Ping timeout: 260 seconds]
lexano_ has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<pointfree> I previously did not know it is possible to extract flash/eeprom memory contents with a SEM. https://twitter.com/lowfatcomputing/status/868144998147137536
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
digshadow has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
lexano__ has joined ##openfpga
lexano__ has quit [Remote host closed the connection]
lexano has joined ##openfpga
lexano_ has quit [Ping timeout: 268 seconds]
scrts has joined ##openfpga
m_t has joined ##openfpga
<rqou> egg|egg: generics are hard
<rqou> this isn't a grammar problem though
<rqou> this is a problem with the language semantics
<egg|egg> rqou: ah yes, generics are hard :D
<egg|egg> in Ada at least
<egg|egg> but hey, at least they're contractual, it's not the C++ mess :-p
<rqou> housemate and i discussed this
<egg|egg> rqou: any specific questions?
<rqou> apparently having numbers in your generics makes things really hard
<rqou> having only types is actually easier
<egg|egg> if your type system isn't turing complete that is
<egg|egg> otherwise you can just make types that are numbers :-p
<rqou> the best part of vhdl is that generic constant parameters can be used to control generate statements
<rqou> which can contain generic instantiations
* egg|egg doesn't know what a generate statement is
<egg|egg> but yeah, generic parameters can do a lot of stuff in Ada too
<rqou> basically the idea is "copy this block a bunch of times"
<rqou> "make <n> copies of this pieces of hardware"
<egg|egg> (in fact in Ada 83 there were no pointers to subprogram, so you did it with generics)
<rqou> but n can come from a generic
<egg|egg> (that was daft, and Ada 95 and 2005 added pointers to subprograms)
<rqou> and each copy can have different generic parameters
<egg|egg> seems reasonable
<rqou> now generic instantiation, generate statements, and constant propagation have to all be done simultaneously
<rqou> oh yeah, and you have to do generics before you can even do typechecking
<rqou> and you can't actually resolve overloads until you have done all of the above
<rqou> vhdl just feels like it was a big mess that nobody really thought through
<azonenberg> rqou: Is verilog any better?
<azonenberg> :p
<azonenberg> (i havent actually tried parsing it)
<rqou> verilog is much better to parse because it just doesn't have enough stuff
<rqou> that's why so many companies have a really hacky verilog + perl/python/sed/m4/c-preprocessor/etc./etc. workflow
<azonenberg> lol
<azonenberg> see, i dont like having weird mixed stuff like that
<rqou> but every company has a _different_ ad-hoc version
<azonenberg> i use full on domain specific languages for things like constant tables or top-level interconnect generation (not half verilog half other stuff)
<azonenberg> that compile to plain old verilog
<azonenberg> then everything but that one module is native verilog
<azonenberg> way more portable
<rqou> meanwhile vhdl seems to be going the direction of "let's add ALL THE THINGS"
<rqou> but it's not "PL people" doing it
<rqou> so it just turns into a giant mess
<azonenberg> lol
<azonenberg> In other news, starshipraider host board out for delivery
<azonenberg> Going to try assembling tonight
<rqou> i looked at the working group for vhdl-201x and one of the proposed features (don't remember if it made the cut) was garbage collection
<rqou> (not synthesizable obviously)
<rqou> one feature that iirc did make the cut was access to environment variables
<azonenberg> ...
<azonenberg> no
<azonenberg> no
<rqou> because those are definitely a really great, consistent, reliable interface to get data into your program
<azonenberg> if you want something like that in your HDL, do an explicit -D in the build process
<rqou> /s
<azonenberg> you can always do $COMPILER -DFOO=$ENVVAR
<azonenberg> if you must
<rqou> imho instead of adding all of this shit we need a new simulator framework/interface thing
<rqou> so you can stop writing the testbench in HDL as well
<rqou> write the testbench in a "real" programming language
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<azonenberg> also starshipraider boards are here
<azonenberg> now i just have to finish work for the day so i can go assemble it :p
<rqou> azonenberg: why are sizes/indices in xbpar uin32_t?
<rqou> not size_t?
pie_ has quit [Ping timeout: 255 seconds]
Hootch has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
<azonenberg> Probably because i figured there was no point in making them bigger on a 64-bit system
<azonenberg> no product term CPLD in existence has >2^32 of anything
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
m_t has quit [Quit: Leaving]
Spida has quit [Ping timeout: 240 seconds]
<rqou> azonenberg: why is there no private used anywhere?
<azonenberg> rqou: I generally dont like using private values in C++
<azonenberg> it's rare that i have a class that i know will never have anything derived from it
<azonenberg> it's either public API, or something internal that i expect derived classes to use
<azonenberg> Going protected allows me to provide encapsulation while not losing extensibility
Spida has joined ##openfpga
pie_ has quit [Changing host]
pie_ has joined ##openfpga
Zarutian has quit [Quit: Zarutian]
m_w has quit [Quit: leaving]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
Zarutian has joined ##openfpga
Zarutian has quit [Read error: Connection reset by peer]
Zarutian has joined ##openfpga
<egg|egg> rqou: well generics being involved in overload resolution is a thing in Ada too, that's not just vhdl's weirdness
<egg|egg> rqou: though from what you told me vhdl does have shitloads of screwed-up language designs compared to ada
<lain> yes
<lain> it's almost bad enough to make me want to use verilog
* egg|egg shouldn't think about language design too much otherwise he's going to make an egghdl
<lain> haha
<lain> I'm already working on an hdl, but it's a long way from being usable
<lain> it works but it's not much better than existing solutions at the moment
<egg|egg> I'm good at getting sidetracked I've already wasted a few week-ends investigating the numerics of Kepler's equation, and one of the many ends of the rabbit holes was looking at glibc mailing lists with people realizing how shit their math.h was
<egg|egg> the above sentence is missing a colon after "sidetracked"
<lain> hahaha
<egg|egg> lain: problem with being a mathematician turned software engineer: I have had some numerics training, and now I see the state of numerics and I weep :-p
<lain> haha
<lain> I can imagine
<lain> I'm terrible at math :D
<egg|egg> pet peeve of the day: people documenting their libs saying "correctly rounded" when they mean "faithfully rounded"
<egg|egg> anybody can make a faithfully rounded trig function, correctly rounded all the time is impossible (well practically impossible at least), stop saying your trig function is correctly rounded!
<lain> what's the difference?
<egg|egg> I guess correctly rounded is a bit of a fuzzy term, but it does sound too close to exactly rounded
<egg|egg> lain: exactly rounded = last bit precise
<lain> ah
<egg|egg> that is the returned value is the result of rounding the true value with the given rounding mode
<egg|egg> faithfully rounded: the returned value is one of the two values either side of the true value
<egg|egg> that is it might be the wrong one
<egg|egg> (exactly rounded is "at most half an ULP" if you will)
<egg|egg> whereas faithfully rounded is "at most an ULP"
<egg|egg> s/at most/less than/
<egg|egg> lain: example in decimal arithmetic: 1/3 rounded to 2 sig. dec, rounding mode nearest ties to even: faitfully: either of 1.3, 1.4 will do; exactly: 1.3.
<lain> I see
<egg|egg> it can take arbitrarily long to compute an exactly rounded transcendental function
<egg|egg> whereas faithfully rounded is quite easy
<egg|egg> what you *can* do is try to find a faithfully rounded that's *really often* exactly rounded
<egg|egg> the above sentence is missing a noun
<egg|egg> and you can even give bounds on how often it fails to be exactly rounded
<egg|egg> most libs don't do that
pie_ has quit [Ping timeout: 240 seconds]
* qu1j0t3 has been reading a lot of Müller on this topic lately
* qu1j0t3 ... Handbook of F.P. Arithmetic and Elementary Functions, Algorithms & Implementations - if anyone wants to deep dive
<egg|egg> qu1j0t3: \o/
<qu1j0t3> egg|egg: hola!
<qu1j0t3> haha, that's funny.
* qu1j0t3 follow'd
<egg|egg> qu1j0t3: also, if you want a non-elementary function to bang your head against, the mean anomaly from Cartesian coordinates: https://en.wikipedia.org/wiki/Kepler%27s_equation
<qu1j0t3> ha
<egg|egg> full of ill-conditioning at every turn \o/
<qu1j0t3> egg|egg: do you use formal tools like Gappa?
<egg|egg> what's gappa?
<qu1j0t3> i'm really not DOING any of this stuff (not even qualified to) but I'm an interested reader
<egg|egg> I'm not doing anything I'm qualified to do tbh, this is just me getting sidetracked from a KSP mod
<qu1j0t3> gappa is good at figuring out error bounds. it's discussed a bit in Müller
<egg|egg> I've mostly been using a combination of pen&paper, whiteboard, some plots of random things, and banging my head against the desk
<egg|egg> qu1j0t3: my results seem to be that if e < 1 and ν > π/2, M(x/ℓ,y/ℓ) is well-conditioned, and if e >> 0 (including e > 1) and ν < π/2, M(x/a,y/a) seems well-conditioned too
<egg|egg> qu1j0t3: also I have no idea how to properly compute these 2-argument functions without summoning cancellations and other ill-conditions at every turn, but at least I've managed to shunt the ill-conditioning in the computation of a and ℓ, where things should be manageable with some high-precision trickiness :-p
* qu1j0t3 nods
<qu1j0t3> egg|egg: just curious, what's the fpga connection?
<egg|egg> >_> <_< >_> none at all :-p
<qu1j0t3> i mean i guess it's fairly natural for someone interested in binary arithmetic to be into fpga as well
<qu1j0t3> or vice versa
<egg|egg> my only contribution to the topic here is that I happen to know about Ada (because my father used to be on the Ada rapporteur group), and rqou is writing a vhdl compiley thingy so I occasionally provide some grammatical input
<egg|egg> other than that I mostly derail things with KSP modding and physics and numerics and Unicode (or all at the same time)
* qu1j0t3 nods