<whitequark>
one row of pins in that connector is all GND, 8 pins in the other row go to the FPGA, and 2 more are VCC from Vadj
<rqou>
so, when is this going to feature-creep into bus-armada/starshipraider?
<whitequark>
rqou: hm? this isn't feature-creep, this is just laying out the mechanics for what I always had planned for it
<whitequark>
which is: have four JTAGs, or two JTAGs and four UARTs
<rqou>
yeah, well a few years ago i started with a similar idea
<rqou>
and then it feature-creeped into bus armada and got cancelled
<rqou>
:P
<whitequark>
well we already settled on the iCE40UP5K
<whitequark>
so that fairly severely restricts the design
<rqou>
lol
<rqou>
i guess i started with a s6
<rqou>
so plenty of room for feature creep there
<awygle>
whitequark: so 2x 10x2 connectors, and those run to a daughter board? or direct-to-DUT?
<whitequark>
awygle: I suppose you could do direct-to-DUT with the correct cable but it makes more sense to do daughterboards and standard cables and connectors
<whitequark>
also, it should be possible to make a single daughterboard that plugs into both connectors
<whitequark>
for example, the Cortex ETM connector needs 10 pins
<awygle>
sure
<awygle>
we can use the actual bus blaster pinout
<whitequark>
on both?
<awygle>
then if you happen to have a bus-blaster-compatible DUT you can just use a ribbon cable
<whitequark>
oh I do quite like it
<awygle>
there are 9 i/o pins, 2 Vtarget and the rest are ground
<whitequark>
that's exactly what I came up with lol
<whitequark>
so ... we'll be compatible by default on *both* sides of the board
<whitequark>
I like that a lot
<awygle>
yup, and then we can do dirt-cheap daughter boards to whatever connector
<rqou>
random questions: are PIC compilers still a pile of flaming garbage?
<rqou>
"award-winning MPLAB® XC C Compilers"
<rqou>
the shit award? :P
<whitequark>
awygle: sounds good
<whitequark>
rqou: lol
<awygle>
sweet, sounds like we have a design
<rqou>
oh wtf
<awygle>
now how shall we divide the work
<rqou>
apparently xc8 is evolved from the hi-tech compiler
<whitequark>
awygle: there's still one thing to discuss
<rqou>
so it's still the same shit
<whitequark>
do we try to make it possible to use two different Vio?
<awygle>
well there are three I/O banks. one for Cypress, one for each DUT?
<whitequark>
the SPI pins are in Bank 1
<whitequark>
and Cypress needs at least 15 pins so it can't fit in Bank 1
<awygle>
hm. does cypress fit in _any_ bank by itself?
<awygle>
bank 0 looks like
<whitequark>
we could squeeze it into Bank 0
<whitequark>
that would mean losing some pins
<whitequark>
potentially making things less efficient or harder to design
<whitequark>
it's probably not a very big deal
<whitequark>
but we still need to do something about SPI
<awygle>
wait bank 0 is 17 pins, that's exactly the width of the cypress interface + INT0/INT1, right?
<awygle>
if we find a "1.8 to 3.3" SPI that should be OK
<whitequark>
um wait no
<whitequark>
by SPI I mean the SPI slave interface through which the bitstream is downloaded into FPGA
<whitequark>
there'll be no actual SPI in the design
<whitequark>
I want to find a very large I2C EEPROM for the bitstream
<awygle>
oh so you're planning to load the bitstream from the cypress chip
<awygle>
?
<whitequark>
yeah, for two reasons
<whitequark>
first, reprogramming the SPI chip every time I want to change the design runs counter to the goal of this being easily configurable
<whitequark>
second, 68013A doesn't have any hardware support for SPI so it'll all be bitbang
<whitequark>
but it does have hardware I2C
<whitequark>
(and it actually seems amazingly non-buggy for an I2C core)
<rqou>
hardware i2c? does it work? :P
<whitequark>
I was surprised
<whitequark>
but yes, it does work
<rqou>
IME atmel's also works
<whitequark>
awygle: so we can load the 68013A's firmware and FPGA's bitstream into the same chip
<rqou>
ST's (at least the one in the F4s, the F3s have a newer one) pretty much doesn't work
<whitequark>
reprogram it in the same way from 68013
<whitequark>
and upload 68013A firmware and FPGA bitstream at will
<whitequark>
that seems quite desirable to me
<awygle>
hmm, i'm not sure variable Vio per bank works at all in that config
<awygle>
because SPI has to be on bank 1, which means it has to speak cypress vio, but there's not enough room for the whole interface
<awygle>
i guess we could use the 17 pins of bank 0 to do _both_ dut interfaces
<whitequark>
yes, I was thinking about that.
<whitequark>
it limits us to one Vio at a time.
<whitequark>
but maybe that's fine?
<whitequark>
harder to mess up, anyway :P
<rqou>
btw, why 4 jtags?
<awygle>
except more damaging if you do mess up
<whitequark>
oh it should obviously have protection on all pins
<whitequark>
by protection I mean it should continuously tolerate short-circuit between any of them
<whitequark>
so I think that means external clamping diodes for every FPGA pin or at least current-limiting resistors (not sure what's going to limit Fmax worse)
<whitequark>
and voltage regulators that don't burn themselves out
<awygle>
are we doing the Vtarget sense thing?
<whitequark>
how does that work out pinout-wise?
<awygle>
it wouldn't affect pinout since we'd need an external ADC, we can hang it on that same I2C bus
<whitequark>
no, I mean, the daughterboard pinout
<awygle>
it's already in the bus blaster pinout
<awygle>
just don't hook it up if you're not using it in your daughter board
<whitequark>
oh VTG is an input
<whitequark>
and... it can also be hooked to 3V3
<awygle>
yes, i was specifically talking about the input version
<whitequark>
hmm.
<whitequark>
good question.
<whitequark>
so what will we do with the value read from that ADC?
<rqou>
random question: does ice40 have esd clamps to vccio?
<awygle>
use it to calculate the value written on the DAC that's setting VIO
<rqou>
because s6 doesn't, and so series resistors to limit current don't work
<awygle>
a problem is that if we put both DUTs on bank 0, and one DUT asks for 1.8v and the other for 3.3v, you'll get 3.3v out if you implement the sense in a naive way
<awygle>
solveable just something to pay attention to
<whitequark>
yes, that's what I'm talking about
<whitequark>
so in case of conflicts this will need to be reported somehow, will it?
<awygle>
i'd say default to the lower value and report, yes
<whitequark>
when will the value be latched in?
<whitequark>
when/if...
<awygle>
it could be allowed to vary continuously
<awygle>
although
<whitequark>
that seems quite complex to do well
<awygle>
if you configure the i/o for LVCMOS18 and then change to a 3.3V VIO
<awygle>
you won't get the best performance at the very least
<whitequark>
iCE40 doesn't have I/O voltage configuration in the bitstream
<awygle>
oh good. never mind
<whitequark>
if it's allowed to vary continuously that basically means polling I2C ADCs...
<awygle>
this kind of thing is sort of inherently complex to do without blowing up the DUT
<whitequark>
precisely
<awygle>
i mean even without sensing
<awygle>
communicating between independently-powered ICs is always complicated
<awygle>
in any case. we could punt on this, put the ADCs on the board, and decide later whether to populate them/write the software.
<whitequark>
sure.
<whitequark>
what about the DAC+Vadj?
<awygle>
i think that's valuable, bordering on required
<awygle>
and it sounds like we can't split the DUT voltages
<awygle>
unless we use discrete level shifters
<awygle>
which is cost and complexity
azonenberg_work has joined ##openfpga
<whitequark>
I think we can't afford discrete level shifters without going to an FPGA with much more I/O
<awygle>
yep. so one DAC for Vadj, footprints for two ADCs, figure out the rest later
<whitequark>
... but if we go to an HX4K we have four banks in the first place, so no need for that
<whitequark>
oh, HX4K isn't available in QFN
<whitequark>
only in an absolutely gigantic 144-pin QFP
<awygle>
no, only 20mm QFP
<awygle>
the 0.8mm BGAs don't exist either, even if we wanted dto go that way
<whitequark>
TQ144, no?
<whitequark>
I don't see a 20mm QFP
<awygle>
TQ144 is 20mm square
<whitequark>
oh nvm I misread what you wrote
<whitequark>
yes
<whitequark>
I don't want to touch that package
<awygle>
the only alternative i see is an LP1K QFN if we could fit in it, which i doubt
<cr1901_modern>
iCE40 doesn't have I/O voltage configuration in the bitstream <-- it doesn't?
<whitequark>
LP1K seems very small.
<awygle>
and it's not secretly an 8K or anything, so i think ti's a nonstarter
<whitequark>
only has a 8KB of BRAMs too
<whitequark>
5K has 15KB of BRAMs...
<whitequark>
but also a lot of SPRAM
<whitequark>
awygle: okay, so what Vadj are you thinking about?
<whitequark>
or just bare DAC?
<azonenberg_work>
whitequark: at least we agree that tq144 is an awful package that nobody should ever use
<azonenberg_work>
Lol
<whitequark>
cr1901_modern: it doesn't. if you want to do LVDS you need to emulate it with resisters
azonenberg_work has quit [Ping timeout: 260 seconds]
<cr1901_modern>
Oh right, I remember reading that. But I thought the Synopsis/Diamond tools let you specify I/O voltages (could be misremembering. or the tool itself lies about setting the voltages)
<whitequark>
cr1901_modern: you only get to set the IO standard to SB_LVDS_INPUT for Bank 3 on LP/HX devices
<cr1901_modern>
Interesting
<whitequark>
huh, apparently you can implement FPD-Link in ice40
<GitHub180>
Glasgow-JTAG/master b7fc4ad Andrew Wygle: Implement TCK-only shifts
<pie___>
carry on \o/
<awygle>
I've got to run. If we can run at 1.8v and let the level shifter do all the work we can save what, like 6$ off that? Or we could drop input protection to meet a bom cost target.
<awygle>
TTFN, ta ta for now
<whitequark>
awygle: 3.22 on ADCs I guess?
<awygle>
whitequark: plus the dac. Wouldn't be needed.
<whitequark>
unless we want to always have Vtarget and never want to generate
<whitequark>
well, let's see what the BOM comes out to first
<whitequark>
ooof the QFN Cypress is $6 more than the SSOP one
<whitequark>
it's limited by 50 MHz, but I'm fine with that being the cost of 5V tolerance and significantly improved safety and simplicity of use
<whitequark>
after all there's no reason we can't lay the board to be alternately configurable with the FPGA IO bank exposed bare
digshadow has joined ##openfpga
* azonenberg
looks
rohitksingh_work has quit [Read error: Connection reset by peer]
<azonenberg>
whitequark: so first problem, it wont work anywhere that has a pulldown (it requires 200K pullups)
<rqou>
azonenberg: what's the expected amount of voltage derating for wet electrolytics?
<azonenberg>
it may not handle strong pullups right either (i.e. the driver might not be able to fight the pullup and it'll think the input is an output)
<azonenberg>
That's my big problem with the auto-sensing parts
<azonenberg>
rqou: its been so long since i last used one that i don't have a rule
<rqou>
lol ok
<azonenberg>
i'd have to look at the datasheet, 50% is probably conservative
<rqou>
hmm
<azonenberg>
i.e. use a 25V for a 12V rail
<rqou>
so i'm doing the teardown for my power electronics class...
<rqou>
and the adapter has 25V caps on the output that can supposedly go up to 24V
<azonenberg>
But if i'm doing a new design a wet electrolytic is going to be the LAST option
<azonenberg>
Once i've exhausted all solid-state options
<azonenberg>
And since i dont really do power electronics, the odds of me doing such a design are low
<azonenberg>
To give you an idea...
<azonenberg>
let me find you a part
<rqou>
what do you think about 25V caps on a 24V rail?
<azonenberg>
i'd say you should read the datasheet *very* carefully
<azonenberg>
before even considering it
<rqou>
the datasheet doesn't have a derating curve lol
<rqou>
these are chemi-con KZE caps
<azonenberg>
If i cant find a derating curve for C/V, or any estimates of lifetime at various parameters
<rqou>
also note, this isn't my design
<azonenberg>
i honestly probably wouldn't use the cap
<rqou>
blame targus or the OEM :P
<azonenberg>
the #1 criterion for me to use a passive in a design in any remotely critical application is a very good datasheet
<azonenberg>
for a MLCC the first thing i look at is C/V
<azonenberg>
if i dont see that curve linked directly on the digikey page, i probably wont use the part
<whitequark>
I had an incomplete understanding of how it works
<azonenberg>
whitequark: So basically you probably want to use a manually configured level shifter with OE hard-wired high for the outputs (or maybe to an FPGA GPIO for tristate if you want that)
<azonenberg>
and then either a comparator (if you want precision thresholds) or some resistors and such for the input stage
<azonenberg>
At that point you basically have a simpler, less robust version of the starshipraider i/o cell
<azonenberg>
(since you're targeting up to 5V but at lower speeds than I am, and not requiring resistance to +/- 12V DC faults)
<azonenberg>
for jtag only, what you have is probably fine
<azonenberg>
i mostly wanted the higher performance to be able to do things like using it as a logic analyzer
<azonenberg>
or "netcat > gpio"
<rqou>
oh btw whitequark are you familiar with power electronics? iirc you had some vaguely-power-related-stuff on your blog?
rohitksingh_work has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
balrog has quit [Ping timeout: 248 seconds]
bitd has joined ##openfpga
<rqou>
wtf
<rqou>
apparently the way printing an ipython notebook to pdf looks depends on how you split up the cells
rohitksingh_work has joined ##openfpga
<rqou>
why is it that *) all "scientific" software sucks *) all software for putting things onto dead tree/dead tree simulations sucks
rohitksingh_work has quit [Read error: Connection reset by peer]
<whitequark>
rqou: I did
rohitksingh_work has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
FabM_cave has joined ##openfpga
FabM_cave is now known as FabM
<pie___>
idk i think word probably doesnt suck at printing
rohitksingh_work has quit [Read error: Connection reset by peer]
futarisIRCcloud has joined ##openfpga
<rqou>
heh, i decided it would be "fun" to poke at the ancient max+II and WinCupl and i almost forgot what "that era" of windows was like
<rqou>
full screen green-colored installer backgrounds with the three different progress bars
<rqou>
installing mfc40
<rqou>
etc.
rohitksingh_work has joined ##openfpga
bitd has quit [Ping timeout: 252 seconds]
bitd has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 256 seconds]
noobineer has joined ##openfpga
noobineer has quit [Ping timeout: 276 seconds]
rohitksingh_work has quit [Read error: Connection reset by peer]
ondrej2 has quit [Quit: Leaving]
clifford has quit [Read error: Connection reset by peer]
clifford has joined ##openfpga
gnufan has quit [Ping timeout: 268 seconds]
soylentyellow has quit [Ping timeout: 256 seconds]
gnufan has joined ##openfpga
gnufan has quit [Ping timeout: 268 seconds]
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.2/20180316222652]]
<awygle>
oh no it's early
gnufan has joined ##openfpga
_whitelogger has joined ##openfpga
Patater has joined ##openfpga
ovf has joined ##openfpga
FabM has joined ##openfpga
<felix_>
rqou: haven;t really looked at skylake and newer, but on pre-skylake core i platforms the pch soft straps weren't signed (maybe some checksum, but definitely nothing cryptographic)
<balrog>
the rows are even slightly different, the matrix is non-singular.
<balrog>
matrix: if two rows are exactly equal, the matrix is singular. But if
<balrog>
basically -- floating point error introduces that undesired random noise and makes your matrix non-singular
<balrog>
(and therefore invertible, but not in a useful way)
<digshadow>
I'm using integers
<balrog>
ohh... right
<digshadow>
maybe you could still get errors
<balrog>
yeah, but still, if you're computing numerically, you can have error
<digshadow>
but I feel its going to be a lot less
<balrog>
you'd have to compute symbolically (meaning arbitrary-length integers), which is what sympy does
<digshadow>
2.0 / 1.0 is exactly 1.0
<digshadow>
ah
<digshadow>
interesting
<digshadow>
but yeah
<digshadow>
I guess if it computes 1.0 / 3.0
<digshadow>
that will have roundoff error
<balrog>
yes
<balrog>
and a reduced matrix may have fractional values
<balrog>
likely will, even if the initial matrix is integer
<balrog>
integer constrained*
<digshadow>
taking a step back
<egg|easter|egg>
meow? numerics?
<digshadow>
I can do frequency analysis on the source sparse rows without too much effort
egg|easter|egg is now known as egg|egg
<digshadow>
and I was playing around with identify the correlated rows in the source data
<balrog>
egg|egg: I was gonna ping you :D
<egg|egg>
hehe
<digshadow>
if I can tell the whole set of correlated values, and not just one that could be removed to make the matrix invertible, thats actually al ot more valuable
<egg|egg>
balrog: you said floating point, numerically, and roundoff, you pinged me already :-p
<balrog>
egg|egg: you have pings set for all that? :o
<egg|egg>
yes
<balrog>
ahahah
<egg|egg>
also double, which sometimes has false positives
<balrog>
LOL
<egg|egg>
please don't double check,
<egg|egg>
or integrate
<digshadow>
we've doubled the floats in the pool this year
<digshadow>
balrog: so what I'm also getting at though
<digshadow>
is the matrix level the correct level to work at, or does it sounds like I should fundamentally be working on the source rows
<digshadow>
do I loose too muchin formation by the time its in a matrix?
<balrog>
I'm still not sure what you're trying to do here
<balrog>
maybe I missed part of the question
<digshadow>
balrog: "Other: the rows of the dense matrix I'm trying to solve are random linear combinations from a large set of sparse rows. I'm also exploring what can be done directly on the sparse rows"
<egg|egg>
balrog: uh so invertible matrices are dense in all matrices right
<digshadow>
egg|egg: a matrix doesn't have to be dense to be invertible
<egg|egg>
digshadow: wrong dense
<egg|egg>
I mean in the sense that near every matrix is an invertible one
<digshadow>
gotcha
<egg|egg>
which means that a criterion "invertible/not invertible" is unlikely to be what you want if your matrix is the result of a computation (because the value of the criterion will just be random crap as balrog says)
<egg|egg>
some sort of conditioning of whatever maybe?
<egg|egg>
shampoo and ill-conditioner
<digshadow>
egg|egg: can you clarify? I'm not following
<digshadow>
what will be random crap
<egg|egg>
digshadow: assume you have a predicate IsInvertible and you apply it to a matrix M in floating-point which is the result of a (well-behaved, but rounded) computation
<egg|egg>
the predicate is not very useful
<digshadow>
isinvertible is not the answer I want
<digshadow>
I already have that
<digshadow>
I want an explanation of why its not invertible
<digshadow>
what I'm hearing is there are two ways to answer that
<digshadow>
1) use simpy function linked
<egg|egg>
the thing is a matrix can be invertible and be ~just as bad for practical purposes
<digshadow>
2) sounds like SVD may in fact provide that, but I need to understand it better
<digshadow>
balrog: do above points sound accruate
<balrog>
still haven't gotten to what you're trying to accomplish :/
<egg|egg>
same
<egg|egg>
digshadow: you may have isinvertible, but it's unlikely to be useful to start with
<egg|egg>
I'm unconvinced that you care about the boolean property "invertible or not" unless there is a lot of context
<egg|egg>
rather than, say, the condition number
<egg|egg>
whence the matrix and what for
<digshadow>
egg|egg: I'm telling you I don't care about that property specifically
<balrog>
digshadow: I assume all your matrices are square because you're talking about invertibility
<egg|egg>
yes but you start with that property
lexano has quit [Ping timeout: 264 seconds]
<egg|egg>
what is the more general property you care about
<digshadow>
did you understand this statement: "Other: the rows of the dense matrix I'm trying to solve are random linear combinations from a large set of sparse rows. I'm also exploring what can be done directly on the sparse rows"
<egg|egg>
i.e. what are you trying to do with the matrix
<egg|egg>
okay so you are trying to solve a linear system?
<egg|egg>
then you care about the condition number
<egg|egg>
it is infinite if the matrix is not invertible, but if it's large you're just as screwed
<digshadow>
I need more than a single number
<digshadow>
I need an explanation of why the solution is poor
<digshadow>
some of the variables are changing together. I need to identify those groups
<egg|egg>
okay but this has to be about "why is the condition high" rather than "why is it not invertible"
<digshadow>
that is semantics to me
<digshadow>
sure
<egg|egg>
"why is it not invertible" is not a useful question if "is it invertible" is meaningless
<digshadow>
egg|egg: I'm working with integer values. If I used sympy, they are equivilent from what I can tell
<egg|egg>
wait are we talking about doing the solving in floating-point arithmetic or symbolically
<digshadow>
that isn't really the point, I'll just roll with condition high
<digshadow>
Lets say that is the problem, what would you ask next?
<egg|egg>
then maybe the singular values can help you but I really don't understand where your matrix comes from remotely enough to say something useful
<balrog>
^
<digshadow>
Okay, then lets elaborate on that
<egg|egg>
also at that point even if I did I would probably have to summon a more powerful numericist because this is getting interesting
<digshadow>
I run timing analysis on a large number of FPGA nets
<digshadow>
I generate a timing score and path
<digshadow>
I trace along the path and tally up the different delay element types along that path
<digshadow>
this gives me an equation like 3 t0 + 2 t1 + 7 t2 = 123
<digshadow>
where I found 3 delay elements of model type t0, 2 of model type t1, and 7 of type t2, which produced a total delay of say 123 ps
<digshadow>
I then trace another path and get something like this
<digshadow>
6 t0 + 4 t1 + 7 t2 = 200
<digshadow>
I need to figure out that 3 t0 + 2 t1 always occurs together
<digshadow>
for example, you have a delay model going into and out of a switchbox. Regardless of the timing paths through there, you are always going to hit the input and output delay model
<digshadow>
but since you always have to go into and then out of a switchbox, they are essentially the same delay element
<digshadow>
Does that make sense?
<egg|egg>
yes but now approaching it as a numerical linear algebra question makes less sense to me
<egg|egg>
this seems extremely discrete
<digshadow>
okay, what is your suggestion?
<egg|egg>
I don't know
* egg|egg
casts "summon numericist"
<balrog>
digshadow: those coefficients will have a random error though, right?
<digshadow>
balrog: I'm over simplifying things
<digshadow>
Lets just focus on this simplied problem for now
<balrog>
okay
<balrog>
ah, but easily discretized by rounding due to the physical system being discrete?
<digshadow>
balrog: if you want to get into it
<digshadow>
the issue is that they are actually closer to inequalities
<digshadow>
you can get things like this
<digshadow>
t0 + t1 = 100
<digshadow>
t0 + t1 = 120
<digshadow>
That is why ultimately we are feeding this into linopt
<digshadow>
which does seem to be a pretty good fit for it, but we need to understand how to provide it better input dat
<digshadow>
a
* egg|egg
casts *summon numericist* again
* digshadow
casts *summon someone with better communication skills*
bofh_ has joined ##openfpga
<digshadow>
egg|egg: what information would have helped to understand the problem better earlier, now that you have a better understanding?
<egg|egg>
digshadow: *summon numericist* seems to have worked
<egg|egg>
digshadow: well, the explanation of how you get the matrix and what it's for is extremely useful
<egg|egg>
because without it the question is devoid of actionable meaning
<egg|egg>
here it becomes optimization and bofh_ will know better
lexano has joined ##openfpga
<bofh_>
digshadow: well for starters your problem seems to be a graph optimization problem that gives you an integer program, I'm just trying to remember *which* particular graph program it is.
<bofh_>
(first and most important question: is the matrix you're getting symmetric/hermitian?)
<digshadow>
bofh_: yes, that sounds about right. I've been playing around with some graph like correlation stuff
<digshadow>
bofh_: I'm don't know how to answer that question, I'm reading up on that
<bofh_>
do you get a matrix which looks the same when you transpose it, basically?
<digshadow>
no
<bofh_>
so the logs aren't clear on this - are you trying to explicitly calculate a matrix inverse, or are you computing a pivoted LU decomposition and then solving that via back-substitution? (the latter is what you want to do always)
<cr1901_modern>
bofh_: Ahhh so you _do_ use IRC :P?
X-Scale has quit [Ping timeout: 255 seconds]
<egg|egg>
cr1901_modern: only after eggstensive summoning
<rqou>
azonenberg: why do you have both C and R footprints that are identical?
<cr1901_modern>
egg|egg: Please no puns, they burn my retinas
<bofh_>
cr1901_modern: yea, like I've always been on this network lol
<cr1901_modern>
bofh_: Ahhh I suppose we just haven't crossed paths, in say a ##yamahasynths channel yet lol
finstern1s has quit [Quit: leaving]
finsternis has joined ##openfpga
<bofh_>
cr1901_modern: *is* there a yamahasynths channel?!?
mumptai has quit [Quit: Verlassend]
X-Scale has joined ##openfpga
<cr1901_modern>
bofh_: No lol
<cr1901_modern>
If there is I'm not aware of one
<azonenberg>
rqou: different 3d models
<azonenberg>
same land pattern, i think
<digshadow>
bofh, egg|egg: back, some things came up
<digshadow>
bofh_: my maths aren't good enough to easily answer that question
<digshadow>
but the shorter answer is
<digshadow>
I want to find values for a bunch of constants. If constants are aliased together, I want to identify that and make that noted in the solution
<digshadow>
with the source input being a bunch of sparse rows each containing a few of those constants
noobineer has joined ##openfpga
<rqou>
is this system overdetermined?
<rqou>
digshadow?
<egg|egg>
bofh_: cr1901_modern: I mean, you can make one you know
<rqou>
all of you are a bit _too_ crazy about OPx synths :P
<digshadow>
although on that note, there has been some interest in CEM3394 recently
<rqou>
i know
<Ultrasauce>
I really need to get around to using the tube of ym3438s i have kicking around
<cr1901_modern>
rqou: 1. It was an example of shared interests. 2. Pot meet kettle?
<rqou>
i was talking about your matrix equation thing
<cr1901_modern>
I mean few ppl know the VRC7 is undumped
<Ultrasauce>
it's weird randomly looking at this channel and seeing yet another thing I'm into
<cr1901_modern>
Ultrasauce: Tbf, there's a lot of overlap w/ MAME and emulators, and ppl who do decap. And YM synths are prime targets for those b/c they're so badly-behaved if you don't emulate them well.
<cr1901_modern>
Not to mention they just sound nice :D
<cr1901_modern>
Someone decided it was a good idea to try emulating an OPN chip using Adlib OPL. This is the result.
<Ultrasauce>
a pleasant serenade
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 264 seconds]
[X-Scale] is now known as X-Scale
<digshadow>
Hmm not sure I see the connection to the synths and this channel so much, but one thing I was hoping was that there would be an FPGA mame folk would be interested in that they would subsequently document for openfpga
<cr1901_modern>
>not sure I see the connection to the synths and this channel so much
<cr1901_modern>
digshadow: I was getting at that MAME needs a lot of decap, and a lot of ppl who do decap/IC RE also idle here.
<digshadow>
gotcha
<digshadow>
sarayan is noticeably missing
<cr1901_modern>
Hrm, that's true
<cr1901_modern>
Don't you mostly provide decap for MAME ever since things fell thru w/ CT/Dr. Decap?
<digshadow>
I do things occasionally, but not too much these days
<cr1901_modern>
Ahhh
* cr1901_modern
updates his priors
<digshadow>
part of the issue was that I was unclear what the impact of a lot of that was
<digshadow>
but as you may be aware, I did help with the TGP digitization by hosting it on sipr0n and collating the results
<cr1901_modern>
I mean the impact afaict is: Ppl get to play video gaems more like the hardware manufacturers intended. Not exactly a goal that'll, say bring about world peace.
<cr1901_modern>
Oooh, very nice
<cr1901_modern>
Oh, the Virtua Racing chip
<awygle>
these logs are a wild ride today
bitd has quit [Remote host closed the connection]
<digshadow>
awygle: feel free to smack the chan back into topic
<digshadow>
I was also nudged to look at vpr stuff some more
<cr1901_modern>
awygle: The best forums/IRC channels are where the topic is allowed to derail, tbh
Bike has joined ##openfpga
<digshadow>
cr1901_modern: to some degree. I was trying to contribute to panotools a while back, but I abaonded it because their mailling list had too much OT
<cr1901_modern>
Hmmm...
<awygle>
digshadow: I don't understand the value of grouping finer delay elements into larger structures
<awygle>
cr1901_modern: I find that to be true when the community is small (maybe a Dunbar issue, idk)
<digshadow>
awygle: if two elements alias each other, they can't be individually resolved
<digshadow>
the solution is then ambiguous
<awygle>
Ah, I see
<digshadow>
awygle: to elaborate further, there are a lot of scenarios where a => b, but not b => a. This results in branching solutions that need to be carefully combined
<awygle>
This sounds like it might be overly ambitious. That is, it may be easier to generate many instances of the minimal path and come to an understanding of just that structure, then use that to simplify larger systems.
<digshadow>
awygle: sure, reporting which paths are ambiguous may be enough
<digshadow>
which is something I can do today
<digshadow>
maybe I should focus on that more
<cr1901_modern>
off-topic, since it's Slack-bashing day on my Birdsite feed, I'm so glad that most ppl I talk to still use IRC
<qu1j0t3>
always up for bashing Slack; this week it's decided not to take or receive calls
<qu1j0t3>
(which i never wanted, but now of course people rely on that)
<qu1j0t3>
make or receive*
<qu1j0t3>
even the font they picked is crap, a constant irritation (yes I hate Lato)