<azonenberg_work>
whitequark: yeah thats what i'd do
<azonenberg_work>
(you see why starshipraider is going to have a DAC+comparator based input stage now?)
<whitequark>
unfortunately
<whitequark>
hm i wonder if you could just put an ADC on every channel
<azonenberg_work>
starshipraider is going to have a single dac shared by each 8 bit io bank for setting the output level, plus another for the input threshold
<azonenberg_work>
Also a slow adc for tracking an external reference voltage
<azonenberg_work>
Per bank
<azonenberg_work>
Then each input buffer is a comparator
<whitequark>
right, this is similar to how glasgow works :D
<azonenberg_work>
So in total with the full system you'll have four ADCs, four vref dacs, four vcco dacs
<whitequark>
I have a single slow ADC and a single DAC for setting thresholds
<azonenberg_work>
And, the cool part is
<azonenberg_work>
since the vref tracking is done FPGA side...
<azonenberg_work>
You can do all kinds of nasty things like having VCCO[bank2] be VREF[bank1] * 0.8
<whitequark>
azonenberg_work: the way I handle this is I have the ADC pull alert
<azonenberg_work>
The only hardware restriction is that all input buffers in a bank share the same vref, and all output buffers share the same vcco
<whitequark>
when the voltage is out of range
<azonenberg_work>
whitequark: you misunderstand
<azonenberg_work>
i meant that you have the option of using any vref pin for any purpose
<azonenberg_work>
it's not dedicated to that bank
<azonenberg_work>
So you can have bank 1 be driving fixed 3.3V with 1.65V threshold
<azonenberg_work>
and repurpose bank 1's vref pin as the input threshold for bank 2
<azonenberg_work>
while using bank 2's vref as the output level
<azonenberg_work>
Or any other weird combination
<whitequark>
sure
<whitequark>
glasgow can do that too
<whitequark>
it's just not currently supported in software
<azonenberg_work>
How many banks goes glasgow have?
<whitequark>
two
<whitequark>
two ADCs and two DACs
<azonenberg_work>
ah so one for each mpsse
<whitequark>
yes, if you configure it for mpsse
<azonenberg_work>
Is there an out of band usb command to do things like reading the adc directly?
<whitequark>
yep
<whitequark>
$ glasgow voltage
<whitequark>
:p
<azonenberg_work>
well i meant, something outside the ftdi protocol you are emulating
<whitequark>
sure
<whitequark>
FTDI doesn't have adjustable Vref
<azonenberg_work>
Exactly
<whitequark>
I actually don't emulate FTDI right now
<azonenberg_work>
oh?
<azonenberg_work>
You're using your own protocol?
<whitequark>
yes
<azonenberg_work>
ah ok, thats better :)
<whitequark>
glasgow *started* as an FTDI replacement
<whitequark>
but it will have FTDI compatibility as an option instead
<azonenberg_work>
ah ok
<whitequark>
it'll ship with an FTDI compat bitstream flashed so it works with openocd out of the box
<azonenberg_work>
Any interest in writing a jtaghal driver for the glasgow native protocol?
<whitequark>
but native mode is way more powerful
<whitequark>
I actually pinged you earlier
<azonenberg_work>
oh? must have missed that
<whitequark>
I absolutely want that because I have this chip with SWD
<whitequark>
and I don't have an SWD debugger
<whitequark>
so like I have a use case *right now*
<azonenberg_work>
So, you should probably wait another couple of days then
<azonenberg_work>
in case you havent seen the commit history
<azonenberg_work>
i am actively implementing swd support for jtaghal right now
<whitequark>
can you uh
<whitequark>
can you implement some sort of "generic SWD protocol" in jtaghal
<whitequark>
just whatever you think is convenient
<azonenberg_work>
You want the ADIv5 specification section 4.3 or thereabouts
<azonenberg_work>
they have full timing diagrams
<azonenberg_work>
this is my very WIP untested MPSSE SWD implementation
<azonenberg_work>
I have to do some nastiness because MPSSE does not support bidirectional TDI
<azonenberg_work>
So i have to hard wire TDI to TDO with an external connection and then tristate TDI when i want to read TDO
<azonenberg_work>
(both physically wired to SWDIO on the DUT)
<whitequark>
right
<azonenberg_work>
Another WIP item that i've thought about but not coded up yet
<azonenberg_work>
is how to figure out what i am talking to
<azonenberg_work>
JTAG you have the JEP106 idcode in the IDCODE instruction
<azonenberg_work>
With SWD you dont have that
<azonenberg_work>
The MEM-AP has a ROM table that lets you figure out what ARM IP cores are present
<azonenberg_work>
but you cant distinguish one chip with a single cortex-m3 from another
<tpw_rules>
yeah afaik that's a manufacturer specific thing. most of them have chip ID registers
<azonenberg_work>
My plan is to allow you to either hard code "this is a stm32f103" or read a set of addresses that are known to contain IDs for different devices
<azonenberg_work>
and see which ones come out sane
<azonenberg_work>
then try to narrow it down
<whitequark>
seems fine
<azonenberg_work>
autodetect mode will be default
<whitequark>
ok so my plan is to add an SWD applet to Glasgow
<azonenberg_work>
There is a small risk that reading random SFRs could cause unpleasant side effects
<whitequark>
that will let me read/write transactions from command line
<azonenberg_work>
but in general reading is fairly safe
<whitequark>
and then write a backend for jtaghal once that works
<azonenberg_work>
whitequark: have you played with jtagsh yet?
<azonenberg_work>
You probably want to use it and just add a glasgow backend
<whitequark>
so "jtag pirate"
<azonenberg_work>
i have support for ADI already
<azonenberg_work>
i can flash stm32s over JTAG-DPs already
<azonenberg_work>
I just dont have the SW-DP or SWJ-DP supported yet
<azonenberg_work>
But above the transport layer all arm debug is the same
<azonenberg_work>
One of the TODOs to add SWD support is to do the custom-binary-protocol to protobuf revamp
<azonenberg_work>
Because the current network protocol between jtagd and jtagsh assumes JTAG is the transport
<azonenberg_work>
the new protocol supports multiple transports
<azonenberg_work>
i have a draft .proto in the repo but don't actually do anything with it yet
<whitequark>
ok so I need a glasgow applet for SWD anyway
<azonenberg_work>
that was where i left off yesterday
<azonenberg_work>
Yeah you need the fpga support no matter what
<whitequark>
yep
<azonenberg_work>
But i think you are better off using my host side software and just writing a backend
<whitequark>
and it doesn't hurt to let you do SWD txns from CLI
<azonenberg_work>
You can use the jtaghal API directly now for SWD (well, the portion of SWD i have implemented so far lol)
<azonenberg_work>
But you can't run it over the network yet which means you cant use jtagsh yet
<azonenberg_work>
i've thought of adding a no-network self hosted mode for jtagsh that just connects to a JtagInterface it created, but that will require refactoring the "create a jtaginterface from command line args" code in jtagd into a standalone function
<azonenberg_work>
Which i probably should do anyway
<azonenberg_work>
(pull requests welcome :P)
<whitequark>
hmmm I kind of have my hands full with this USB PD shit
<whitequark>
it's pretty high but i do have a yak shaving stack limit
<whitequark>
writing my own SWD impl is fine
<whitequark>
but working on jtaghal right now is probably not happening
<azonenberg_work>
Ok
<tpw_rules>
if i may interrupt, how is glasgow itself coming along?
<azonenberg_work>
whitequark: how about a SWDInterface and/or JtagInterface derived driver class for glasgow?
<azonenberg_work>
it would probably be simpler if you were to implement the host and device side of the protocol at the same time
<azonenberg_work>
vs trying to document/explain the protocol and then have me write it
<whitequark>
azonenberg_work: yeah sure I can do that
<whitequark>
tpw_rules: I figured out the major problem which is glitches on fx2 bus
<whitequark>
and I asked awygle to proceed with assembling revB
<whitequark>
and then revC once I review it
<whitequark>
so it's progressing nicely
<whitequark>
there's quite a few applets already and they help me a lot in practice
<whitequark>
in fact for the last few months I constantly use glasgow in real work
<tpw_rules>
awesome! i'm looking forward to buying one. i don't know if you saw, but i think i'm going to re-fork migen and have a more fleshed out hack of it that can get merged back in. and of course work on my own gateware, i'm still interested in the CAN one
<whitequark>
tpw_rules: seen it yes
<whitequark>
i'm not sure how i feel about a fork of migen
<whitequark>
but i will keep an eye of it
<azonenberg_work>
whitequark: awesome
<whitequark>
i think it's important that the glasgow codebase use a consistent style
<tpw_rules>
i remember you said you'd prefer gateware be written in 'real' migen
<tpw_rules>
yes
<azonenberg_work>
i'm looking forward to the point that starshipraider reaches that point
<azonenberg_work>
Right now jtaghal is mature enough (for the stuff i work with often, at least) that i use it on a daily basis at $dayjob as well as in my own projects
<tpw_rules>
where did the name come from?
<whitequark>
name of what?
<whitequark>
azonenberg_work: excellent
<tpw_rules>
STARSHIPRAIDER
<whitequark>
i really don't want to write my own jtag/swd code
<whitequark>
so even though i'd normally do it all in python i am more than fine with reusing jtaghal
<azonenberg_work>
whitequark: yeah jtaghal is designed to be very easy to add new chip support to
<whitequark>
it beats openocd anyway
<azonenberg_work>
New transport layers are a bit more work
<whitequark>
openocd is
<whitequark>
weird.
<azonenberg_work>
in particular the *first* new transport layer ever :p
<azonenberg_work>
(this is my first time using it for anything but jtag lol)
<sorear>
What was the final verdict on the revB glitches btw?
<azonenberg_work>
so some refactoring needed there
<azonenberg_work>
and lol yes
<azonenberg_work>
I am only starting to compete with openocd very recently, until now i was entirely FPGA targets and they were mostly MCUs
<rqou>
awygle: no
<azonenberg_work>
But now there is nontrivial overlap in the feature set
<azonenberg_work>
sorry i meant {mode of transportation, thief} + {2{future}}
<whitequark>
sorear: I didn't use I/O registers
<rqou>
also wtf why am i so tired?
<tpw_rules>
lol i like it
<whitequark>
after I rewrote everything to use SB_IO registers clocked by the FX2 clock
<whitequark>
everything started working reliably
<awygle>
rqou: oh, nvm them
<rqou>
awygle: why?
<awygle>
rqou: I was gonna ask you to check something for me but it's not important
<rqou>
whitequark: how do i make myself less tired all the time other than by sleeping more? :P
<whitequark>
rqou: stimulants?
<whitequark>
start with modafinil
<rqou>
right, i think you've recommended that before
<rqou>
is that safe long-term?
<whitequark>
well
<whitequark>
physiologically, yes
<whitequark>
but i dont take any responsibility for burnout
<rqou>
hmm
<awygle>
I am personally enjoying sleeping more
<whitequark>
I can't sleep because clomipramine makes me manic
<whitequark>
I sleep like 4 hours per day tops now
<whitequark>
and I don't want to
<awygle>
I used to sleep like garbage and do shitty work and not know it, now I sleep well enough that when I sleep badly (like last night) I can actually tell my work is much worse
<whitequark>
I never really got anything bad from sleep deprivation, in fact sleep deprivation is a pretty decent antidepressant (comparable to SSRIs)
<whitequark>
unfortunately you can't be sleep deprived all the time
<whitequark>
or well I can't
<whitequark>
I do pretty decent work during mania but not the kind of work that I *need* to do
<whitequark>
I do weird shit like reverse engineering Apple's dongles
GenTooMan has quit [Quit: Leaving]
<azonenberg_work>
awygle: i find that i need at least 3-4 hours to function decently period, and 6+ if it's for an extended period of time
<azonenberg_work>
After ~20 hours of being awake performance definitely starts to deteriorate but even a fairly short nap resets me at least for a couple of days
<rqou>
i seem to get enough hours now that i'm not doing the whole student thing but i'm still tired all the time
<azonenberg_work>
rqou: i actually slept pretty well as a student, comparatively speaking
<azonenberg_work>
Compared to now doing construction and working two jobs :p
<azonenberg_work>
With the occasional 3am phone call from sar thrown into the mix
<whitequark>
rqou: you could also be tired for any number of reasons
<whitequark>
Mg deficiency for example
<rqou>
hmm
<whitequark>
I'd suggest asking a GP but GPs are useless
<whitequark>
in the US
<rqou>
how do i easily measure/fix something like this?
<whitequark>
try taking various supplements and see if it's any better
<whitequark>
vitamin D is another one people often don't get enough of
<whitequark>
the actual amount you need is like 10x what FDA guidelines currently say
<rqou>
given that my current diet is/was "whatever food was being served at $WORK because it's free and i didn't have to cook it"
<whitequark>
because some people fucked up the statistics
<awygle>
whitequark: vitamin d supplements make my skin get itchy when I am about to start sweating
<whitequark>
awygle: hm
<whitequark>
weird
<whitequark>
apnea is a good suggestion too
<awygle>
even at realtively low doses like 2000 IU/day
<rqou>
whitequark: thoughts on the "everything" multivitamins that americans seem to like a lot?
<awygle>
i backed off to 500 IU/day and that seems to be below whatever threshold is happening
<awygle>
the doc suggested it was a liver thing
<whitequark>
rqou: it doesn't really hurt to take them if they're all water soluble
<whitequark>
awygle: could be
<whitequark>
rqou: the utility is questionable too
<rqou>
wtf
<Zorix>
multivitamins usually give me a lot of stomach problems
* awygle
's stomach is a problem just generally
<rqou>
why does it seem like anything "health-related" in the US is just fucked?
<Zorix>
mine too
<Zorix>
because life isnt fair
<awygle>
i know why though, it's because i mostly eat like shit
<awygle>
and am no longer young enough to get away with it
<Zorix>
yea.. i hate that too
kuldeep has quit [Ping timeout: 252 seconds]
<rqou>
whitequark, awygle: any suggestions for "someone who absolutely _hated_ PE and was previously a bit too burned out being a student" to adjust to having "a healthy lifestyle and diet"?
<whitequark>
rqou: oh yeah
<whitequark>
ok well not diet
<awygle>
rqou: running is terrible, try biking/swimming. sports are terrible, try lifting weights.
<rqou>
e.g. "where do i start? wat is a body? wat is a vitamin?" :P
<whitequark>
i have sensory processing issues and i long gave up on trying to get any sort of diet
<Zorix>
best you can do is to cut out processed foods as much as possible, even though its inconvenient
<whitequark>
sure i might die at 60 but if i force myself to eat whatever is "necessary" i'll kill myself at 30
<whitequark>
rqou: ok that's a bit too basic
<rqou>
ok sure
<whitequark>
i can suggest you an exercise regimen
<whitequark>
that wont break your back
<whitequark>
sec
<Zorix>
i used to find bike exercising a nice thing until i started getting knee problems
<awygle>
portion control is almost certainly more important than diet anyway unless you have a specific issue
<rqou>
the problem is that i _hate_ "doing exercise"
<Zorix>
most people do hate it, but you have to get over that part
<whitequark>
like at most three hours per week, and walking fast counts towards it
kuldeep has joined ##openfpga
<whitequark>
you could also find a gf (or bf) and have a lot of sex, that actually helps a lot
<Zorix>
i was doing it 30 min a day
<rqou>
lol whitequark
<whitequark>
no seriously
<whitequark>
Zorix: 30 min a day is even a lot
<rqou>
i assume perusing *boorus don't count? :P :P
<awygle>
sex helps with an enormous amount of things. when i first started having sex all my acne cleared up.
<whitequark>
ha
<Zorix>
probably a lot but i was also trying to build endurance too
<whitequark>
i mean if you just want a "healthy lifestyle"
<whitequark>
you dont need to spend 30 min per day
<awygle>
i bike to/from work now, swim like 30m twice a week, and lift weights like 30m three times a week. which is more than i strictly need, but i want to look good eventually :p
<whitequark>
and you shouldn't because you;re way more likely to just give up
<rqou>
i'm almost certainly getting way less than recommended nowadays
<awygle>
i don't read swimming as "exercise" which helps
<rqou>
i was probably getting "enough" as a student
<rqou>
but it seems that burnout is far more detrimental to health than can be compensated by the exercise you get walking to class
<awygle>
running is the most horrible form of exercise though, i don't understand runners at all. i have literal nightmares about being made to join the cross-country team at my old high school.
<whitequark>
yeah
<whitequark>
awygle: "runner's high"
<Zorix>
yea that joint impact.. on the knees especially
<whitequark>
some people literally get off on it
<Zorix>
will ruin you later in life
<rqou>
interesting, i hated running significantly less than basically any other activity in PE
<rqou>
er, well that's not quite true
<awygle>
whitequark: is that _literally_ associated with running, or just hard aerobic exercise? can you get runners high from biking?
<whitequark>
i hated all PE because it required being in an enclosed space with other humans that were happening
<rqou>
append "until i and other students learned that we needed to game the grading system"
<whitequark>
awygle: aerobic
<awygle>
lol 'other humans that were happening'
<whitequark>
but for some reason runners get it especially often
<awygle>
excellent description
<whitequark>
they're happening so much!
<Zorix>
yea being in close proximity to another smelly sweaty human is not so nice
<awygle>
i hated PE because i was bad at it, basically
<rqou>
i hated PE because of both the teachers and because i was bad at it
<awygle>
also because everyone else saw it as "fun", and i didn't, and that made me anxious
<awygle>
as a teenager still trying to figure out wtf was up with all these other humans and their different opinions than mine
<rqou>
i don't personally know anybody who found it "fun"
<whitequark>
being trans but not realizing it is also very much not conductive to eg swimming
<Zorix>
i took weight lifting in high school.. the football jocks were kind of dicks
<awygle>
sure, i can see that
<tpw_rules>
i hated it because it was basically constant collective punishment
<awygle>
i feel like i might have just missed a much worse PE experience
<awygle>
it seemed like a lot of previously-standard tactics were not permitted anymore
<rqou>
somehow the PE teacher that i had all throughout grades 1-6 (it was the same one every year) just hated me from day 1
<awygle>
i don't even remember PE in grades 1-6. i'm not sure we had it at all
<rqou>
she was also a bitch who would yell at students
<awygle>
well, 1-5 rather. 6-8 had it as did 9, and then i took summer school PE my senior year to graduate
<rqou>
i had PE in grades 1-10 and then it was no longer required
<awygle>
i didn't take it in 10 because i intended to do a sport but then didn't
<rqou>
1-6 was with the bitchy teacher, 7-8 were a blur (as is pretty typical) and 9-10 was learning about "real life" and gaming the system
<Zorix>
hmm i might be the old man here
* awygle
lived 7 and 8 in excruciating detail
<awygle>
middle school is the worst
<awygle>
anyway. enough of this lol
<rqou>
i specifically remember in 9-10 a significant proportion of your grade was "continuous improvement or at least maintaining performance" while running a mile
* awygle
back to something useful
<rqou>
i was an idiot who couldn't read between the lines
<rqou>
so i actually tried hard at the beginning
<rqou>
then got sick some time during the winter and had my time slip back significantly
<rqou>
which results in you being chastised every week
<rqou>
afterwards i warned my sister about this, and a number of people started doing the "optimal" solution of running 10 seconds slower than the auto-fail time the first week
<rqou>
and "improving" by 10 seconds each week
<rqou>
the school then tried to "fix" this by banning students from carrying their own stopwatches
<rqou>
supposedly after that a small group of indian parents went and complained to the school enough that the grading was changed to absolute time buckets
<whitequark>
awygle: don't want to buy stuff
<whitequark>
want it now
<awygle>
don't care how
<awygle>
yeah that just came across my Neverending Stream Of Content so i thought i'd share
<whitequark>
right
<rqou>
anyways, unwinding the stack a bitt
<rqou>
whitequark: how do i squeeze in exercise if i work a boring desk job and don't particularly like to outside?
<awygle>
rqou: how much do you work at your boring desk job?
<whitequark>
rqou: you can exercise at home
<whitequark>
the CDC website has a regimen somewhere
<whitequark>
from that link
<awygle>
you can also exercise at your boring desk job
<whitequark>
I think they changed the structure a bit but you'll find it
<awygle>
which i recommend
<awygle>
since $WORK_I_CAN_DO << $HOURS_I_MUST_BE_PRESENT
<rqou>
the problem is that whenever i start to think "do exercise" my mind is already "nope, don't wanna"
<whitequark>
rqou: hmm
<whitequark>
can you do it at least once?
<whitequark>
like just schedule it with all the other chores
<awygle>
stop thinking about it as "guess i better do this so that someday down the line i don't die at 60", and start thinking about something that matters now. becominig hotter, or beating your previous record, or something. whatever works for you.
<rqou>
i've tried that before, but due to various personal "reasons" it doesn't work more than like a month
<whitequark>
ironically, the former motivates me better
<awygle>
whitequark: my hypothesis is that people motivated by the former don't really need advice in this way
<whitequark>
true
<awygle>
i know several people who started an exercise habit due to basically spite
<awygle>
someone said they couldn't do it and they were like "fuck off i'll show you"
<rqou>
the latter absolutely doesn't work for me
<whitequark>
yeah same
<awygle>
the point is you gotta find a motivation that actually works for you
<awygle>
instead of trying to push through one that isn't
<awygle>
at least ime
<awygle>
also something something therapy
<awygle>
just always all the time
<rqou>
something something untrustable
<whitequark>
untrustable?
<rqou>
not going to go into details in public but let's just say that my experiences with therapists have been "less than stellar"
<whitequark>
oh
<whitequark>
yeah US mental health care is junk
<whitequark>
you're correct to not trust most of those fuckers
<whitequark>
you can find a decent one via skype tho
<whitequark>
it's a Thing
<rqou>
um.. i'd trust that even less
<whitequark>
wait, why?
<whitequark>
they don't have any power over you
<rqou>
idk, i don't really trust people that i encounter only through the interwebs
<whitequark>
that's completely alien to me i guess
<whitequark>
everyone i've ever trusted i've met via the web
<whitequark>
mostly via twitter
<whitequark>
ok with one exception
<whitequark>
possibly two
<whitequark>
ok three
<whitequark>
but that's it
<rqou>
hmm, i usually try to meet IRL the people that i initially meet via the interwebs
<whitequark>
i try to not meet people i don't already trust
<whitequark>
not necessarily like trust completely
<whitequark>
its a spectrum
kuldeep has quit [Ping timeout: 240 seconds]
<rqou>
whitequark: so if i try supplementing vitamin d, how much should i supplement?
<whitequark>
rqou: 8000 IU
<rqou>
how do i "debug" if i should supplement anything else?
kuldeep has joined ##openfpga
<whitequark>
rqou: try magnesium
<whitequark>
or cheese
<rqou>
lol
Bike has quit [Quit: Lost terminal]
<awygle>
... cheese?
<whitequark>
calcium
<whitequark>
milk products
* awygle
has not tried magnesium, but eats a lot of cheese
<rqou>
i like cheese but don't really eat a lot of it
<awygle>
i should try magnesium i guess
<rqou>
i might try that too and work on not being a lazy fatass later
<rqou>
nice ##openfitness discussion :P
<rqou>
much more informative than what they teach you in school :P :P
<awygle>
negative self-talk probably not hugely helpful :p good luck
<rqou>
not-entirely-joking question: can we just delete our K12 health classes and replace them with just whitequark? :P
<whitequark>
lol
<whitequark>
you'll find that many of my opinions are in direct contradiction with your ruling class
<whitequark>
i'll get killed probably
<rqou>
yeah, but many of our ruling class opinions are dumb
<whitequark>
well duh, that's why they're ruling class
<rqou>
e.g. i believe there were some studies that showed that some of our anti-drug programs had negative efficacy
<rqou>
not just zero, negative
<whitequark>
um, yeah
<whitequark>
and very significant too
<sorear>
running away has been a big effect on my fitness, not sure if net positive or negative
<sorear>
food being something I have to spend effort to get means a lot less of it in general
_whitelogger has joined ##openfpga
<fseidel>
any of you guys know why Quartus might be really slow at uploading and occasionally start giving "Can't access JTAG chain" until I reboot my VM?
<rqou>
sorry, don't use the quartus programmer
<fseidel>
I know this isn't quartus support, but I figured maybe one of you had run into this issue
<rqou>
but the usual answer is to blame the vm usb stack :P
<fseidel>
yeah, I figured as much
<fseidel>
welp
<whitequark>
which VM?
<whitequark>
which hypervisor*?
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
<awygle>
oh hey that reminds me - on the hike i did today we were under power lines for part of it and they made a weird, almost rain-like buzzing sound. anybody know why that is?
<awygle>
(i have a theory but i wonder if somebody _knows_)
<rqou>
i don't actually know, but maybe corona discharge?
<azonenberg_work>
magnetorestriction?
<azonenberg_work>
(phases alternately attracting and repelling each other and vibrating against insulators)
* azonenberg_work
afk
<awygle>
azonenberg_work's was my theory
<awygle>
i didn't see any corona discharge, and i did look, but i might not have (they were far away)
<awygle>
(by which i mean high in the air)
azonenberg_work has quit [Ping timeout: 272 seconds]
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work>
Back
<rqou>
is your house done yet? :P :P :P
Miyu has joined ##openfpga
<azonenberg_work>
rqou: we finished hanging rock, taping, and the first coat of mud in the lab
<azonenberg_work>
Tomorrow is sanding and recoating
<azonenberg_work>
The cable tray penetrations were a pain to do
<rqou>
woot, checkpoint! :P
<rqou>
now <strike>draw the rest of the owl</strike>finish the rest of the house
<azonenberg_work>
And they still aren't quite the way i want, one of them baaaarely fits and the other is a tad too small so i may have to put a short section of narrower tray or something
<azonenberg_work>
(not my fault, the studs are too close together and it's a load bearing wall so i can't remove/trim them)
Miyu has quit [Ping timeout: 244 seconds]
<azonenberg_work>
Worst case i can terminate the tray on either side of the penetration and run the wires through
<azonenberg_work>
They'll be fully supported at both sides as well as in the middle
<azonenberg_work>
So it's code-kosher
<azonenberg_work>
the unsupported length would be less than between rungs of the cable tray
<rqou>
do you need firestopping?
<azonenberg_work>
I have a box of the red pillows already
<azonenberg_work>
So i should be ok, unless i have an odd-shaped gap and need to buy a larger/smaller size
<azonenberg_work>
if anything my concern is that the gap will be too small to shove the ones i have in
<azonenberg_work>
But the trays are nominally 2" high (actual height more like 2.5") and they will be (per code) less than half full
<azonenberg_work>
So i should be ok
ayjay_t has quit [Read error: Connection reset by peer]
<rqou>
hmm in general not happy with where the yellow EL wire is
<whitequark>
rqou: wow nice
<rqou>
hmm power routing for "wearables" is hard
<rqou>
actually, constructing wearables is in general pretty hard despite them usually not being very technologically "advanced"
<rqou>
something something sexism
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
<tnt>
Damn, the difference between best & worst timing for the ul5k are pretty huge ... I might just start running them all at 1.3v instead of 1.2v.
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 252 seconds]
[X-Scale] is now known as X-Scale
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
<tnt>
Oh come on ... seriously you can't do A-B in a single layer of logic on an ice40 ?!?
_whitelogger has joined ##openfpga
<nrossi[m]>
has anybody seen behaviour of a ice40 PLL (specifically on a lp8k) where it looses lock every ~2s? The input clock appears fine...
nrossi[m] is now known as nrossi
<tnt>
nrossi: not me ... what board is that on ? supply/decoupling done properly ? Is the input clock duty cycle fine as well ?
<nrossi>
tinyfpga-b2
<nrossi>
tnt: i think it was working fine when i was using the original bootloader firmware, so i'm thinking i just have something configured wrong with the bitstream
<tnt>
can you pastebin the code ?
<nrossi>
tnt: just the pll config, or you want the whole thing as a git repo?
<tnt>
the PLL config and just how it's linked to the input pad
<tnt>
Also are you sure it's not the whole fpga resetting ? The tinyfpga bootloaer has a timeout that resets the whole FPGA if there is no attach within some time after power on ?
<nrossi>
tnt: oh maybe thats whats resetting, i will comment out the reset of the module and test it by itself
<nrossi>
tnt: yep thats the same opinion i had, but since the bootloader for the BX was setup with yosys so i thought it was just a bug in icetime and to just ignore it for the time being
<tnt>
I opened an issue and a patch, but not sure it was ever merged.
<nrossi>
tnt: you wouldn't happen to know where to find the pre-built bitstream binaries for the tinyfpga-b2 bootloader are? (the older bootloader is fine)
<tnt>
No sorry. Even in the git, it seems the -B2 isn't supported yet ?!?
Bike has joined ##openfpga
<tnt>
nrossi: I'm not familiar with difference between BX/B2 ...
<nrossi>
tnt: there is not a whole lot of difference, just the available pins some leds and a bigger spi flash. The problem is i trashed the flash of the original bootloader by accident and was just trying to get it working again ;)
<tnt>
heh ... I tried to build the BX here but it doesn't even build :/
<nrossi>
tnt: interesting setting the boot =0, to prevent the timeout allows for the usb device to appear correctly now
<nrossi>
tnt: no meta data, but the ttyACM node appears now which means potential success!? :)
<tnt>
Just tried the BX one with arachnepnr vs nextpnr : 31.47 MHz for arachnepnr and 23.97 MHz for nextpnr
<tnt>
(I had to fixup the IO buffer to instanciate SB_IO manually and also apply my patch to remove the latches)
<tnt>
mm, yosys didn't infer any RAM, that's not normal.
kuldeep has quit [Ping timeout: 240 seconds]
<tnt>
not sure if there is a way to force yosys to recongnize an array as a RAM ...
kuldeep has joined ##openfpga
<nrossi>
tnt: it has to match the usage, and be inferred/mapped to a compatible bram cell, otherwise it cant map it. I will keep hacking away its at the point where the USB comms are working and the bootloader tool is able to send and receive commands but the spi flash is just responding with FF's
<tnt>
Yeah but icecube infers it as RAM ... and from the verilog, it _should_ be able to map it.
<tnt>
If that's asynchronous ... I need to re-learn verilog.
<tnt>
Arg ... tx_data was initialized as 0 ...
<nrossi>
tnt: yer it has to do with how it infers the registered nature of the read port, which cant have init value
<daveshah>
icecube synthesises it because it ignores init values (including for registers)
<daveshah>
I'm not sure what the "correct" behaviour is, init values are usually ignored in ASIC synthesis but it's a bit more blurred for FPGA synthesis where the init state is actually defined
<tnt>
Now I get 68 MHz with icecube2, 38 MHz with yosys/arachnepnr, 33 MHz with yosys/nextpnr
<tnt>
daveshah: yeah, tbh, I never use init values because I'd rather have an 'undefined' in the simulation for anything that doesn't have a proper reset. Matches what I would expect "in the real world" more closely imho.
<tnt>
interestingly the design generated by icecube still has a logic loop and can't be analyzed by icetime ... weird.
<tnt>
daveshah: btw, unrelated question : do you know if the icecell can both use its local output to feed the chain with the cell above it and its "normal" output to use the DFF ?
<daveshah>
tnt: yes, although neither arachne nor nextpnr support that (if you mean LUTCascade and not carry chains)
<nrossi>
tnt: getting there on timing Timing estimate: 24.00 ns (41.67 MHz) (with arachne)
<tnt>
nrossi: what did you cahnge ? :)
<nrossi>
tnt: just got the two large memories into bram was enough
<tnt>
nrossi: and did you have to use the patch for the latch I referenced above as well ?
<nrossi>
tnt: oh yes and that :)
<tnt>
daveshah: Ah damn :/ I thought there would be a LUT4 primitive with the LO output I could have instanciated to force it or something.
<tnt>
Ah well .. can I instanciate my own ICESTORM_LC ?
<daveshah>
tnt: yes, but neither arachne-pnr nor nextpnr will obey the LO rule during placement (although that would be an easy fix now nextpnr has rel constraint support) so routing will fail
Miyu has joined ##openfpga
<tnt>
nrossi: note that this timing is worst case, for like 1.1v supply at 85C ... so most likely it should meet timing just fine with a good supply and at room temperature.
<tnt>
nrossi: I was actually just noting than for a UP5k, the difference between best case and worst case was huge. Going from ~ 50 MHz to 110 MHz ...
<nrossi>
tnt: are you referring to what icetime produces or from some other source?
<tnt>
nrossi: that was icecube, I haven't seen anyway for icetime to produce anything else than 'worst case' timings.
<nrossi>
tnt: ok, going to start testing it again on hw see if it working better now ;)
<tnt>
nrossi: keep us posted !
<nrossi>
tnt: well looks like it was able to program it once i hacked out the metadata checking stuff... now to figure out why the warmboot has issues and get it to boot into the second image :)
mumptai has joined ##openfpga
<nrossi>
tnt: success got it all working, apart from the tinyfpga metadata stuff. Its getting late here (12am) so i will clean it all up tomorrow for a pull request and get the metadata stuff going :)
<tnt>
esden: no I haven't tried it, but I found it in the code.
<tnt>
esden: so far every design I tried was slower on nextpnr :(
kuldeep has joined ##openfpga
<esden>
tnt: if they are available publicly you have to report it to them, they are actively looking for performance benchmarks to improve it
<rqou>
i wouldn't, due to the team's disgusting behavior overall
<esden>
rqou: wtf are you talking about
<rqou>
embargoes and silly retaliation; feel free to grep the backlog since i don't want to explain it again
<rqou>
i stand by my recommendation not to work with m!thro, d!gshadow, or the entity symbioticeda (the individual devs may be ok)
<azonenberg_work>
esden: tl;dr rqou refuses to accept the fact that sometimes external constraints of funding, conference publication, etc sometimes force you to develop a f/oss project non-publicly for a while and then make a public release
<azonenberg_work>
rather than having every commit go live on github immediately
<esden>
rqou: thanks, but I am totally fine working with them... they do a good job and I met a big chunk of the team in person and can confirm they are good people ... so... I do not know all of them though, but I do not have any personal feelings against them. I will try to find your earlier description in the log.
<rqou>
azonenberg_work: that is not a fair summary
<esden>
azonenberg_work: ahhh! well that is obviously a personal chip on the shoulder...
<tnt>
rqou: do you have timestamp for the backlog to look for ?
<esden>
rqou: sorry you feel that way.
<tnt>
(rather than just re-do the whole thread now ...)
<esden>
tnt: good point, thank you azonenberg_work for the summary
<rqou>
azonenberg_work: you carefully omitted both the retaliation, the fact that the team basically only responds to callouts, and the fact that the team actively manipulates different members of the community
<tnt>
esden: btw, did you get a chance to look for spare boards ?
<rqou>
esden: and yes, i've met the members of the team IRL too and i would not agree with your assessment
<esden>
tnt: it was on my todo for the whole day yesterday, and I got sidetracked. It is still on my todo for today. :)
<tnt>
esden: ok np :)
<rqou>
azonenberg_work: the problem isn't just with "non-publicly for a while"
<rqou>
the problem is how the team actively manipulates the community
<tnt>
esden: just tried j1a on nextpnr, first design that's faster (although only by 6% but that's a start)
<esden>
tnt: I also observed some variance when using different initial random seeds...
TD-Linux has joined ##openfpga
<esden>
I had strange issues when setting the target frequency of 13mhz and then 12mhz and getting faster results using lower speed target than higher speed target... very strange stuff
<tnt>
yeah, I would expect small amount of randomness ... it's a PNR after all.
<esden>
actually not that strange as those annealing places are random based... ... yeah what you just said :P
<cr1901_modern>
whitequark: Charitable intepretation of that orange website post you linked: "No real world TCP/IP stack is implemented strictly according to the RFCs". I remember you linking a website discussing this. But probably giving HN too much credit.
<azonenberg_work>
cr1901_modern: I know for a fact that none of my TCP/IP stacks implement all of the weird corners in the RFCs
kuldeep has quit [Ping timeout: 245 seconds]
<azonenberg_work>
i implement the subset that is required for reasonable functionality
<azonenberg_work>
and what functionality i DO have is pretty much in accordance with the RFCs
<azonenberg_work>
But i often omit a lot of stuff that is technically required, like support for IPv4 frag
kuldeep has joined ##openfpga
<cr1901_modern>
That's prob okay for your use cases tho :)
<azonenberg_work>
IMO given the capabilities of upper level protocols
<azonenberg_work>
there is almost never a reason for an IPv4 packet to be fragmented
<azonenberg_work>
Just set DF and if it doesnt go through, reduce your tcp segment size
<cr1901_modern>
I'm still curious about frag even if no one uses it. I prob have some _personal_ (i.e. "just because I can") use cases for it
<azonenberg_work>
In general most of my projects implement the "sane" subset of specificatoins
<azonenberg_work>
And omit technically mandatory features that are rarely used or that in my opinion should never have been there in the first place
<azonenberg_work>
Like, say, 100M half duplex Ethernet
<azonenberg_work>
Or IP fragmentation
<cr1901_modern>
Is 10BASET (sic) half duplex?
<azonenberg_work>
it can be half or full
<azonenberg_work>
but i consider it deprecated entirely :P
<azonenberg_work>
i still need 100M support on my hardware because a lot of 32-bit MCUs don't have gig-e interfaces on them
<azonenberg_work>
So my switches etc have to be able to negotiate down to 100M
<azonenberg_work>
But i have nothing so old that it is 10baseT only
<azonenberg_work>
therefore i simply omit 10baseT support
emeb has joined ##openfpga
* cr1901_modern
does :)
<azonenberg_work>
Re IP fragmentation, my opinion is that exceeding the MTU is not a problem that requires a network-level solution
<azonenberg_work>
It's a transport layer problem
<azonenberg_work>
Layer 3 simply has a restriction that packets above X size cannot be handled
<azonenberg_work>
and layer 4 fragments your stream into packets as needed
<awygle>
I use ip fragmentation at work
<awygle>
In UDP
<azonenberg_work>
The only use case i know for IP frag is sending UDP datagrams in excess of the MDU
<azonenberg_work>
MTU*
<awygle>
Inb4 lol
<azonenberg_work>
Personally I just declare that the max legal UDP packet size is MTU minus headers
<azonenberg_work>
and let that be that
<cr1901_modern>
>not a problem that requires a network-level solution
<cr1901_modern>
What do you mean by "network-level solution"?
<awygle>
that has substantial performance impacts in my use case
<awygle>
due to crossing the kernel boundary much more often
<awygle>
and yes I did benchmark this
<azonenberg_work>
cr1901_modern: layer 3
<azonenberg_work>
awygle: interesting
<awygle>
it's a somewhat unique situation as the receiver is CPU starved
<cr1901_modern>
Ooooh, okay
<azonenberg_work>
I generally find that it's very rare i need to send a >1492 byte UDP datagram
<awygle>
and maximum bandwidth is critical
<awygle>
and I'm transmitting gigabytes of data most of the time
<azonenberg_work>
Since i normally use UDP for small one-way notifications or something, and anything big is TCP
<awygle>
s/bandwidth/throughput/
<cr1901_modern>
azonenberg_work: Ignore me I managed to swap Layer 3 and 4 :P
<cr1901_modern>
Thinking network-level was 4, and transport was 3 lmao
<awygle>
I do exactly the opposite of that. Control is tcp, data path udp
<awygle>
For various reasons
<azonenberg_work>
awygle: honestly beyond DNS almost everything i do is tcp
<awygle>
Semi related, I am annoyed that there's no ubiquitous layer 4 protocol which is reliable but also packet based
<azonenberg_work>
or DHCP but now that i am moving towards IPv6 as much as i can, DHCP isnt used either
<azonenberg_work>
awygle: SCTP?
<azonenberg_work>
I actually have considered using it for some of my projects
<azonenberg_work>
It's widely supported in modern OSes, but not used frequently
<azonenberg_work>
(and a lot of cheap consumer routers etc dont handle port forwarding for it or anything like that)
<awygle>
azonenberg_work: sctp isn't bad but it's not very ubiquitous
<awygle>
Also it does a lot of things I don't care about, but so do all protocols.
<azonenberg_work>
lol
<awygle>
I'd like to see something like NORM get adoption as well, but that's a more local thing
<azonenberg_work>
i considered using it for starshipraider but decided that parallel tcp streams were a better option in terms of platform support
<awygle>
Starshiprader is definitely something I'd default to UDP for
<azonenberg_work>
UDP? why
<azonenberg_work>
you need reliable delivery
<awygle>
Do you?
<azonenberg_work>
If you miss a single jtag scan transaction everything is screwed
<awygle>
I was thinking of the instrument modes
<awygle>
Jtag is control, see above
<azonenberg_work>
Oh... possible but still it can make you lose phase lock if you're bitbanging a protocol or something
<rqou>
hmm, will point-to-point links actually ever drop any packets?
<azonenberg_work>
rqou: crc errors
<azonenberg_work>
Rare but the BER of ethernet is nonzero
<rqou>
ok sure
<awygle>
sometimes but barely ever
<awygle>
also it's not a CRC lol
<azonenberg_work>
awygle: i was talking the 802.3 link layer CRC
<rqou>
"FCS errors"
<awygle>
all you need is detection imo, not correction, in most local cases
<azonenberg_work>
TCP checksum errors on a point to point link are very rare because you aren't going through intermediate routers which can have bitflips in buffers etc
<azonenberg_work>
and bad link layer packets normally get dropped by the FCS
<rqou>
so idk about routers but BRCM switches now have ECC
<azonenberg_work>
The performance of TCP over a low latency link is quite good
<cr1901_modern>
azonenberg_work: On my PPP link on RPi, I start getting errors once I speed up the UART above 1Megabaud or so :)
<azonenberg_work>
The intended deployment of starshipraider for maximum performance is a point to point 10gbase-SR fiber from it to your desktop either directly or through a switch
<awygle>
TCP_QUICKACK :-P
<azonenberg_work>
We're talking latency on the order of tens of microseconds
<rqou>
cr1901_modern: maybe it's due to errors in the baud rate?
<rqou>
try a nice even number like 1.5M or 2M?
<awygle>
cr1901_modern: that's probably dropping characters in the buffer actually
<awygle>
rather than SI stuff
<azonenberg_work>
awygle: My last tcp stack would send an ACK every time a packet came in
<cr1901_modern>
I have flow control enabled
<azonenberg_work>
and, if there was outbound data ready to send, that data would go into the ack as well
<awygle>
Hardware? Okay maybe not then
<cr1901_modern>
awygle: Software flow control*
<rqou>
i do know >1mbaud and ftdi chips stop working super reliably
<azonenberg_work>
awygle: actually now that i think about it
<cr1901_modern>
rqou: Also happens when I have a tty open on said line
<rqou>
i usually handwave and blame usb
<cr1901_modern>
rqou: This also isn't a FTDI chip
<awygle>
I don't particularly trust SW fc in uarts for various reasons
<azonenberg_work>
i always sent the ack in real time as i parsed the incoming packet, as soon as i had the incoming checksum verified
<awygle>
But in theory it should help
<azonenberg_work>
Then outbound data was sent separately
<cr1901_modern>
awygle: Well, I can never get damn h/w fc to work properly so I just took what I could get and ran w/ it
<azonenberg_work>
awygle: and i have had BER issues and/or dropped packets with FTDI MPSSE around 10 MHz
<azonenberg_work>
didn't try downclocking but i was doing JTAG
<rqou>
but that's probably because the MPSSE engine is such a piece of shit anyways
<azonenberg_work>
After moving a few gigabits of JTAG traffic i almost always had a point in which i sent a transaction and never got a reply
<azonenberg_work>
I was running *large* scale jtag during my thesis though
<azonenberg_work>
i had unit testing running on ~20 spartan6 and artix7 boards running the antikernel noc over jtag
<awygle>
Yeah that's mpsse and/or jtag being garbage
<awygle>
I suspect
<azonenberg_work>
in my continuous mode where TCK is free-running and the chip is able to send data on its own without any explicit polling
<awygle>
JTAG should have chained TCK
<awygle>
and TMS
<azonenberg_work>
this is 20 different scan chains
<azonenberg_work>
with one chip each
<azonenberg_work>
and 20 FT232H's hanging off multiple usb root ports
<azonenberg_work>
Moving an aggregate 200 Mbps of TDI and 200 Mbps of TDO
<azonenberg_work>
That adds up to GB of jtag data pretty quickly so even a BER in the e-9 range is going to lead to errors eventually
<rqou>
meanwhile i've transferred at least a tb over a 10g fiber link with china optics and got 0 BER?
<rqou>
ethernet BER is pretty impressive
<rqou>
meanwhile HDMI BER is afaik the laughingstock of "just a serdes" protocols
<azonenberg_work>
rqou: yeah usb ber is awful
<azonenberg_work>
But i have had very good luck with ethernet ber as well
<azonenberg_work>
Especially over short point to point links
<gruetzkopf>
i mean even over the congress network, with me running SR optics over like 200m of singlemode fiber i had zero packets dropped during the whole stay
<rqou>
10g?
<gruetzkopf>
yes
<rqou>
200m isn't exactly a long singlemode link though is it? :P
<azonenberg_work>
rqou: he said SR optics meaning designed for multimode fiber
<gruetzkopf>
^
<rqou>
er wait a sec
<azonenberg_work>
Also did i mention we should just burn down usb and replace it with ethernet? :p
<gruetzkopf>
quite often, yeah
<rqou>
were you running a multimode optic with singlemode fiber?
<azonenberg_work>
gruetzkopf: we need to make PoE more ubiquitous
<rqou>
meh, PoE isn't particularly good
<azonenberg_work>
rqou: it cant be worse than USB PD
<gruetzkopf>
yes, i was
<azonenberg_work>
On that note, i want to make a laptop that has a switchable master/slave PoE port on it
<rqou>
wtf gruetzkopf
<azonenberg_work>
I want to be able to charge a laptop by plugging it into the LAN
<azonenberg_work>
And i want to be able to plug IP phones, cameras, etc into my laptop and power them
<rqou>
azonenberg_work: what if i plug an etherkiller into it? :P
<gruetzkopf>
i want a laptop that uses both tengig-interfaces a ryzen embedded v1xxx has.
<azonenberg_work>
gruetzkopf: I also want a laptop with SFP+ interface
<azonenberg_work>
:p
<azonenberg_work>
rqou: BOOM
<rqou>
no SFP28? :P :P
<gruetzkopf>
yeah, 2*SFP+ and 2*copper/POe would be nice
<azonenberg_work>
gruetzkopf: Exactly
<rqou>
gruetzkopf: can we get 25G ethernet at congress? :P
<azonenberg_work>
The copper dont need to be 10G
<azonenberg_work>
10GbaseT is dead to me
<gruetzkopf>
10GbaseT is stupid
<azonenberg_work>
Yeah i don't see myself ever deploying it
<rqou>
40GbaseT :P
<azonenberg_work>
Which is why as i prepare to deploy the new cable plant at my lab under construction
<gruetzkopf>
fiber is *so cheap*
<azonenberg_work>
I'm using OM4 and CAT5e
<azonenberg_work>
Because 5e runs 1000baseT reliably
<azonenberg_work>
its cheap and i have half a mile of it sitting around
<azonenberg_work>
And anything beyond gig is optical
<gruetzkopf>
so i can break it out to 4*10GE
<azonenberg_work>
gruetzkopf: I will have two 40Gbase-SR4 and two 10Gbase-SR links, plus $MANY 1000baseT links, from my desk to the data rack in the lab area
<rqou>
azonenberg_work: what about future 2.5G/5G? :P
<gruetzkopf>
the broadcom missile-chip-switches support that kind of lane splitting
<azonenberg_work>
gruetzkopf: my intel 710 40g nic can do that but only for one interface
<rqou>
oh yeah, it's pretty cool
<azonenberg_work>
not enough queues or something?
<azonenberg_work>
the supported options are...
<rqou>
there's a finite number of MACs though
<azonenberg_work>
2x 40G interface
<azonenberg_work>
4x 10 on one port, other port not used
jn__ has quit [Ping timeout: 276 seconds]
<azonenberg_work>
2x 10 on one port, 2x on the other
<azonenberg_work>
remaining lanes not used
<azonenberg_work>
So i guess four macs total
<gruetzkopf>
maybe
<azonenberg_work>
rqou: re 802.3bq, yes you *can* run ethernet over twisted pair
<azonenberg_work>
at crazy speeds
<azonenberg_work>
You can run gigabit over barbed wire too
<azonenberg_work>
Doesn't make it a good idea
<rqou>
ok the missile-chips have more macs than that i think
<azonenberg_work>
Not when cat5 is available
<gruetzkopf>
yeah they have one per lane usually
<azonenberg_work>
rqou: this is for a 2-port NIC though
<azonenberg_work>
In any case, my own DIY switch will have one mac per serdes
<gruetzkopf>
the old sun nics i have are 2-port 4-mac, they support 4-port models on the same chip
<azonenberg_work>
So it will be able to do 4x 10G on every 40G interface
jn__ has joined ##openfpga
<azonenberg_work>
LATENTORANGE's actual port configuration is not yet decided though
<gruetzkopf>
they're already single-lane 10g though
<azonenberg_work>
other than " a buttload of 10G/40G interfaces"
<azonenberg_work>
LATENTRED meanwhile is 24x 1000baseT / 4x 10Gbase-R for sure
<gruetzkopf>
are you building each of the lanes from XAUI?
<rqou>
my favorite BRCM switch configuration was a 2 port switch: 100G ethernet on one port and iirc 128G HiGig on the other :P
<azonenberg_work>
LATENTORANGE is TBD but will be a kintex/virtex with 10G+ serdes natively
<azonenberg_work>
LATENTRED is an xc7k160t which has four 10G serdes
<azonenberg_work>
Then i'll be using LVDS GPIOs in SGMII mode to talk to the 24 copper PHYs
<azonenberg_work>
this is the line card, ready to send to fab although i may move the position of the Q-strip (for connecting to the backplane) based on mechanical constraints once the brain card is done
<azonenberg_work>
The backplane, brain, and CPU module are still WIPs
<azonenberg_work>
Line cards are dumb, just a PoL power supply and eight PHYs
<azonenberg_work>
plus some i2c sensors for system health monitoring
<gruetzkopf>
8-port. interesting jacks
<azonenberg_work>
Yes
<azonenberg_work>
Mechanical constraints, i needed to fit 24 copper interfaces plus four SFP+s and a console port in a 19" wide chassis
<azonenberg_work>
You can fit 24 ports in a 19" case but theres not room for anything else
<azonenberg_work>
plus routing wise i needed a bit of space between the rj45
<gruetzkopf>
yeah, you need to stack
<azonenberg_work>
So a dual row option was pretty much mandatory
<azonenberg_work>
Which meant i had to clamshell the PHYs :p
<azonenberg_work>
THAT was fun to lay out
<gruetzkopf>
i'm used to them connecting in 2 rows, not next to each other
<azonenberg_work>
And will be interesting thermally
<azonenberg_work>
Yeah thats an odd layout but hey
<gruetzkopf>
with stacked ports you can fit 52 ports comfortably
<azonenberg_work>
So with a 4 layer pcb and the PHYs i am using
<azonenberg_work>
you need some space between groups of ports
<azonenberg_work>
the PHY pitch is larger than the port pitch
<azonenberg_work>
Then i need to fit four boards side by side
<azonenberg_work>
Three base-T PHY boards
<azonenberg_work>
and the fourth will be the "brain" that has the switch fabric FPGA, a SoM with a small IO expander FPGA and an ARM core to run the management CLI
<gruetzkopf>
and a "dumb" baseboard?
<azonenberg_work>
The brain will have four front panel SFP+ interfaces plus a dedicated RJ45 for the management interface (the sshd listens on a dedicated hardware interface with no bridging to the switch fabric)
<gruetzkopf>
for interconnect?
<azonenberg_work>
Then probably a dedicated RJ45 using the Cisco RS232 pinout, or a mini/micro USB interface to an FTDI, for initial IP config of management
<azonenberg_work>
The backplane will actually be more of a "top plane"
<azonenberg_work>
like an SLI bridge
<azonenberg_work>
between the line cards and brain
<azonenberg_work>
parallel to and slightly above them
<azonenberg_work>
It will be dumb, but probably not entirely passive
<azonenberg_work>
Initial SI analysis suggests i may need buffers or redrivers for the more distant line cards
<gruetzkopf>
this looks like the ideal hardware to implement stupid ideas on
<azonenberg_work>
Lol
<azonenberg_work>
oh and the brain FPGA will have a QDR-II+ hanging off it for buffers, routing tables, etc
<azonenberg_work>
That will be an xc7k160t in FBG484
<azonenberg_work>
The management engine will live on an INTEGRALSTICK SoM, which is a partially designed credit-card sized SBC that mates to the host via two Q-strips
<gruetzkopf>
"fun" pricing :|
<azonenberg_work>
has the biggest stm32 (216 MHz Cortex-M7, half a meg of SRAM, 2 MB of flash) plus an Artix-7 in FTG256
ayjay_t has quit [Read error: Connection reset by peer]
<azonenberg_work>
Dedicated gig-e interface from the FPGA to the front panel bypassing the switch fabric
<azonenberg_work>
100Mbps MII from the FPGA to the STM32
<azonenberg_work>
The idea is that you can push 100M of the gigabit management traffic to the stm32 for SSH but still have extra bandwidth if you wanted to do something funky on the artix
<azonenberg_work>
Then there will be a bunch of LVDS lanes from the artix to the main kintex
<azonenberg_work>
The artix will also be in charge of a bunch of things like polling the i2c sensors on the PHYs, optional JTAG on the PHYs for board self test, power rail sequencing on the line cards (did i mention they're totally dumb and brainless?)
<azonenberg_work>
in order to save GPIOs on the kintex for high speed stuff like SGMII and QDR-II+
<azonenberg_work>
I could have gone with a bigger kintex but that would mean more PCB layers on the brain
<rqou>
going to run linux on the stm32? :P
<azonenberg_work>
This architecture should let me keep it to 6L on both the CPU card and the brain
<azonenberg_work>
initial plan is bare metal interrupt driven architecture that just runs a sshd and CLI
<rqou>
which sshd?
<azonenberg_work>
Probably full custom and half in hardware on the fpga
<rqou>
lol good luck
<azonenberg_work>
it will support public key authentication only, password wont even be supported
<rqou>
djb ciphers only?
<azonenberg_work>
aes128-gcm and x25519 as the sole cipher suite
<azonenberg_work>
tentatively
<rqou>
not going to completely drink the djb coolaid yet?
<azonenberg_work>
No
<azonenberg_work>
tentative plan is to do tcp/ip and aes on the fpga
<azonenberg_work>
then push cleartext ssh transport layer frames to the stm32
<azonenberg_work>
the only crypto on the stm32 will be unmodified libsodium for the key exchange
<azonenberg_work>
i dont want to implement x25519 on fpga right now :p
<rqou>
afaik it's not actually that bad
<azonenberg_work>
gruetzkopf: anyway, yeah this will be a FUN platform to play with
<sorear>
chacha is bad for hardware anyway
<azonenberg_work>
Initial firmware will be minimal, dumb layer 2 switching but there is potential to add lots of fun layer 3-4 features down the road
<rqou>
i have a (not foss yet, sorry) reimplementation of nist p256
<rqou>
it was... manageable
<gruetzkopf>
i have some stupid ideas for a platform like that
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
<gruetzkopf>
involving ethertype 0x22E4 "pcie tlp over ethernet"
<rqou>
oh wtf
<rqou>
of course you then run this on the same infrastructure as appletalk over ethernet right? :P
<azonenberg_work>
y u no decnet?
<gruetzkopf>
because the VAXen i'm planning for that part are still in active service
<azonenberg_work>
gruetzkopf: ...
* azonenberg_work
finally gave away his last VAX parts
<azonenberg_work>
somebody from some irc channel was in the area and offered to give them to a good home, i forget exactly how i got connected to them
<azonenberg_work>
i think the living computer museum was involved somehow but they weren't the final recipient of the boards?
<gruetzkopf>
these are still mission-critical, a replacement is being deployed but not yet certified by the relevant authorities
<rqou>
wait what
<rqou>
seriously?
<rqou>
goddammit is this on a train?
<gruetzkopf>
nope
<jn__>
i suspect it's the backend for the search at bahn.de
<rqou>
lol
<gruetzkopf>
nope :Ü
<gruetzkopf>
:P
<fseidel>
rqou: you mentioned not using the Quartus programmer. What do you use?
<rqou>
fseidel: TBD :P :P
<rqou>
bringup not done yet
<fseidel>
ah, okay :-P
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
<rqou>
fseidel: honestly it'll probably be openocd with some duct tape
<rqou>
since azonenberg_work's jtaghal seems to perpetually be a not-quite-usable mess
<rqou>
strongly considering writing yet another jtag abstraction that does everything that azonenberg_work doesn't want to have
GenTooMan has joined ##openfpga
<awygle>
rqou: tag me into design meetings if you do
<rqou>
i think step 0 is for me to actually go and code some rust "AutoFFI" glue
<rqou>
which unfortunately is quite hard
<awygle>
what kind of ffi
<rqou>
i want something that you can annotate a non-#[repr(C)] struct and automatically generate a full set of getters and setters
<rqou>
the next step will then be to generate more glue in a scripting language like python that automagically creates objects that invoke these getters and setters via python's FFI
<awygle>
hm, that seems somewhat useful I suppose
<rqou>
i looked into it a while back and it seems like you need some pretty gross hacks to do it
<rqou>
but it should be possible
<azonenberg_work>
rqou: whats "not quite usable" about jtaghal?
<awygle>
think I'd have to see it in action to see the value
<rqou>
constantly being refactored for one :P
<azonenberg_work>
There are certainly features not present, like SWD
<awygle>
oh christ can we not have this argument again? lol
<rqou>
being very FFI-hostile for another
<rqou>
but yeah, this again
<azonenberg_work>
rqou: and lol i wouln't say constant
<azonenberg_work>
This is literally the first major refactoring of the core in years
<azonenberg_work>
adding support for multiple transport layers
<rqou>
azonenberg_work: you should add "no more FFI fights" to the topic :P
<azonenberg_work>
rqou: lol
<azonenberg_work>
let me rephrase... Do you have any issues with the end user facing featureset of jtaghal, for either a C++ developer or somebody using the CLI only?
<rqou>
yes, the constant fight about "which virtual functions are legal hook points"
<rqou>
and the fact that coolrunner-ii support is still unfinished and it seems extremely tedious to actually finish
<rqou>
azonenberg_work: maybe you should also add "no more fights about virtual function-centered API vs data structure-centered API"
<awygle>
I prefer the rust rfc "no new arguments" policy lol
<awygle>
"have I already had this fight with these people? yes? I shouldn't have it again then"
feuerrot has quit [Ping timeout: 264 seconds]
feuerrot has joined ##openfpga
<gruetzkopf>
hm, do i really have to paste 2 ECP5 onto a board to get 10GE *and* something else :(
sunxi_fan has joined ##openfpga
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
zino has quit [Quit: Leaving]
zino has joined ##openfpga
<awygle>
gruetzkopf: you could use a 5g and RXAUI if you have an RXAUI driver
<awygle>
phy whatever
<awygle>
actually that might not even quite work out
<rqou>
yeah we're kinda lacking some good intermediate speeds between 1g and 10g
<rqou>
also between 10g and 28g but then you're already in $$$ territory
mumptai has quit [Quit: Verlassend]
<awygle>
FC? IB?
<rqou>
let's be honest, nobody uses those :P
* awygle
knows little of such things except they exist
<rqou>
i just troll whitequark by asking about IPoIB
<zino>
FC is shit! ... sorry, sorry, storage manager PTSD
<zino>
IPoIB is nice, I run that for most of my traffic at home. :)
<awygle>
Standardize 5GBASE-X
<rqou>
wait, somebody uses IPoIB?
<awygle>
Nationalize anime
<rqou>
other than "the other bridge logo company"? (the israeli one, not the silicon valley one)
<zino>
rqou, sure. I have ~2k nodes running that at work and ~20 at home.
<rqou>
although apparently they also have headquarters in sunnyvale lol
<gruetzkopf>
i'm missing a FC switch (1/2/4G)
<awygle>
What's FC good for? I understand IB much better
<awygle>
Seems storagey?
<gruetzkopf>
storage
<zino>
FC is good for absolutely nothing.
<gruetzkopf>
you mostly use it to tunnel scsi
<awygle>
What makes it "good" for storage?
<gruetzkopf>
it was faster than 1G before 10GE was common
<rqou>
zino: what about FCoE?
<gruetzkopf>
except when you're ibm, then you use it for mainframe stuff
<zino>
rqou, never been close to that thankfully
<rqou>
gruetzkopf: i thought sata also tunneled scsi? :P
<awygle>
is IPoFC a thing?
<gruetzkopf>
technically yes, never seen an implementation
<zino>
awygle, I hope not
<rqou>
there's also a tunneling for scsi over ethernet iirc
<awygle>
everything tunnels scsi. UFS is SCSI-over-M-PHY
<rqou>
tunnel everything over everything :P
<rqou>
hence "converged networks"
<awygle>
SCSI is like uhhh
<gruetzkopf>
the scsi command set is surprisingly un-terrible for its age
<awygle>
That thing instruments speak
<gruetzkopf>
no, that's GPIB
<awygle>
SCPI?
<awygle>
The ascii protocol
<gruetzkopf>
ah, one layer up SCPI, yeah
<gruetzkopf>
SCSI is what disks speak
<awygle>
Yeah, scsi is at that layer imo
<gruetzkopf>
and tapes
<rqou>
cdroms?
<awygle>
So "tunnel scsi" is an odd phrase
<awygle>
To me
<gruetzkopf>
there's the scsi command set
<gruetzkopf>
which runs over all kinds of different buses, like SCSI, SAS, SATA and ATA (in the ATAPI case), FC, IP...
<rqou>
wait PATA isn't SCSI?
<gruetzkopf>
USB (UAS mass storage)
<zino>
rqou, No.
<awygle>
Right. Does SCSI the bus really exist anymore or is it vestigial?
<gruetzkopf>
the parallel scsi bus is dead
<rqou>
so how do those PATA<->SATA bridges work?
<rqou>
very hard/hackily?
<gruetzkopf>
SAS is alive
<gruetzkopf>
both sata and pata use the ata command set
<zino>
rqou, with a buggy translation chip
<rqou>
wait, sata isn't scsi?
<gruetzkopf>
and for CD support they taped SCSI-over-ata on top
<rqou>
wtf
<gruetzkopf>
SAS is native scsi
<awygle>
yup, this all matches my understanding
<rqou>
gruetzkopf: what about iomega zip trololo?
<gruetzkopf>
ATAPI
<rqou>
(afaik it's scsi over printer port)
<gruetzkopf>
also scsi, or scsi-over-printer-port
<awygle>
SCSI isn't too bad as a command set, as stated
<gruetzkopf>
(well, there's non-atapi ide zip drives, and they're *extremely* annoying)
<rqou>
so are sata optical drives scsi-over-ata-now-sata?
<gruetzkopf>
yes
<rqou>
lolol
<rqou>
but somehow sata can be mixed with sas?
<gruetzkopf>
SAS controllers and switches can de-encapsulate ATA commands tunneled over SCSI
<gruetzkopf>
which is *fun* when you connect a SATA optical drive ;)
<rqou>
so...um...how do the involved asic teams perform validation?
<zino>
hahaha
<rqou>
i guess maybe they don't which is why half of this doesn't work half the time
<gruetzkopf>
yep
<rqou>
gruetzkopf: now let's throw a CF card into the mix :P
<rqou>
a lot of CF cards also seem pretty buggy in true PATA mode
<gruetzkopf>
and then at least LSI made FCAL->SATA bridges which accept scsi commands, then issue ATA commands to the disk and back
<gruetzkopf>
i've never had those work outside a LSI enclosure
<rqou>
and then marcan comes in and reflashes the controller :P
<rqou>
gruetzkopf: so if i were to hypothetically plug a sata-interface optical drive into a usb dock, how many layers of encapsulation do i get?
<gruetzkopf>
raid controller crossflashing is something one has to do too often
<gruetzkopf>
i have some ibm servers with a adaptec SAS raid controller on them
<rqou>
would this be scsi (cdrom) over ata (sata) over scsi (usb)?
<gruetzkopf>
the adaptec version supports disk passthough, the ibm version does not :/
<gruetzkopf>
that's a interesting case
<rqou>
wait no
<gruetzkopf>
if the bridge is old, you wouldn't be running SCSI over usb, but rather the usb-mass-storage protocol
<rqou>
are those usb hdd docks UAS or bulk-only with a smart controller?
<gruetzkopf>
it depends
<gruetzkopf>
some UAS "capable" controller also have terrifying bugs
<rqou>
wtf
<rqou>
why does this have bugs?
<rqou>
you read/write some data to a sector
<gruetzkopf>
good old 2TiB barrier
<rqou>
goddammit
<rqou>
oh yeah, i hit that the other day
<awygle>
Hahaha yeah I hit that every other week
<rqou>
i tried to use a 4tb hdd for my sony ps2
<rqou>
most homebrew was... unhappy
<awygle>
Or 2 GiB or similar
<zino>
PS2 takes a maximum of 120G if I remember correctly
<rqou>
afaik that's a different part of the system software
<gruetzkopf>
128G
<gruetzkopf>
the LBA32 barrier
<zino>
right
<rqou>
i believe homebrew can actually use lba48
<rqou>
but somehow they managed to make new bugs at 2tb
<zino>
Does it switch to PIO mode?
<awygle>
Given my employer, every intersection of 32-bit int and page size gets hit eventually
<rqou>
i have no idea
<rqou>
the ps2 homebrew scene is a clusterfuck
<gruetzkopf>
rqou: usb disk or native bus
<rqou>
ps2 linux is an even bigger clusterfuck
<rqou>
gruetzkopf: 4tb laptop sata drive<->sata-to-pata bridge<->official network adapter
<zino>
rqou, well, it's not a bigger clusterfuck than PS3 Linux that got removed. :-/
<rqou>
heh ok
<gruetzkopf>
ah, fat ps2
<gruetzkopf>
does your PS2 still have FW?
<rqou>
5-series, not sure exactly which one
<rqou>
also, you really forget how far technology has come and how slow 100mbps ethernet is nowadays :P
<gruetzkopf>
yeah
<gruetzkopf>
here at home, 1GE feels slow
<zino>
True. But 100mbit on PS2 is nicer than 100mbit on the Dreamcast. The DC BBA tends to lock up if you drive it in 100mbit for any lenght of time.
<rqou>
heh i recently finally went and bought a bba
<rqou>
but i haven't gotten around to trying it yet
<gruetzkopf>
still need to clone that one
<rqou>
i unfortunately misplaced my vga box
<zino>
$100+?
<rqou>
yeah, for the bba
<gruetzkopf>
it's only a pci<->somewhat pci adapter and a$3 RTL8139C PCI card
<zino>
They seldom come up on eBay any more.
<rqou>
i see some for $130
<gruetzkopf>
the G2 bus works pretty much exactly like 64bit-address-on-32bit-pci phases
<gruetzkopf>
with a 16bit AD bus
<zino>
Hmm. My alerts must have stopped working
<rqou>
iirc g2 cannot support device-initiated dma?
<rqou>
iirc there's a bounce buffer in the bridge
<gruetzkopf>
there is a bounce buffer, yeah
<zino>
I used to have two BBAs, but I leant one to a friend and it got lost.
<gruetzkopf>
ouch
<q3k>
esden | I had strange issues when setting the target frequency of 13mhz and then 12mhz and getting faster results using lower speed target [...]
<q3k>
esden: was that measuring with icetime or just with the nextpnr timing info output
<zino>
rqou, yea, it's part of preventing exploits via G2 as far as I could tell.
<rqou>
wait seriously?
<rqou>
were they actually thinking about this type of attack back then?
<rqou>
and yet they left in mil-cd :P
<zino>
Not confirmed, but we looked at that as a possible way to start homebrew before Marcus REd mil-cd.
<rqou>
wait a sec
<rqou>
were you part of the "scene" back in the day?
<rqou>
you should help me un-bitrot dreamcast linux :P
<zino>
Not quite. I talked a bit to the scene guys, but I worked with Marcus C to document and boot homebrew, not copied games.
<gruetzkopf>
currently, my superh-box of choice to mess with is a casio graphing calculator
<rqou>
it's kinda weird searching dreamcast stuff on the internet because it's just barely new enough that some searches return modern discussions and some return forum posts from 2001
<rqou>
zino: do you know how the dreamcast linux boot process works between mil-cd and actually loading a kernel?
<zino>
Which led to some talkes with a Sega US rep who wanted us to make NetBSD a viable platform for DC development. That never went anywhere.
<rqou>
i found a livecd of linux from the early 2000s that still works
<rqou>
but no instructions on how to build/boot a modern 4.x system
<gruetzkopf>
i feel bad for not getting all the fun DC stuff back when it was sub-30€
<zino>
rqou, I used to know. Now I would have to spend days reading notes to get that knowledge back.
<rqou>
whelp, no wonder everything is bitrotted :P :P
<rqou>
step 0) find where my vga box went :P
<rqou>
ps2 linux could also use a complete bootstrap from scratch
<rqou>
rather than the old 2.4 monavista linux
<gruetzkopf>
n64 linux could use a strap at all
<rqou>
lolol
<gruetzkopf>
what, 8MiB has to be enough for everyone :P
<rqou>
problem is that n64 kinda just missed the cutoff to have "modern" periperals
<gruetzkopf>
there's a mouse
<rqou>
and modern IO interfaces
<gruetzkopf>
and the GC keyboard would work
<rqou>
yeah but ps2/dc have ethernet
<rqou>
and ps2 has _usb_
<gruetzkopf>
with a mechanical adapter
<gruetzkopf>
cube has too
<rqou>
no usb
<zino>
Maybe try NetBSD first, it might be easier. And try this if you don't want to burn an infinate series of CDs: https://github.com/zeldin/dc-virtcd
<rqou>
also cube linux works just fine
<rqou>
you just have to run it on a wii :P
<rqou>
wii has _wifi_
<gruetzkopf>
not totally fine on cube
<gruetzkopf>
but jn__ knows more
<gruetzkopf>
proper tri-core wiiu linux needs a lot of work
<rqou>
wiiu is a trashfire i currently don't want to touch
<gruetzkopf>
the scene? into the trash it goes, yeah
<zino>
Of course, virtcd doesn't work with NetBSD and might not work with Linux either. It robably bypasses BIOS.
<rqou>
also, iirc the cores aren't identical?
<gruetzkopf>
one has more cache
<gruetzkopf>
but that's not a problem
<esden>
q3k: it was with both, I am also getting different results than clifford, which is super strange. I was synthesiszing picosoc and it could not meet the 12mhz timing constraint unless I set the timing for nextpnr to 12mhz instead of 13mhz... very obscure
<rqou>
zino: for testing i'm probably going to just run 9p anyways before figuring out how to pack things into a live disc
<rqou>
gruetzkopf: although tbh the ps2 scene is a dumpster fire too
<gruetzkopf>
9p2000, rescuer of many bad ideas
<rqou>
but fortunately in 2018 the fire has basically been extinguished :P
<q3k>
esden: would you mind filing a bug for this?
<esden>
sidenote: (argh I have to add git stamp and version outputs to the picosoc makefiles, not having them in the logs makes it hard for you to get the same setup as I had)
<esden>
q3k: sure I can do that... I was reluctant about it because clifford was assuring me that it works perfectly fine on his machine, so I keep questioning my setup :)
<q3k>
that's something that we'll fight out in the bug :P
<q3k>
but yeah, would be nice if you could point to particular commits of yosys & nextpnr
<esden>
hehe fair enough ;)
<esden>
ok, I will try to dig it all up
<esden>
I do think that by default all the tools should output one line at the beginning of the output identifying the exact version used. This way someone just pasting the log will automatically report the version.
<rqou>
actually gruetzkopf you're good at osint right?
<rqou>
did anybody actually document DNAS?
<rqou>
or did "scene" people do their usual bullshit and not write it down?
<gruetzkopf>
never was a sony person, sorry
<shapr>
anyone uses clash-lang here? I'm trying to write a basic blinky with the beaglewire
<gruetzkopf>
my current "needs a lot of work" bullshit project is in the rootfs-via-9p2000-phase too
<rqou>
lol which project is this?
<gruetzkopf>
so you know the tegra X1 has this cortex A9 for "audio"
<rqou>
also i love how landley basically cleaned up and documented 9p2000.L
<gruetzkopf>
which has access to like 1.5GiB of DRAM
<rqou>
oh goddammit gruetzkopf
<rqou>
what is wrong with you
<gruetzkopf>
that's a good question, i cannot give you a finite answer
<rqou>
hmm i also should spend some time making linux-tsx :P
<rqou>
this should actually be reasonably straightforward
<gruetzkopf>
(for extra points, run nommu linux on the ARM7 BPMP)
<rqou>
plz no
<rqou>
hmm btw do we have switch piracy yet? :P
<gruetzkopf>
yes, even commercially, but it's absolutely useless because nintendo got their shit together
<rqou>
aw :(
<gruetzkopf>
play a pirated game and you're banned.
<rqou>
is it still a "up yours, ktemkin" situation?
<gruetzkopf>
they have backported most of that to 3ds, too
<rqou>
oh wow
<rqou>
do we know how?
<gruetzkopf>
doesn't work that well on 3ds because there gamecards share certs in one fab run
<gruetzkopf>
switch cards are individualised
<rqou>
gruetzkopf: do we have code exec on the security asic yet?
<gruetzkopf>
huh?
<gruetzkopf>
card asic?
<gruetzkopf>
not seen anything
<rqou>
iirc there was an extra asic with firmware for talking to cartridges
<rqou>
nobody seems to care about it because "zomg piracy"
<gruetzkopf>
i don't even know offhand how it's connected to the X1
<rqou>
yeah me neither lol
<gruetzkopf>
so, which fpga vendor would i have to go to hit "at least 5, preferably 8 serdes capable of 5G" and "FOSS tooling this decade"?
<rqou>
lol
<gruetzkopf>
i don't even want more than 10 other IOs :P
<whitequark>
gruetzkopf: ecp5?
<rqou>
join awygle in annoying me about cyc10gx?
<rqou>
that only has 4?
<gruetzkopf>
^
<gruetzkopf>
rqou: work faster :P
<rqou>
iirc kintex7 also only has 4
<whitequark>
oh
<rqou>
gruetzkopf: i'd probably work faster if i didn't have to keep countering the lies and spin of d!gshadow/m!thro/symbioticeda
<gruetzkopf>
4 @ 3.125G and 4@2.5G would be fine for now
<gruetzkopf>
(join me today in my quest to replace everything with ethernet. even pcie.
<rqou>
actually kintex7 has 8 serdes
<rqou>
so that would work
<rqou>
gruetzkopf: want to hardfork xray and do it?
<gruetzkopf>
i think that'd make the project stack hit the heap
<rqou>
lol probably
<gruetzkopf>
and that's a overbudget for a joke project ;P
<rqou>
sounds like you'll be duct-taping two ECP5s together then
<awygle>
yeah do the cyc10gx thing
<awygle>
dance puppets dance :-P
<rqou>
> i'd probably work faster if i didn't have to keep countering the lies and spin of d!gshadow/m!thro/symbioticeda
<gruetzkopf>
well i could use one
<gruetzkopf>
and a external XGMII phy
<gruetzkopf>
but those are ridiculous
<rqou>
also i'd need to get an "improved" version of quartus first
<awygle>
I can't even find XGMII phys that aren't NDAd
<gruetzkopf>
:(
<awygle>
rqou: quartus pro is free for the 10gx in case I haven't mentioned
<awygle>
just download and go
<rqou>
it is?
<awygle>
yup
<gruetzkopf>
you see
<rqou>
i thought you needed to buy the paid thing? the free edition only has 10lp?
<rqou>
or am i confused?
<awygle>
You still download pro but it comes with cyc10gx enabled
<awygle>
Then you pay to enable arria and stratix
<rqou>
and it's not a trial?
<awygle>
Source: me, I did this
<awygle>
Nope
<rqou>
lolwtf
<rqou>
thanks intera
<rqou>
very obvious
<gruetzkopf>
i promise a free ethertype 0x22E4 implementation