<azonenberg>
whitequark: the *via* placement looks good however the *cap* placement, while decent, could be improved
<azonenberg>
if you have big enough caps / small enouhg vias that you can fit *both* between the cap pads, that's great
<azonenberg>
in this case, you can only fit one so going in between with one via doesn't shrink your loop much
<azonenberg>
i think you're slightly better off putting the cap on the side of the vias
<azonenberg>
i usually place the cap so that the pads are tangent to or very slightly overlapping the annular ring
<azonenberg>
Such that you still have soldermask over the via preventing solder from wicking down into the drill
<azonenberg>
from the pad
<azonenberg>
But the trace length is essentially zero
<awygle>
good morning world
<whitequark>
azonenberg: oh you mean e.g. moving C10 a bit to the right?
<azonenberg>
Right and up or down
<azonenberg>
s.t. the via is tangent to the north or south edge of the pad
<azonenberg>
you'll still need a tiny piece of trace for kicad to understand that it's connected, but the length should be basically zero
<whitequark>
I see. I think I can do that, yes
<azonenberg>
whitequark: it provides very slightly less loop area than the alternatives, at the speeds you're working with it *probably* doesnt matter
<azonenberg>
but unless you have a good reason NOT to, why use a less good layout?
<azonenberg>
i always use low-inductance mounting techniques unless forced to for some reason
<azonenberg>
if i have space i'll even put a second set of vias on the south side
<azonenberg>
for bigger say 1206 caps i even do four, one on each side of each pad
<whitequark>
welll I'm worried about this close via placement somewhat
<whitequark>
it's a cheap board house
<azonenberg>
as long as you have the full annular ring
<azonenberg>
even if there's a tiny bit of breakout you shouldnt have much solder wicking down
<awygle>
i don't expect it to be a problem as long as a) the interior vias are to ground and b) both interior and exterior vias meet trace/space relative to the smaller pads
<azonenberg>
You're tenting vias iassume?
<awygle>
interior non-ground vias i would be slightly more cautious but would still probably be OK, definitely tent though.
<awygle>
whitequark: i assume you're planning to assemble yourself? with hot air, presumably?
<whitequark>
awygle: hotplate I think
<awygle>
ah ok, same difference
<whitequark>
azonenberg: yes tented vias
<awygle>
95% of these "ooo that's pretty close maybe it will suck up solder" problems are completely irrelevant for low-volume hand assembly, i wouldn't worry much. it's more about manufacturing yield.
<azonenberg>
awygle: exactly
<azonenberg>
and you can always add more solder with an iron if there is a voiding problem (very unlikely)
<azonenberg>
ESPECIALLY with a one-off i'd put priority on good AC performance of the cap
<azonenberg>
Since thats not something you can easily rework
<marcan>
what kind of frequencies are we talking about here?
<marcan>
but I've gotten away with murder on things like this
<whitequark>
this chip has an fcore=48MHz
<azonenberg>
It's likely overkill for that
<marcan>
oh you're fine
<marcan>
you're more than fine
<awygle>
yup
<marcan>
I started my designs before knowing what decoupling was
<azonenberg>
But again i prefer to err on the side of too-good power distribution
<marcan>
I had entire micro designs at 8MHz with *no* decoupling *anywhere*
<azonenberg>
unless i actually have a reason
<marcan>
and, like, motors and shit
<azonenberg>
marcan: meanwhile, i learned quickly from the school of hard knocks
<azonenberg>
I had designs with PICs on breadboards not work
<azonenberg>
Because of no decoupling
<whitequark>
marcan: well, the developer boards i have with this chip have one decoupling cap
<awygle>
your decoupling loop can be, at a rough estimate, 2.5 centimeters long at 48 MHz
<whitequark>
and its not even close
<marcan>
the first design where I realized maybe I needed decoupling was a PIC on a board that also had a big relay and a 12V halogen lamp
<marcan>
toggling that made it reset
<azonenberg>
breadboards have massive parasitic L and C and apparently the L dominated :p
<whitequark>
awygle: oh that explains why the devboards work
<awygle>
(derived by 1/100th wavelength rule in FR4)
<azonenberg>
awygle: yeah i dont have a good gut feel for what i can get away with at low speeds :p i'm used to targeting parts with GHz range PLL VCOs on them etc
<azonenberg>
So i decouple everything well and if i spend an extra $0.10 on caps for a $250 board with a $100 FPGA on it... big deal
<awygle>
marcan: that sounds more like insufficient cap than an inductance problem
<marcan>
I've had more interesting things break badly on breadboards later, heh
<azonenberg>
awygle: yeah agreed
<marcan>
but I don't recall issues with PICs most of the time
<marcan>
unless I was doing some analog stuff
<azonenberg>
marcan: this was a dspic with a PLL on it
<marcan>
oh
<azonenberg>
i think the pll was glitching
<marcan>
yeah okay
<marcan>
I only used dsPIC once
<awygle>
i had a coworker convinced we had decoupling problems on our MSP430 design
<azonenberg>
marcan: its such an obscure arch IDA doesnt have a cpu plugin for it
<azonenberg>
lol
<marcan>
sadly that design never made it to orbit due to... shitty management
<marcan>
(it was a cubesat)
<marcan>
(we even had the funding)
<awygle>
turned out to be a bad filter on our ADC input - it was a sample-and-hold ADC and we didn't have enough charge on the node to fill the cap
<marcan>
azonenberg: ha
<awygle>
marcan: *nod* that life
<balrog>
we're dealing with PICs again?
<azonenberg>
awygle: and yes, capacitance matters in addition to inductance for decoupling
<marcan>
I remember the ugly GCC port
<marcan>
and the almost certainly GPL-violating optimizer pass blob
<azonenberg>
you need enough C to keep your voltage from browning out
<awygle>
i don't have a good "enough C" rule of thumb
<azonenberg>
before the PSU can respond
<whitequark>
awygle: so you're saying that putting a cap on each pin of this CY7C68013A is overkill? :p
<awygle>
i suspect i overkill it (usually 100 nF/10 nF on every pin, or 1u/100n on power hungry stuff)
<marcan>
just do what everyone does and put 100nF on every power pin
* marcan
hides
<awygle>
(plus a 10uF bulk)
<azonenberg>
awygle: My rule for moderately large/fast digital boards is, minimum 100 uF on every rail, 4.7 uF on every chip/bank, 0.47 uF on every vdd/vss pair
* awygle
remembers not to talk about overkill when azonenberg's around
<azonenberg>
Anything this is insufficient for is likely a large fpga/soc which will come with more extensive decoupling recommendations
<balrog>
marcan: optimizer pass blob? I don't remember that
<whitequark>
hahaha
<marcan>
balrog: there was some ugly thing involved
<azonenberg>
the way i see it is, passives are cheap and respins are expensive
<balrog>
I do remember them artificially limiting it and then having it check "licensing"
<azonenberg>
Unless you plan to make tens or hundreds
<balrog>
if you're talking about XC16/XC32
<awygle>
whereas every board i've made in the last... three years? has been BOM-cost-dominated
<marcan>
maybe it was open source, I forget
<marcan>
also C18 was fun
<azonenberg>
awygle: I make lots of stuff that's BOM dominated
<azonenberg>
but normally it's things like $40 comparators and $250 FPGAs
<marcan>
you could install the "upgrade" download by creating an .exe file full of zeros with the same size as the previous version, and installing over that
<awygle>
ah with one exception, the elysium was board-dominated because it was IPC 3/A
<azonenberg>
Not $0.05 caps
<marcan>
no license required
<balrog>
C18 / XC8 is another story
<marcan>
C18 was so bad though
<marcan>
I switched to SDCC
<marcan>
C18 had two modes: blatantly violating the C standard, and issuing 10x more instructions than necessary
<marcan>
no middle ground
<whitequark>
ugh PIC
<whitequark>
why is PIC so bad
<whitequark>
PIC8 was my first microcontroller and I still have trauma from switching memory banks
<awygle>
why is PIC so *popular*
<whitequark>
also why is it so sloooooow
<marcan>
I ported a USB device stack to PIC18 assembler
<azonenberg>
whitequark: thankfully i never had problems with memory banks because i never wrote ASM
<whitequark>
PIC8 is not even pipelined
<awygle>
it's easy to design bad microcontrollers, it's less easy to get them widely adopted
<marcan>
I couldn't get it to work and I was convinced it was bank switching
<azonenberg>
whitequark: yes, i have no idea why the isa is so awful
<marcan>
so I printed the whole thing out and went over it with a highlighter to mark the banks
<marcan>
found the problem and it worked after that
<azonenberg>
I quickly graduated from pic8* to pic32
<whitequark>
marcan: you have truly absurd amounts of patience
<azonenberg>
Which is actually halfway decent since it's a licensed mips cpu core
<balrog>
XC8 is supposed to be much better than C18
<marcan>
my first micro was the 16F84 (heck that's where my avatar comes from, the 18 pin PDIP is somewhat characteristic)
<azonenberg>
xc8 is a gcc port right?
<balrog>
unfortunately, it does not do much in the way of optimizing code unless you pay for it
<balrog>
azonenberg: no it's not
<marcan>
and I never really got on the AVR bandwagon much
<azonenberg>
i know xc32 is
<azonenberg>
and i think xc16?
<marcan>
never touched PIC32 either though
<balrog>
XC16 and XC32 are, and source code are provided
<marcan>
if I'm going there I might as well go ARM
<azonenberg>
marcan: see, i did it specifically because "not arm"
<balrog>
some people are working on alternate firmware for the tl866 programmer
<balrog>
and that thing's built around a PIC18
<marcan>
when I started ARM µCs weren't really a thing
<whitequark>
marcan: mine was PIC16F648A
<azonenberg>
mine was 12f683
<whitequark>
and that's why I will never touch PIC again
<azonenberg>
the first mcu i ever developed for and, fittingly
<azonenberg>
the first one i ever broke the code protection on :p
<marcan>
ah, I've used 628 (smaller 648)
<marcan>
see this is anonther thing that annoyed me
<marcan>
people *kept using the fucking 16F84*
<marcan>
because it was the first flash pic ever
<awygle>
my first mcu was an msp430g2232
<marcan>
and thus became the standard for hobby use
<azonenberg>
marcan: lol
* cpresser
started with the 16c84
<whitequark>
marcan: there's a short story in russian about a programmer slowly going insane trying to fit a firmware into a 16f6?8a
<marcan>
even when the 16F88 was pin compatible, had a bunch more peripherals, ran faster, more memory, ADC, everything, and was *cheaper*
<marcan>
but people are terrible
<whitequark>
it never mentions the chip by name but i KNOW
<awygle>
MSPs have some crazy stuff (20-bit address bus, split memory map) but at least the ISA is quite clean and orthogonal
<azonenberg>
awygle: yeah pic32mx had a few buggy peripherals and no MMU but overall it was a really nice platform
<marcan>
MSP430 has the worst JTAG ever
<marcan>
I had to write a programmer for those
<balrog>
(the tl866 uses an 18F87J50)
<azonenberg>
i outgrew it, wanted something with multiprocessing capability and they had no memory protection between usermode processes
<marcan>
they broke it so badly you can only use them as the first device in the chain
<awygle>
marcan: yes, that's fair
<azonenberg>
pic32mz didn't exist yet
<awygle>
TDI to clock the CPU lol
<marcan>
yeah
<marcan>
I don't even
<marcan>
oh and if you get the clockrate wrong the flash fries itself
<marcan>
(or so the datasheet said)
<azonenberg>
marcan: o_O
<awygle>
Spy-bi-wire is also pretty bad
<awygle>
the FRAMs had a serious reset issue for a while
<awygle>
i could corrupt the NVM in about thirty seconds
<awygle>
but they fixed it thank god
<marcan>
yeah, sbw is sad too
<awygle>
TDD-JTAG
<marcan>
I also had to support that
<awygle>
me too
<awygle>
and i was telling whitequark the other day about how we solved the "only one device in the chain" problem
<marcan>
it was my first job at a company whose production cycle was plugging in the production board to the debugger, changing the #define SERIAL in the code, and hitting compile and run
<marcan>
also saved their ass when a production run had the wrong xtal compensation caps and thus clock drift... which they could work around in software, but they had 300 units programmed
<whitequark>
awygle: to do *what*
<marcan>
I made a little self-contained updater on my first day, on protoboard
<marcan>
(having never used MSP430 at all)
<awygle>
whitequark: well see jtag can be run arbitrarily slowly, and all the pins are unidirectional, so...
<marcan>
that saved the parameter area and just updated the code
<whitequark>
awygle: aaaargh
<awygle>
we later replaced it with an FPGA-based version. which was still awful because of dynamic chain sizing and "blind shifts" and other things, but was a _marked_ improvement
<awygle>
(the biggest improvement was that they gave it to somebody else so it wasn't my job anymore)
digshadow has quit [Ping timeout: 264 seconds]
<azonenberg>
awygle: lol
<marcan>
JTAG... over JTAG.
<marcan>
just. why.
<azonenberg>
The best problem is one that's not on you :p
<awygle>
i mean i could give my boss' reasoning, but that would sound like i'm trying to justify that horrific decision
<marcan>
so it's a 74xx chip with JTAG
<marcan>
I had no idea this was a thing
<marcan>
this feels so wrong
<awygle>
the chip itself is kind of useful for board level test stuff
<awygle>
you can get a reasonable amount of self-test out of it
<azonenberg>
awygle: yeah i think that's basically why it exists
<azonenberg>
boundary scan shim
<marcan>
yeah that makes sense
<awygle>
but that architecture, sheesh
<marcan>
add JTAG to things without it
<azonenberg>
marcan: i did jtag over jtag over tcp/ip once, does that count?
<awygle>
iirc the main reason to use that chip is it's on like, 450 nm, so low chance of SEU
<awygle>
(this was also for cubesats)
<azonenberg>
this was for a completely different reason
<azonenberg>
i had a jtag master core for Antikernel
<azonenberg>
I needed to test it
<azonenberg>
I had a bridge from the antikernel NoC to JTAG
<azonenberg>
And a bridge from JTAG to TCP
<azonenberg>
So i could connect over the TCP socket and give commands to the IP in hardware to exercise it
<marcan>
awygle: ah, makes sense then
<awygle>
mmm i wouldn't go that far :p but yes, there were reasons
<marcan>
at least it wasn't sony-level ridiculous design
<marcan>
seriously, the stuff they manage to ship in a mass market consumer product is amazing
<marcan>
I'm amazed at how their engineers are allowed to piss so much money away
<balrog>
marcan: is there any interest anywhere from anyone in developing better compilers for 8-bit PIC?
<balrog>
there was an LLVM backend but it got removed because it wasn't properly abstracted
<marcan>
the original ps3 being sold at a loss... probably had something to do with the full SoC that was the "southbridge". complete with a MIPS CPU and a DRAM controller that went totally unused, and probably more silicon area than the damn Cell. or the 8-port Ethernet switch chip in there, of which they used 3 ports. Why? Because their WiFi controller wasn't a WiFi controller, it was a self-contained ...
<marcan>
...SOHO router daughterboard connected via *ethernet* to said switch, acting as a WLAN<->Ethernet bridge. oh and their HDD was SATA but the old SB only did PATA, so they needed a bridge for that too. And their boot Flash used a full custom NAND controller connected to the SB bus, because they couldn't figure out how to do it with a megabyte of NOR
<marcan>
eventually they figured out... some of these things... in the latter revisions.
<azonenberg>
lol
<marcan>
except that PATA<->SATA bridge. their new southbridge was SATA... but the BD-ROM was still PATA... so they kept it, flipped around.
<sorear>
the original PS3 had a MIPS SoC in order to run PS2 games, it was the PS2 SoC
<marcan>
no, not *that* MIPS
<marcan>
*another* MIPS
<sorear>
unless you're referring to a *second* entire MIPS SoC
<marcan>
yes
<marcan>
a completely separate one
<marcan>
the "southbridge"
<marcan>
the EEGS from the PS2 was a separate thing
<marcan>
which IIRC MITMed the video output of the PS3 GPU itself, passing through in PS3 mode
<marcan>
(and itself contained two MIPS cores)
<sorear>
eesh
<marcan>
basically their "southbridge" was a full STB SoC or so
<marcan>
much like the PS4 "southbridge" is a full ARM SoC
<marcan>
which also does I2C over message passing bytecode because why would anyone ever use the GPIOs that the APU has precisely for this purpose?
<marcan>
oh and the PS4 internal hard drive is connected... via an internal USB3-SATA bridge chip.
<marcan>
even though they *have* a SATA controller.
<marcan>
I've never figured that one out
<azonenberg>
marcan: bug in the controller?
<azonenberg>
or stupidity on the part of the engineering team not knowing it was there?
<marcan>
but they used it for blu-ray...
<awygle>
i usually assume stuff like this is the result of Gotta Go Fast-ing your way through a design project
<azonenberg>
both are equally plausible :p
<azonenberg>
lol
<awygle>
the more entire SoCs you throw in there the easier it is to split up your engineering teams
<azonenberg>
yeah, this is why i could never cut it in consumer electronics
<azonenberg>
I'm not willing to cut corners
<balrog>
azonenberg: lol
<azonenberg>
if i ever switch careers from infosec to dev, i'd have to go to aerospace or medical or something where there's still gonna be BS but people care more about the final product working than FIFI'ing their way through it
<awygle>
meanwhile i kind of want to work on crappy consumer stuff now because i'm so tired of design reviews where people delay board fab by a week saying "nudge C10 to the right and up so you can get 0.1 nH less inductance on our 48 MHz processor"
<marcan>
shots fired
<awygle>
:p azonenberg just said "this is better, but you're fine", he didn't tell anybody what to do
<marcan>
I know I know :P
<azonenberg>
awygle: you havent worked on the kinds of things i've seen, lol
<azonenberg>
things where there was either no design review, or a woefully incompetent one
<azonenberg>
Things like boards coming back from fab and parts not fitting because nobody double checked the pin pitch
<azonenberg>
this wasnt a class project, i'm talking industry here
<marcan>
ouch.
<whitequark>
marcan: that PS3 stuff is horrifying
<azonenberg>
or... one of my favorites
<azonenberg>
a PMIC containing an LDO and a bunch of buck converters
<azonenberg>
Bucks are 15V Vimax, powered off 12V
<azonenberg>
LDO is unused
<azonenberg>
The geniuses connected the LDO Vin to the 12V rail, not reading the datasheet saying Vimax of the LDO was 6V b/c it was supposed to be a post-regulator for the buck
<marcan>
"oops"
<sorear>
Is that the one that exploded?
<azonenberg>
End result: hot, unhappy board that shockingly worked fine after i cut the trace
<marcan>
that's china-level
<azonenberg>
i expected the pmic to be dead
<marcan>
I once bought a USB hub (does *anyone* make USB hubs that don't suck and actually meet spec?) that had the hub chips with a strap connected to 5V
<marcan>
except it was a 3.3V pin with an internal pull-up
<azonenberg>
...
<marcan>
guess how much power was going through there
<azonenberg>
marcan: this was a major publicly traded US company here
<azonenberg>
Re usb hubs, i did a pretty solid design a while ago that i want to redo with a new chipset (the old one is kinda obsolete now)
<azonenberg>
it had overcurrent shutdown AND a dedicated overcurrent indicator LED per port
<azonenberg>
So when you shorted you knew immediately
<azonenberg>
and fairly hefty esd protection on all the data lines after i blew out a port on my first iteration
<kc8apf>
I worked with a team that spent a _lot_ of time making a robust 128 port USB hub
<pie__>
what HASNT azonenberg made yet
<azonenberg>
whitequark: pad in via, lol
<azonenberg>
that's about right
<marcan>
azonenberg: I want one :P
<azonenberg>
marcan: it was meant as a developer's hub
<azonenberg>
the next-gen model was going to have full ethernet-switch-style port management
<azonenberg>
where you could query status and force resets of ports
<azonenberg>
But i never finished it
<kc8apf>
azonenberg: add charger mode emulation and power monitoring and I'm sold
<azonenberg>
If i get back to it, i'm going to switch chipsets
<azonenberg>
the old one had a single TT so it was slow for many usb 1.x chips
<awygle>
yeah i'd like one too
<azonenberg>
i'd go with a multi-TT one
<marcan>
so far my conclusion is that all hubs you can get at actual shops are crap, the only important difference is genesys logic chipsets are ultra crap (they instafry their ports if you so much as brush D+/D- against 5V, which is of course super easy to do, and blatantly violates the spec robustness requirements), and Terminus Tech ones, which are better
<awygle>
i've powered too many things off usb
<marcan>
so I try to stick with hubs that use terminus chips
<marcan>
preferably multi-TT, I have one with one of those which is neat
<azonenberg>
This was a Cypress chipset
<awygle>
or back-powered USB too many times
<azonenberg>
I havent looked if they have a good multi-TT one
<marcan>
awygle: oh that too, I just assume hubs back-power by default
<awygle>
grab an Artix, do it yourself :p
<marcan>
and if I need to power them off DC then I cut the trace
<azonenberg>
awygle: actually, i seriously considered it
<azonenberg>
except i hate usb so much i really dont want to :p
<pie__>
my surface three ?reboots? if you short something in the usb port
<pie__>
i usually do it by accident by trying to plug the micro usb into the usb
<marcan>
currently I just have a 16-port USB2 hub which at least doesn't back-power (not like it'd ever work bus powered anyway, so they didn't try) and is at least reasonably robust
<azonenberg>
i do want a solid usb 2.x hub down the road though
<marcan>
runs off 5 cascaded TT chips
<kc8apf>
and Twitter has become useless for me for the rest of the day
<azonenberg>
So i might get back to it at some point
<awygle>
i put 28V across my laptop's USB port and it was fine!
<awygle>
that was surprising
<awygle>
good diodes
* awygle
thanks whitequark for the recommendation once again
<marcan>
not bad
<awygle>
of course it shouldn't be designed so the charger connector fits in a usb port and perfectly bridges pins, but still
digshadow has joined ##openfpga
<azonenberg>
awygle: LOL
<azonenberg>
stinkpad?
<azonenberg>
with the new square power connector?
<awygle>
XPS15
<awygle>
it's a small barrel connector
<awygle>
the pitch is just unfortunate
<balrog>
oh those
<marcan>
... how does a barrel connector fit into a USB port?
<whitequark>
awygle: wait what
<balrog>
marcan: by being really tin
<awygle>
its diameter is <(height of usb port)
<balrog>
tiny*
<whitequark>
it doesn't seem to fit on mine?
<awygle>
whitequark: this is a pretty new model, from this year, maybe it got smaller?
<whitequark>
huh, maybe
<awygle>
also i have the 15 not the 13
<balrog>
whitequark: does yours have a pin in the center?
<whitequark>
awygle: "Component U4 pad 0 not found in footprint" for the FPGA
<awygle>
whitequark: whoops.
<whitequark>
that's one of VCC pins
<whitequark>
which should it be?
<awygle>
5 or 30 are the vccs
<whitequark>
aha 30
rohitksingh has joined ##openfpga
<awygle>
Guess I dropped the 3
* whitequark
very carefully connects IFCLK to a clock-capable pin
* whitequark
has fresh trauma from that board
<awygle>
:-)
<rqou>
whitequark: don't want to go through the internal fabric before hitting a bufg? :P
<rqou>
actually can ice40 even route fabric to a bufg without doing pin feedback?
<whitequark>
yes
* whitequark
is offended on behalf of ice40
<pie__>
is ice our most favoritest fpga arch
m_w has joined ##openfpga
<pie__>
is it better than X / A
<whitequark>
for most of my projects FPGAs with non-FOSS toolchains could as well not exist
* pie__
draws an US / YOU line
* pie__
needs t ostop shitposting nad get somewhere with his life
<whitequark>
life?
<awygle>
Ooo new ryzens
<pie__>
(shitposting IS life)
<rqou>
i guess I've been doing too many things with weird CPLDs
<rqou>
xc2 needs pin feedback to feed a BUFG
<rqou>
although I need to test on hardware whether you can disable the actual pad or not
<whitequark>
the actual pad?
<rqou>
each pin has an "OE mode" selection
<awygle>
eesh lots of stupid errors on new msop footprint, you can tell I'm getting sloppy.
<awygle>
gotta focus up this weekend
<whitequark>
hm
<whitequark>
so I have a 48 MHz IFCLK track crossing I2C SDA and SCL
<whitequark>
though there are two planes between them
<rqou>
eh, probably fine
<rqou>
add a "chicken" series resistor near the driver?
<whitequark>
er
<whitequark>
what would that do exactly?
<whitequark>
azonenberg: so on this 48 MHz bus, do I do series termination? or not care?
<whitequark>
it'd be a whole lotta resistors
<rqou>
it limit slew rate which maybe helps with noise?
<azonenberg>
whitequark: perpendicular crosisngs are normally OK
<azonenberg>
especially if you have planes in between
<azonenberg>
parallel is more of an issue but again with planes in between should be fine
<azonenberg>
whitequark: what's the bus coming from? ice40?
<rqou>
azonenberg: does a series resistor actually help?
<azonenberg>
rqou: with what? it helps reduce ringing on fast transitions even if the line is too short for transmission line effects to be a thing
<azonenberg>
there's still some LC resonance from parasitics
<azonenberg>
often you can get away without termination if you tweak drive strength down a bit
<whitequark>
azonenberg: bidirectional between ice40 and cy7c68013a
<rqou>
azonenberg: yeah, that's what I expected. does it help with noise coupling into other lines?
<azonenberg>
rqou: That i dont know
<azonenberg>
crosstalk has never been something i've had problems with
<azonenberg>
But i normally err on the side of caution with SI
<whitequark>
ice40 has 8mA drivers, cy7c68013a has 4mA drivers
<azonenberg>
Since a few passives are cheaper than a respin
<azonenberg>
whitequark: does the ice40 have programmable drive or no?
<whitequark>
not really
<azonenberg>
I might put a resistor footprint in but 8 mA drive isn't too excessive so you'd probably be fine without
<whitequark>
k, going without then
<azonenberg>
You definitely wont have transmission line issues with 48 MHz
<rqou>
s3 >= 16 mA drive trololo :P
<azonenberg>
as long as the lines are sane sized
<azonenberg>
let's see... 1/20 wave for 50 MHz is 30 cm
<azonenberg>
your max edge frequency is probably ~10x that
<azonenberg>
so 500 MHz or 3 cm
<azonenberg>
if your bus is shorter than that transmission line effects should be negligible
<whitequark>
my bus is 28 mm long exactly
<whitequark>
well the longest trace anyway
<azonenberg>
Yeah so t-line effects should be negligible and at that drive strength i wouldnt expect much overshoot
<marcan>
and lane skew won't be an issue either at those speeds
<rqou>
azonenberg: many years ago my father interviewed somebody who was using s3 with the 16mA drive and hitting simultaneously switching output limitations
<marcan>
whitequark: for reference, both the twlfpga and OV3 have a 60MHz bidir bus between an FT2232H and a Spartan (3E/6) and none of these things were particularly considered during design
<rqou>
apparently the fpga will behave _really_ strangely in that case
<marcan>
max length is ~3cm eyeballing it
<rqou>
since you're effectively glitching it
<marcan>
oh and there's also 100MHz SDRAM on the OV3 which worked fine once we got the clock phase right
<marcan>
on actually the OV3 has a big fat pin header in between, for debugging
<marcan>
so more like 5-6cm length
<marcan>
and a 1cm stub right in the middle
<awygle>
rqou: yes, reducing overshoot will reduce crosstalk (and EMI)
<marcan>
(and wider lane spread since it widens out)
<marcan>
so yeah, really, at these speeds... you can get away with a lot
<rqou>
unfortunately my father also mentioned that the candidate characterized the issue very well but never understood what the root cause was
<rqou>
in summary don't use parallel buses :P
<awygle>
spread spectrum parallel busses?
<rqou>
no, this was a dumb parallel bus
<awygle>
Spread spectrum parallel busses are not a thing
<awygle>
I was suggesting a comical solution for the problem
<rqou>
oh i misread
<rqou>
I thought you meant PCI-style unterminated buses
* rqou
wants nomz
<marcan>
didn't even PCI buses have spread spectrum at some point?
* rqou
is currently standing in the classic Stuffed Inn line (awygle i assume you're familiar :P )
<awygle>
of course
<whitequark>
who mentioned food
<whitequark>
how i want food
<rqou>
lol
<marcan>
now I want food
<marcan>
and I had sushi for dinner and was going to go to sleep, but now I'm hungry
<awygle>
now I'm going to get food
<awygle>
mmm sushi...
<awygle>
rqou: is stuffed in in the corner of "Durant food court"? I think that's the one where the lady who ran it always gave me double portions
<azonenberg>
marcan: pci used really fun "reflected wave signalling"
<azonenberg>
basically, the bus is deliberately unterminated and the signal amplitude is too weak to do anything
<marcan>
yeah I seem to recall something like that
<azonenberg>
But the reflection constructively interferes with the original signal
<rqou>
awygle: no, the sandwich shop on northside euclid
<azonenberg>
and that's strong enough to trigger the input buffer
<rqou>
awygle: i see you deliberately didn't use the "not-PC nickname" :P
<awygle>
Ohhh yeah that place
<awygle>
Not a big fan frankly
* azonenberg
recalls his dad referring to gradd school as "Stevens Hoboken Institute of Technology"
<azonenberg>
grad*
<marcan>
how does reflected-wave switching compare to an uncontrolled unterminated bus?
<rqou>
awygle: not a fan of stuffed inn? heretic :P
<azonenberg>
marcan: the reflections are desired and intended
<azonenberg>
and in fact, if terminated it wont work
<marcan>
right
<azonenberg>
the receiver threshold is above the drive voltage
<rqou>
especially since it's currently Friday and they have clam chowder :P
<azonenberg>
The idea is, by requiring and only triggering on reflections
<marcan>
oh, it's above the drive voltage, not just a function of the current drive?
<azonenberg>
i think so?
<azonenberg>
The idea is that you can skip terminating
<azonenberg>
and be guaranteed good SI
<azonenberg>
by making the reflection actually part of the spec :p
<marcan>
but then wouldn't that be AC-only?
<marcan>
steady state you get the drive voltage
<marcan>
that sounds wrong
<azonenberg>
i dont know if pci does any kind of scrambling or something to enforce a min frequency?
<azonenberg>
i never looked into reflected wave signaling in great detail
<marcan>
pretty sure it doesn't
<marcan>
PCI is dumb
<azonenberg>
they might just be using the reflection to speed up edges or something
<rqou>
^ i think this is right
<marcan>
or just to avoid termination
<whitequark>
no, it is not right
<whitequark>
but that's what they do
<azonenberg>
whitequark: lol
<awygle>
what's that hoagie place on Durant called? I love that place
<rqou>
my father also had "fun" stories of engineers who didn't listen to him and used this huge expensive asic that bridged PCI to a sram interface
<rqou>
rather than just using the fpga directly
<rqou>
or a cpld
<whitequark>
wat
<marcan>
lol
<rqou>
and then the asic went NRND as expected
<awygle>
good God pci actually does this?
<awygle>
the only reason I can think of to do this is cost
<rqou>
awygle: not sure what place you're referring to on Southside and not sure if it's still here
<awygle>
and maybe power
<rqou>
i noticed you don't call it the asian ghetto :P
<awygle>
rqou: IB's
<whitequark>
awygle: hmm
<whitequark>
should I squish this board into 5x5cm?
<awygle>
and I did when I was there lol
<awygle>
whitequark: hmm
<rqou>
1x1 cm like esden :P
<awygle>
space is often good
rohitksingh has quit [Quit: Leaving.]
<azonenberg>
awygle: sooo if you look at PC hardware design in general
<azonenberg>
most of the atrocious design decisions were done to reduce cost
<awygle>
I respect the Will to Smolness but having space to manipulate connectors is nice too
<azonenberg>
just look at DDRx SDRAM having the bidirectional bus and DQS for example
<azonenberg>
instead of a sane source synchronous interface that needa few more pins
<whitequark>
awygle: true
<azonenberg>
like e.g. RLDRAM does
<marcan>
I get the feeling the idea is to use a 3.3V driver with a low enough output drive that the incident wave coupled onto the transmission line drives it to 1.5V (but it's still a 3.3V driver)
<marcan>
then once the signal bounces back it actually makes it to 3.3V (and stays there)
<azonenberg>
lol
<azonenberg>
yeah it seems like they're baiscally using the reflection as "poor man's preemphasis" almost
<whitequark>
"the maximum length is limited to 15cm" riiiight
<whitequark>
I was wondering about that
<marcan>
honestly this sounds more like "engineers wanted to use a cheap unterminated bus and came up with a fancy term to make it sound sophisticated"
<marcan>
it's a dumb approach somewhat optimized to actually work and not eat power / spew EMI :P
<azonenberg>
marcan: s/engineers/managers trying to cut costs/
<marcan>
managers didn't come up with "reflected wave switching" :P
<azonenberg>
no but, they probably told the engineers terminating resistors were too expensive and took up too much board space
<azonenberg>
and that they had to find a way to get rid of them
<marcan>
fair
<rqou>
oh yeah, sdram is a huge pain with its DQS
<azonenberg>
Like i said, most of the awful design decisions in PC hardware are cost driven
<azonenberg>
or, as my old roommate used to say
<azonenberg>
"if it doesn't make sense there's probably money involved"
<rqou>
also, i really wish ice40 had idelay
<marcan>
azonenberg: tell that to sony
<rqou>
lol sony
<azonenberg>
rqou: i wish artix7 had odelay
<azonenberg>
:p
<azonenberg>
7 series has odelay only in HP banks, which artix/spartan lack
<azonenberg>
idelay is everywhere at least
<rqou>
well ice40 has neither
<azonenberg>
nothing you cant fix with some luts configured as delay lines + muxes
<azonenberg>
of course your per-tap resolution will suck...
<rqou>
azonenberg: thoughts on RGMII "pcb trace delay"? :P
<azonenberg>
rqou: Never use it, i phase shift the clock with a pll or odelay
<azonenberg>
then route everything skew matched
<azonenberg>
adding that much skew on a pcb is HARD
<azonenberg>
you'd have to make the clock like a foot longer than the data or something
<rqou>
marcan: wait, the ps3 _also_ has a cpu core in its southbridge?
<marcan>
yeah, except the ps3 doesn't use it for anything
<marcan>
they just used a semi off the shelf southbridge for the first iteration with a LOT of extraneous shit
<rqou>
can it even be powered on?
<marcan>
not even sure if the hardware allows it
<marcan>
the RAM controller isn't connected to any RAM anyway so...
<marcan>
rqou: sounds like BS to me, the hardware was just crap
<marcan>
PS2s after v7 went downhill
<marcan>
there were a number of "fixes", some of them more voodoo than others
<marcan>
this is why I still have a v7 PS2 :P
<rqou>
also apparently the PS2 also has the classic sony "yeah, just ignore the security processor" design :P
<rqou>
btw fun thing i discovered recently:
<rqou>
apparently nocash dumped the ps1 drive controller mcu recently
<rqou>
it's apparently an HC11 and you can dump it by somehow fiddling with the boot mode straps
<rqou>
and supposedly there's a "backdoor unlock the drive" command
xdeller_ has joined ##openfpga
<rqou>
so theoretically SCEx injecting was never necessary
xdeller_ has quit [Remote host closed the connection]
<rqou>
somebody made a demo of exploiting a save buffer overflow in some game and then loading a rebooter
<balrog>
rqou: did nocash publish this?
<rqou>
it was on some forum somewhere
<balrog>
does anyone want another ps1 board to play with?
<marcan>
hah, cute
xdeller has quit [Ping timeout: 264 seconds]
<rqou>
btw SH1s (e.g. in the Saturn) are vulnerable to being dumped by fiddling with the boot mode straps too
<rqou>
some H8s might be but i haven't tested
<marcan>
I should mess with older consoles again now that I have a vague idea what I'm doing...
<marcan>
well, I guess GBA is first
<marcan>
not today though, good night ;)
<rqou>
heh GBA
<rqou>
my first foray into embedded :P
<marcan>
my first foray into ARM and game console programming
<marcan>
embedded... well PIC came first
<marcan>
so my second foray? :P
<rqou>
I'm disappointed how much "emu people" are scared of hardware
<rqou>
wait wat
<rqou>
marcan aren't you much older than me?
<marcan>
I'm 27?
<rqou>
huh
<whitequark>
you're how old?!
<rqou>
so not "much" older
* whitequark
feels inadequate
* rqou
too
* marcan
is confused
<marcan>
since when does age matter anyway? :P
<cr1901_modern>
It doesn't IME. I'm 27 as well, and there's plenty of ppl younger than me who make me look bad
<rqou>
wait, so the ps3/wii stuff happened when you were ~19?
<marcan>
my first commit to the team twiizers repo I was 17, says git history
<cr1901_modern>
I didn't learn to navigate a file system (or program) till I was 18.
* whitequark
feels *extremely* inadequate
* marcan
feels like he wastes all his time these days
<marcan>
back then I was *actually* productive
<marcan>
I used to actually design boards and stuff
<rqou>
i occasionally feel that too
<rqou>
but i would never want to return to being stuck in K12 again
<rqou>
f*ck (USA) public K12 education
<marcan>
Date: Tue Mar 18 08:39:09 2008 -0400
<marcan>
jeebus it's actually been 10 years since then
<marcan>
I feel old.
<rqou>
although i did end up getting into $FANCY_UNIVERSITY, so K12 wasn't a total loss
<whitequark>
marcan: i waste so much time these days
<whitequark>
well
<whitequark>
i guess i have the excuse of having had undiagnosed bipolar disorder
<whitequark>
but still
<marcan>
I probably have some degree of undiagnosed ADHD... but there's also the fact that 10 years ago I never signed up for Facebook, Twitter and Reddit barely existed, and Slashdot could only take so much of my time.
<marcan>
I was going to add that as a student I had a lot of free time but that's lying, my current freelance schedule is barely part-time and I still waste most of my free time anyway
<rqou>
being a student sucks up a ton of time
<marcan>
being an employee sucks up more
<marcan>
my project productivity took a nosedive once I got a real job
<marcan>
and never recovered
<rqou>
hmm true enough
<rqou>
being a "lazy not-trying-hard-enough azn" in high school was great for free time
<rqou>
but not great for having enough access to resources
<cr1901_modern>
How were you in high school in 2003 if you're 27 now?
<marcan>
now until a couple months ago I hadn't designed a board in years... finally got around to using kicad during a meetup after CCC to put together a sync combiner for a VGA cable.
<marcan>
maybe it was middle school
<rqou>
lol 2003 i was in elementary school
<marcan>
that was 7th grade IIRC
<rqou>
heh, 7th grade i was failing to hack nprotect gameguard lol
<rqou>
i did eventually manage to scrounge enough resources to factor their rsa key though
<cr1901_modern>
Yea, in 2003 I was watching anime, surfing all the corresponding Angelfire/Geocities fanpages, playing video games and... not much else outside of school, tbh.
<balrog>
lol how bad was their rsa key?
<rqou>
512 bit
<awygle>
cr1901_modern: i assumed you were older because of your love of vintage hardware
<rqou>
they've since upgraded
<awygle>
i have actually forgotten how old i am. i think 27? let me do the math...
<marcan>
lol
<cr1901_modern>
awygle: No, I just like buses that can be interfaced w/ using 3 TTL chips :)
<marcan>
re: vintage hardware, it helps if you get started with computers early...
<rqou>
i was inspired to try it after the ti calculator factoring
<marcan>
my parents were software translators. I got all the junk PCs they stopped using. Starting with a 386.
<cr1901_modern>
As opposed to requiring length matched traces and a PHY blob
<marcan>
we also had a Spectrum
<rqou>
heh i started on a boring windows pc
<awygle>
yes, 27
<marcan>
funny thing is at one point I got tired of getting all the junk... so I asked for an actual new computer and ended up upgrading from a Pentium 133 to an Athlon XP 1800+
<awygle>
i have been telling people 28 for a while... hope that doesn't turn out to matter
<marcan>
minor bump there
<rqou>
but i did a bunch of experimenting with the GBA
<awygle>
in high school i did some PSP dev
<awygle>
that's actually the only console-y thing i've ever really done
<cr1901_modern>
Now, well I still watch anime, I don't play video games at all basically, and Geocities doesn't exist. So I play w/ hardware
<rqou>
the bitbang-capable link port and mode3 are actually pretty great for noobs getting started woth embedded
<marcan>
I think I still have the first program I ever wrote
<marcan>
on qbasic on that 386
<marcan>
somehow it has survived through multiple nested levels of backups all these years
<marcan>
(even though I do have a black hole in my digital history from when Seagate and ReiserFS conspired to murder my data through 8 very carefully chosen bad sectors)
<marcan>
(that was 40GB gone)
<whitequark>
lol seagate and reiserfs
<cr1901_modern>
>ReiserFS
<cr1901_modern>
>murder
<whitequark>
perfect storm
<marcan>
(I started using RAID after that)
<awygle>
lmao riserfs
<cr1901_modern>
I see what you did there
<rqou>
so i guess i actually have to thank devkitpro for helping me start out on embedded
<marcan>
oh, you had devkitpro
<marcan>
lucky you :P
<balrog>
only 8 bad sectors? :/
<awygle>
i didn't do anything that required hardware until college
<rqou>
oh wait
<cr1901_modern>
awygle: A tldr about why I like vintage hardware is that I like being able to see the interconnects of a bunch of single-purpose/specialized chips working together to become greater than the sum of it's part.
<awygle>
which is why i wanted to be an EE in college
<marcan>
balrog: I think it was the btree node for my /home or something
<balrog>
urgh.
<rqou>
i was using hamlib before that
<marcan>
I tried, but couldn't get anything sensible recovered
<balrog>
not even with photorec...
<awygle>
and probably why i still have some "software is easy" cruft in my brain even though it's demonstrably not
<marcan>
well that would work, but what's the use for a whole bunch of random untagged files
<whitequark>
cr1901_modern: that describes any modern chipset nicely
<marcan>
I had devkitadv, which is what it was called back then
<marcan>
and mostly wrote stuff without any libs, or with libpogo
<rqou>
yeah, i definitely started on hamlib and went to devkitpro around when they were making the EABI transition
<rqou>
i do remember tutorials talking about dka instead
<rqou>
as well as hacks to flip OABI .o files to pretend to be EABI
<marcan>
I still think pogoshell has the best design for a gamepad-compatible keyboard input method
<marcan>
I could actually play text adventure games on a GBA without too much effort
<marcan>
I'm really sad nobody copied that for other systems
<cr1901_modern>
whitequark: When I say "see" I mean "visually inspect" with my own eyes. Or read a schematic. I don't get that joy from modern hardware (which of course is inherent to it's complexity).
<rqou>
i used a SCSD because that had already existed
<awygle>
cr1901_modern: drain cleaner decap and a sweet microscope?
<awygle>
(i know it's not the same)
<rqou>
fortunately i never had to deal with nor flash "linkers"
<marcan>
oh I did
<marcan>
still have my F2A cart and linker!
<cr1901_modern>
You can access the PCIe bus directly from the CPU in the most recent Intel chipsets, right?
<whitequark>
azonenberg: hm, can I abstract a part of schematic in kicad and insert it twice?
<whitequark>
cr1901_modern: huh?
<whitequark>
how else would you access it?
<marcan>
and it's looking like I'm going to wind up trying to write firmware for a TL866 I just ordered to see if I can make that flash carts instead :P
<rqou>
um
<cr1901_modern>
whitequark: There is a direct "physical" connection to the PCIe bus' pins from the CPU IC
<rqou>
you know digshadow/cr1901_modern are also working on hacking the tl866 right?
<marcan>
that is exactly why
<marcan>
they poked me about that and I just constructed that as an excuse to get one and mess with it
<whitequark>
cr1901_modern: yes, the CPU has a PCIe bus
<marcan>
since otherwise I know I wouldn't :P
<whitequark>
it also has a DMI bus that gets bridged to more PCIe inside the PCH
<awygle>
whitequark: you should be able to use hierarchical sheets to do that
<rqou>
you can decrypt Xilinx files by just loading the right .so and calling the decrypt function :P
<marcan>
the lattice stuff is at least part of the synthesis binary
<marcan>
I reverse engineered the 32-bit one because I didn't have 64-bit hex-rays
<rqou>
oh, they're using one of the standard(?) crypto extensions
<marcan>
took me a while to find the private key, I tried some blackbox approaches first (testing every possible offset to see if it worked as a key and such)
<marcan>
turns out it was lolfuscared by XORing
<rqou>
lol
<marcan>
I think it's a synopsys thing?
<marcan>
but anyway
<marcan>
then I went to load it in gdb, so I switched to the 64bit binary
<marcan>
... and it turned out they forgot to strip it
<marcan>
it had an rsa_key symbol.
<whitequark>
wtf
<rqou>
lolol
<q3k>
it probably needs to work with both LSE and synopsys, so there's at least two copies of the crapto
<rqou>
lololol
<awygle>
wait what "lattice encryption" are we talking about? the bitstream encryption?
<marcan>
no, RTL encryption for their softcores
<rqou>
nah, hdl encryption
<marcan>
which are just verilog
<awygle>
ohhh ok
<q3k>
I know the the LSE/neocad part of Diamond has quite a lot of oldschool xorfuscation in it
<marcan>
with comments.
<awygle>
never mind then lol
<q3k>
at least for part definitions
<marcan>
I have a full broken out verilog tree of their PCIe softcore
<rqou>
btw you should read the official VHDL spec for crypto
<marcan>
with a tiny patch to send all TLPs out to the debug/unknown interface
<marcan>
(since I didn't want it handling config transactions itself)
<marcan>
that's how we did the ps4 hack
<rqou>
iirc the only required algo is rsa-md5
<marcan>
lol
<rqou>
and it's full of the classic "every scheme ever is optional"
<rqou>
DSA-MD5-GOST? sure!
<rqou>
IDEA? CAMELLIA? all ok!
<rqou>
hmm maybe not these specific algos, but you get the idea
<rqou>
it's not the modern approach of "RSA/X25519 with AES-GCM/ChaCha20-Poly1305 and no other options"
<rqou>
so much crapto everywhere
<sorear>
roughly how mad at you do east asian contries get when you do that?
<rqou>
er, what?
<whitequark>
awygle: yeah this seems to have owned
<sorear>
rqou: if you try to sell something in (say) south korea and it doesn't support (say) SEED
<digshadow>
rqou: we may reach critical mass on tl866 way before I thought we would. There's been a surprising amount of interest in the project
<cr1901_modern>
it's like cats attracted to chicken dinner
<cr1901_modern>
where "talking about the tl866" is a chicken dinner
<rqou>
sorear: i have no idea
<rqou>
china doesn't particularly have their own pet crypto algo, and i don't know about JP/KR
<rqou>
(or RU)
<whitequark>
RU has GOST
<whitequark>
but it's not really widely used
<whitequark>
also, it's funny how the name of the standards org became the name of the crypto algorithm in anglosphere
<rqou>
for a while somebody in mozilla or something was pushing CAMELLIA
<whitequark>
it's like calling a crypto algorithm "NEMA"
<rqou>
you mean like plugs? :∆
<rqou>
:P
<sorear>
whitequark: don't tell me you've never heard someone talk about "ISO files"
<q3k>
whitequark: the joke is that the 3d printing community talks about 'nema motors'? :P
<q3k>
or that.
<whitequark>
sorear: hah.
<sorear>
rqou: what do you make of the addition of SM3 and SM4 to ARMv8.4
<sorear>
this has dedicated instructions in armv8.4
<rqou>
huh
<rqou>
i guess the silicon required must have been small
<digshadow>
awygle: 1) support chips that aren't supported with vendor firmware 2) additional control for specialized applications
<rqou>
in my personal experience I've never seen those algorithms deployed
<rqou>
ime everybody just uses aes ccmp like a normal person
<cr1901_modern>
awygle: It's essentially a swiss army knife of 40 pins in a nice form factor, with lots of voltages. Which with you can do w/ as you please w/o risk of blowing stuff up.
<q3k>
rqou: but I like my weird obscure national crypto standards
<rqou>
no
<rqou>
bad
<rqou>
wrong
<q3k>
rqou: I want the freedom to choose who backdoors me dammit
<q3k>
rqou: and the freedom to use xorcryption, no backdoors there!
<awygle>
digshadow: cr1901_modern: cool, thanks
<rqou>
q3k: you can do that much more easily: Cisco - US gov, probably IL gov; Huawei - CN gov, US gov, possibly IL gov
<q3k>
well, cisco is actually quite clear on this
<q3k>
if you look at IOS features, you'll find one called 'lawful interception' :)
<q3k>
also, that's why I run Debian&BIRD on my routers, so that everyone with a Linux 0day can pwn me
<rqou>
oh everybody has that feature
<awygle>
i'm guessing IL means Israel but i keep reading Illinois
<q3k>
awygle: just don't tell the illinois nazis
* awygle
wishes that was a joke...
<q3k>
right, I was going to say, at this point that blues brothers reference probably stoppped being appropriate
<awygle>
wildly off-topic: has anyone used or taken a look at Matrix (the "irc replacement" protocol)?
<q3k>
oh what a timeline we live in
<awygle>
q3k: i mean "a half a pack of cigarettes" sounds anachronistic too, so it's not all bad
<rqou>
oh i just mentioned Israel because they seem to be really really good at pwning things
<sorear>
awygle: i know a dozen or so people who use it
<rqou>
and "everybody knows" that equipment is pwned by the country the companies are in
<awygle>
sorear: thoughts? is it a Good Protocol, or a Bad Protocol?
<rqou>
and the Snowden leaks revealed that the NSA pwned huaweo equipment
<rqou>
so use huawei for the maximum backdooring? :∆
<rqou>
:P
<rqou>
(says someone who is currently using a Huawei phone)
<awygle>
i really need to get off of Mister Flagship's Wild Ride when it comes to phones
<qu1j0t3>
what
<awygle>
i keep buying Galaxy S(N+1)'s
<awygle>
every couple years
<awygle>
i should get a much cheaper phone, i would probably be happier
<rqou>
i mean, I'm currently using a flagship
<rqou>
for the SEA market :P
diadatp has quit [Read error: Connection reset by peer]
<ZipCPU>
rqou: You worked with the greenpak devices, right?
<rqou>
vaguely?
<rqou>
i didn't write most of the code
<ZipCPU>
Just asking 'cause someone in ##fpga was asking if anyone had experience with them--not necessarily open source experience, but just experience.
<rqou>
yes, i have experience
<rqou>
but only testing stuff for azonenberg
<rqou>
never in "a real product" or anything like that
<ZipCPU>
Would you like to talk to him in ##fpga?
diadatp has joined ##openfpga
<whitequark>
awygle: oh btw
<whitequark>
the target port lines ended up over all three IO banks
<awygle>
hm. that is a bit of a sad. i think our power still works out though?
<whitequark>
why is it sad?
<whitequark>
IO bank 0 has 17 pins... but three of them are only open-drain
<awygle>
yeah it's not actually a big deal
<whitequark>
I stuffed 14 target port lines into bank 0
<whitequark>
two more go to 1 and 2
<awygle>
it used to be a bad thing but then we changed to using level shifters
<awygle>
so we're cool
<whitequark>
what I meant is
<whitequark>
we couldn't do this board without level shifters at all
<awygle>
yes
<awygle>
i'm up to speed
<whitequark>
k sorry
<whitequark>
it's just that i just realized it
<awygle>
na it was me being slow :)
<awygle>
(or more charitably focusing on $ACTUAL_JOB)
diadatp has quit [Ping timeout: 276 seconds]
<whitequark>
azonenberg: million dollar question
<whitequark>
how do I route FPGA Vcore
<awygle>
lol
<whitequark>
it's just two pins at 1V2 that isn't used anywhere else
<azonenberg>
whitequark: i'd just do a bit fat bus from those pinsi to the regulator
<azonenberg>
put your core decoupling at thise pins and bigger caps further back toward the reg