<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>
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
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>
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)