<awygle>
azonenberg_work: I got those crazy chips working. Thanks again for the PLL help the other day
<rqou>
can you say what chip it is? :P
<awygle>
Several different kinds of UFS chips
<rqou>
wtf why do we need yet another flash memory interface?
<awygle>
I wish I had a satisfying conclusion to the story but it's basically just "new standards have not been vetted and vagueness in standards is bad"
<awygle>
rqou: why did we need SCSI instead of IDE
<awygle>
It's the same transition
pointfree1 has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
pie_ has joined ##openfpga
jarhab[m] has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
digshadow has quit [Ping timeout: 240 seconds]
<lain>
the scsi specs are so well-written
<lain>
everyone involved in authoring specs should be forced to read them and understand why they are good
<rqou>
arrgh why does every single arm soc i use have slow as shit IO performance?
<rqou>
the tegra x1 might be an exception
<azonenberg_work>
rqou: matthiasm in ##fpga a while ago was complaining about io performance on i.mx... 6 i think
<azonenberg_work>
i like FPGAs, where i can easily run every one of 400 GPIOs at 500 MT/s simultaneously :p
<azonenberg_work>
i dont mind using a MCU for control applications but they should stay the heck out of the datapath
ZipCPU|Laptop has quit [Ping timeout: 255 seconds]
<balrog>
azonenberg_work: it wasn't a problem when I used an I.mx6 as a primary server
<balrog>
:D
<azonenberg_work>
balrog: i think the GPIO was his main problem
<balrog>
oh.
<balrog>
MCUs aren't well suited for GPIO
<rqou>
no, it's the SD interface that's being slow as shit usually
<azonenberg_work>
exactly, but apparently this was uniquely bad
<balrog>
unless they're specialized for that (like the TI PRUs)
<rqou>
which makes the whole system feel slow
<azonenberg_work>
you couldn't even create an array of values and DMA them to ram
<azonenberg_work>
to GPIO*(
<azonenberg_work>
iirc
<azonenberg_work>
or maybe you could but it didnt work well? i just remember him complaining lo
<azonenberg_work>
And, unless cost of the final system is a primary optimization goal
<azonenberg_work>
i think i will stick with FPGAs for most/all of my projects going forward
<azonenberg_work>
So much easier to do bit twiddling and precise timing
<azonenberg_work>
and parallelism
<azonenberg_work>
And keep things reliable even if parts of the system fail
<balrog>
I'd like to mess with PSoC more :D
<azonenberg_work>
Which reminds me i need to get my hands on some ice40s
<azonenberg_work>
psoc looks nice
<balrog>
PSoC 5LP boards are $10 each and I have a whole box of them here
<azonenberg_work>
What would be even better is an in-between soc
<rqou>
i fun "soc" i'm trying to play with is implied in the photo i linked earlier :P
<rqou>
although this is probably going to be extremely painful due to no good debugging interfaces
<azonenberg_work>
Something with say a STM32F7 class CPU bolted to an xc7s6
<azonenberg_work>
or something
<azonenberg_work>
And 100% softcore peripherals
<azonenberg_work>
I feel like psoc is a little too small and zynq is overkill for a lot of applications
<azonenberg_work>
of course most companies will just throw a zynq down so their engineer can have the convenience of full linux :p
<balrog>
Pretty sure PSoC is bigger than silego stuff
<azonenberg_work>
Yes, it is
<azonenberg_work>
My interest in silego was mostly b/c the published bitstream
<balrog>
And dynamically reconfigurable RTL would be fun
<azonenberg_work>
Plus the fun of characterizing it :p
<azonenberg_work>
If we could fit a PAR into the CPU on a psoc, that would be pretty cool
<balrog>
I think that’s what pointfree is finding attractive about it
<azonenberg_work>
Yeah
<azonenberg_work>
I haven't yet needed to play a ton with reconfig
<azonenberg_work>
the main thing i've used it for so far is my logic analyzer
<azonenberg_work>
and that was bypassing the whole vendor PR flow and just loading SRLC32s with truth tables
<balrog>
Hah.
<azonenberg_work>
But i did this for a reason
<azonenberg_work>
i wanted to dynamically load new triggers at run time
<azonenberg_work>
and not lose state elsewhere on the FPGA
<azonenberg_work>
and for a chipscope-type tool you dont want to force a recompile to change triggers
<balrog>
On the PSoC there’s 256K flash, 64K RAM
<azonenberg_work>
We could probably fit something useful in there
<azonenberg_work>
honestly, i'm excited by some of the new PIC32s with DDR2 support
<azonenberg_work>
i feel like those would be great UI coprocessors for embedded gizmos
<azonenberg_work>
have the FPGA focus on datapath while the PIC runs the GUI
<azonenberg_work>
they have basic 2D GPUs in them too
<balrog>
The biggest problem with PSoC seems to have been weak documentation for a complex datapath design
<azonenberg_work>
I am probably gonna use one of those pics for my signal generator project (whenever that happens)
GenTooMan has quit [Quit: Leaving]
digshadow has joined ##openfpga
ZipCPU|Laptop has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<pointfree>
So the cypress analog coprocessor actually contains *fewer* analog hardips than the psoc 5lp. No hard mixers, filters, etc. You are supposed to implement those yourself in their analog fabric.
<azonenberg_work>
lol oh?
<pointfree>
Also, Cypress PSoC Creator does not yet support all the features of the analog coprocessor -- the hardware is ahead of the software.
<azonenberg_work>
lool
<pointfree>
I was hoping to use the analog coprocessor as a coprocessor with the psoc6 but I guess the psoc5lp and psoc6 effectively have more analog features than the analog coprocessor at the moment.
<pointfree>
I do like that they passed over more hardips for more flexibility for a change.
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<cyrozap>
Good news: I have the PSoC 5LP macrocells, PLDs, and the non-datapath parts of the UDBs modeled.
<cyrozap>
Bad news: When I pass the Verilog a valid config bitstream and run it through Yosys, Yosis decides the whole thing is a NOP :P
<cyrozap>
So I've probably messed something up somewhere, but I don
<cyrozap>
don't know where exactly.
<azonenberg_work>
Lol
<azonenberg_work>
I/O?
<azonenberg_work>
If you bork that then everything else is optimized out
<cyrozap>
I/O looks good, I think. When I flatten the design the right config bits go to the macrocells.
<cyrozap>
And I'm pretty sure I have the macrocells done right.
<cyrozap>
The UDB moduless pretty much just instantiate the PLDs.
<pointfree>
Good news: I have the routing fabric connectivity done (in tabular format)
<cyrozap>
The PLDs are where the complexity lies, so maybe that's what I borked? But it looks fine when I run it through the synthesis script...
<cyrozap>
pointfree: Yay!
<pointfree>
:)
<cyrozap>
Wait, so it that just external I/O? i.e., the DSI?
* cyrozap
is rusty on everything outside of the UDBs
<azonenberg_work>
cyrozap: well you're still making good progress
<pointfree>
cyrozap: Those registers and bits in the diagram are the nodes. Having the connectivity in tabular format means we now have the edges between those nodes.
<azonenberg_work>
i'm gonna add a shout-out to you guys in my talk next week
<azonenberg_work>
as another architecture with support in progress
<pointfree>
azonenberg_work: Thanks!
<azonenberg_work>
pointfree / cyrozap: how do you want to be credited?
<azonenberg_work>
your handles here? real names? (i forget what they are)
<cr1901_modern>
What are "real names"?
<azonenberg_work>
cr1901_modern: Meatspace names
<azonenberg_work>
:p
<cr1901_modern>
Well you gave a serious answer... In my mind I'm hilarious.
<pointfree>
azonenberg_work: Andreas Bernhard Wagner (real name) pointfree (irc nick)
<azonenberg_work>
pointfree: any institution you want to indicate affiliation with or no?
<azonenberg_work>
cyrozap: what about you?
<pointfree>
azonenberg_work: I'm not affiliated with any institution right now
<azonenberg_work>
OK
<pointfree>
I only know cyrozap's real name from the openocd commit log
<azonenberg_work>
yeah i know who he is but i dont know if he wants to be identified publicly with the effort or not
<azonenberg_work>
In case you're wondering the talk is going to be presented to Christoph Paar's research group at RU Bochum, plus a class they're teaching on hardware security
<azonenberg_work>
Pretty cool being invited to give a talk by none other than the founding father of CHES
<cyrozap>
azonenberg_work: I guess you can use my IRL name plus handle like you've done for pointfree.
<azonenberg_work>
Can you spell your IRL name for me here so i don't get it wrong? :p
<cyrozap>
azonenberg_work: I'd prefer if you'd just look at the copyright line for any of my GitHub projects :P
<cyrozap>
I kind of get weirded out using my real name in places where I'd normally use my handle, and vice-versa. Not really sure why.
<cyrozap>
The association between the two isn't a secret, though.
<azonenberg_work>
cyrozap: So you want just the handle? or what
<azonenberg_work>
Or you just dont want your name in logs here
<cyrozap>
The latter :P
<azonenberg_work>
ah ok
<azonenberg_work>
I have about 3 levels of anonymity
<azonenberg_work>
First, if i actively want to be found, i use azonenberg
<azonenberg_work>
it's shorter than my full name, doesnt have whitespace, etc but is also stupid-easy to google to me
<azonenberg_work>
Then i have one nick i've used since i was like 13 that i don't actively advertise as "me" but also is likely not hard to link to me
<azonenberg_work>
That i use for things where i want some casual separation to maintain professional decorum etc, but i really don't care that much
<azonenberg_work>
I used it for my online dating profile before i met $WIFE for example
<azonenberg_work>
For anything more interesting, i generate a fictional name from a table of first and last names, pick something based on that and maybe some random numbers
<azonenberg_work>
like jsmith123
<azonenberg_work>
only use it in a fresh VM with no cookies or anything that could be traced back to me easily
<azonenberg_work>
And possibly bounce through some intermediaries to obscure the IP, depending on how paranoid i feel that day and whether i'm trying to hide from the server itself or only readers of whatever i wrote
<cyrozap>
jsmith123 is a 1337 h4x0r who hides behind 7 proxies, got it
<cyrozap>
;)
<pointfree>
I've been using a separate identity for each topic as needed. Mostly to avoid boring people who are interested in one topic but not the other.
<azonenberg_work>
pointfree: yeah i dont do topic compartmentalizations
<azonenberg_work>
I do either real name, mild pseudonym, or fully siloed identities for each use case
<whitequark>
I find it weird that people think their name on ID is "real name"
<whitequark>
my real name is "whitequark" regardless of what a few states think about it
<whitequark>
it's even easier to pronounce
<azonenberg_work>
Lol
<azonenberg_work>
Yeah, its funny when you meet someone in meatspace and you're not quite sure what to call thenm
<azonenberg_work>
since you know them better by their handle than their legal name, if you even know it at all
<whitequark>
like literally just call me "whitequark" or "quark" or "quarky" if you want to date me or w/e
<azonenberg_work>
When i was in HK sebastian referred to you by your legal first name and i was like "who's that?"
<azonenberg_work>
lain goes by lain in meatspace too
<whitequark>
yeah, I'm changing that anyway soon
<cr1901_modern>
to W. Quark?
<whitequark>
not really, some other boring-sounding name
<whitequark>
haven't decided which
<whitequark>
literally the only criterion is "boring-sounding vaguely europeanish"
<whitequark>
the more boring, the better
<azonenberg_work>
whitequark: lol
<azonenberg_work>
You remind me of a discussion i had with somebody earlier today
<azonenberg_work>
hypothesizing that @swiftonsecurity
<azonenberg_work>
is actually a random sysadmin who is named Taylor Swift and has no relation to the singer
<azonenberg_work>
and is simply the victim of an unfortunate namespace collision
<whitequark>
I know who @swiftonsecurity is
<cr1901_modern>
swiftonsecurity's identity is _not_ that difficult to figure out
<jn__>
pie_: i came up with the term "dynamic harvard architecture" a while ago :)
<pie_>
well some kind of "dynamic harvard" :P but thats like saying apples are oranges just different
<jn__>
pointfree: interesting
<pie_>
jn__, lol great minds think alike
<pie_>
:PPP
<pie_>
hm, googleing data execution prevention harvard doesnt yield a lot of immediately relevant links, but the terms used might just be different in context. anyway, this looks fun https://arxiv.org/abs/0901.3482 ""
<pie_>
* Code injection attacks on harvard-architecture devices
* jn__
faintly remembers an article by Travis Goodspeed about ROP on MSP430
<jn__>
i mean, how would you "inject code" on a harvard machine? ROP comes to mind, but if all you do is ROP, you don't inject machine code. You could overwrite some flash where the code is stored, but that might be pointless because ROP might be powerful enough for what you're trying to do…
<jn__>
so maybe i misunderstood the term "code injection" because i didn't look it up, or it just isn't that useful
<mtp>
unrelated-ish
<mtp>
the AT&T #1 ESS (phone switch CPU) instruction format had a Branch Allowed flag for each instruction
<mtp>
and the assembler would compute acceptable targets for jumps as it was doing instruction layout and set that flag on all the targets
<mtp>
so if you managed to jump into data it would immediately throw
<mtp>
and you couldn't do ROP as easily
<pie_>
cool
<jn__>
oh, a flag for acceptable jump *targets*, that's pretty neat
nrossi has quit [Quit: Connection closed for inactivity]
* qu1j0t3
actually hasn't seen that before. hi mtp
<gruetzkopf>
siemens EWS[A|D] and Hicom300 use 80x86 and m68k, i own 386-based up to k6-2 based
<cyrozap>
pointfree: No, I modeled literally every other part of the UDB *except* for those things :P
<cyrozap>
pointfree: I just have a UDB top module with a config ram constant and a generate block for the PLDs.
<cyrozap>
pointfree: I'll push the code eventually, just need to tidy things up a bit.
<balrog>
cyrozap: AVR is modified Harvard, so you can read data from program memory too
<pointfree>
cyrozap: no hurry. I just wanted to avoid duplicating work. I still haven't uploaded the connectivity graph.
<pointfree>
The only part of the UDB contents that I know how to use is the PLD AND and OR array.
<pointfree>
I forgot about the clocking and reset blocks also in the UDB's.
pie_ has quit [Ping timeout: 260 seconds]
<awygle>
Anybody know whether a switch will pass traffic on the 169.254.x.x link local subnet?
<awygle>
I know routers don't and I assume dumb hubs do but idk about switches
<azonenberg_work>
awygle: Switches work with mac addresses exclusively
<azonenberg_work>
They don't touch IPs
<awygle>
azonenberg_work: I would typically call an L2 device a hub
<azonenberg_work>
No
<azonenberg_work>
A hub forwards anything coming in one port out every other port
<azonenberg_work>
its just a passive repeater
digshadow has joined ##openfpga
<azonenberg_work>
a switch learns mac addresses and forwards packets only to the port they live on
<azonenberg_work>
or, if it doesnt know the mac, everyone
<azonenberg_work>
(reverting to unicast once they get a reply back from the target mac)
<awygle>
Surely layer 3 switches exist though? I've definitely seen that term
<azonenberg_work>
Yes
<azonenberg_work>
A layer 3 switch is a switch with a bit of routing bolted in
<azonenberg_work>
basically it routes packets between vlans and often does basic firewalling with ACLs
<azonenberg_work>
If it looks at anything above the Ethernet II header, it's not a layer 2 switch
<azonenberg_work>
it's a switch plus other stuff
<azonenberg_work>
Many products marketed as switches are more than switches
<azonenberg_work>
in the same way a typical "wireless router" is actually a switch, router, and wifi AP bolted together
<awygle>
Okay, so will a layer 3 switch pass link local traffic?
<azonenberg_work>
Not across subnets, but within one vlan yes
<azonenberg_work>
Within one vlan a layer-3 switch is still just looking at MACs
<awygle>
Okay so as long as the 169.254.x.x subnet isn't split into multiple vlans
<awygle>
Thanks
teepee has quit [Ping timeout: 260 seconds]
teepee has joined ##openfpga
GenTooMan has joined ##openfpga
Bicyclidine is now known as Bike
<rqou>
damn, .xxx domains are expensive
<rqou>
gotta have than dns pr0n though :P
<rqou>
(thanks lain)
<rqou>
azonenberg_work: so am i weird in that i'm literally running _just_ a wireless AP?
<lain>
:D
<azonenberg_work>
I actually do that
<azonenberg_work>
i think mine has router capability, but i'm bridging the wifi to one of my vlans without routing
<rqou>
mine actually does multiple vlans (thanks meraki)
<azonenberg_work>
Which is where my crazy idea of the 802.11 SFP came in :p
user10032 has joined ##openfpga
<rqou>
azonenberg_work: you should go and buy silicon.xxx and make it redirect to the siliconpr0n archive :P
<azonenberg_work>
I have silicon.re and hardware.re
<azonenberg_work>
Just need to find uses for them
<awygle>
I am a big fan of the 802.11 SFP idea
<rqou>
oh wait, silicon.xxx isn't available
<rqou>
:(
<rqou>
silicon.porn apparently is (thanks gTLDs!)
<azonenberg_work>
rqou: lol
<azonenberg_work>
awygle: care to find a chipset?
<azonenberg_work>
people are saying esp32 is too slow
<awygle>
azonenberg_work: what's your target bw?
<azonenberg_work>
Is there anything faster you can do with just one antenna?
<azonenberg_work>
(limited by mechanical constraints)
<azonenberg_work>
Alternative, have multiple (say) MMCX connectors on the front then run extension cables from those out to antennas elsewhere
<azonenberg_work>
You could fit at least two MMCX's on a SFP
<azonenberg_work>
But they'd be pretty close so shielding could be a concern
<gruetzkopf>
i run most categories of IEEE 802 networking equipment
<gruetzkopf>
including 16M tokenring
<rqou>
um, you have seen the really silly looking coax sdi sfps, right?
<gruetzkopf>
SDI scramler :D
<gruetzkopf>
10/10 fail
<rqou>
SDI as a whole
<rqou>
10/10 fail
<azonenberg_work>
If i was ever going to do anything involving video
<azonenberg_work>
it would be UDP over 10gbase-R
<azonenberg_work>
using maybe VP8 codec?
<awygle>
VP9 has been out for a while
<azonenberg_work>
ok fine vp9 then :p
<azonenberg_work>
You get the point
<awygle>
2x mmcx would probably be fine
<rqou>
or just uncompressed video packed into udp+jumbo frames?
<azonenberg_work>
rqou: uncompressed video is pretty bulky
<azonenberg_work>
if i could get away with one gtx instead of a dozen i'd do it
<azonenberg_work>
But it all depends on how far i had to move it and how high res
<azonenberg_work>
i'd do udp + normal frame uncompressed
<azonenberg_work>
for say 720p30
<rqou>
you can do it easily for up to 1080p60
<rqou>
which is about 3gbps
<rqou>
iirc mithro got it working over usb3 even
<azonenberg_work>
well i was assuming i'd have multiple feeds
<azonenberg_work>
and so three 1080p60 feeds would saturate 10ge after protocol overhead
<azonenberg_work>
give or take a bit
<azonenberg_work>
at that point i'd start compressing and/or dialing back framerates
<rqou>
i guess it depends what you're trying to do
<azonenberg_work>
for a security camera 10-20fps is probably fine
<rqou>
meanwhile i want "just record my one desktop/other-device without stupid errors goddammit"
<awygle>
It feels like there's very little reason not to use at least lossless compression
<rqou>
right, but if you do that you can end up dropping frames at times
<azonenberg_work>
Not if you can set statistical bounds on the max entropy of a frame
<rqou>
but that can never be less than 3gbps at worst
<azonenberg_work>
for example an image sensor may not be capable of producing a pure B&W checkerboard
<azonenberg_work>
there may be inherent coupling between pixels
<azonenberg_work>
Your sensor may not be RGB24
<rqou>
e.g. "cat /dev/urandom > /dev/fb" (not quite like this, but you get the idea :P )
<azonenberg_work>
it may be 8-bit Bayer
<azonenberg_work>
in which case your entropy just went down by a factor of three
<azonenberg_work>
i.e. 1 Gbps max per frame
<azonenberg_work>
per feed*
<rqou>
i can see this being useful for a camera system
<rqou>
but you still have to prepare for a troll like me plugging in a rng into your hdmi input :P
<azonenberg_work>
My point being, lossless compression cannot go below the entropy limit of the data in the general worst case
<azonenberg_work>
But there may be statistical bounds on max entropy of your signal source
<rqou>
apparently "traditional" codecs aren't even nearly this good
<azonenberg_work>
that are far below the shannon limit of the frame
<rqou>
supposedly you can break them by just crashing a retro vidya and trying to compress the resulting tile spew
<rqou>
which is extra hilarious because the tile spew by construction has quite low entropy
<azonenberg_work>
Yes but most codecs these days work on small chunks of the image
<azonenberg_work>
mpeg for example i think is based on DCTs of 8x8 pixel grids just like jpeg
<azonenberg_work>
but i think they do delta coding from the previous frame or something
<azonenberg_work>
i dont know the specifics but i know a lot are 8x8 blocks with fourier based coding
<azonenberg_work>
Because i see ringing artifacts along edges in heavily compressed videos
<azonenberg_work>
And they stop at 8x8 pixel boundaries
<azonenberg_work>
and i know how jpeg works so...
<rqou>
i thought everyone moved off of DCTs to different fourier-like orthogonal bases?
<azonenberg_work>
No idea, i know the older MPEG etc were DCT based
<azonenberg_work>
i dont know h.264 etc
<azonenberg_work>
JPEG is the only thing i've actually implemented
<rqou>
apparently h.264 does "something" with the DCT residuals so that you get fewer ringing artifacts
<rqou>
and some other part of it uses a hadamard transform instead
<rqou>
imho that's not the hard part about "AV stuff" though
<rqou>
imho the math is pretty straightforward (at least if you went to a $FANCY_SCHOOL and took signals&systems) but all of the weird bugs and legacy quirks are the hard part
<rqou>
azonenberg_work: can you imagine a bug report like: "after <foobar update>, i can no longer play my pirated JAV collection that was originally on VHS tape, then got digitized with some JP-only hardware/software, then made its way onto a *tube at some point, then got ripped, and finally got repacked into a .mkv once it reached 'the western internet'"
<rqou>
:P :P :P
m_w has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 255 seconds]
<awygle>
azonenberg_work: TI has a wifi chipset called WiLink that's supposed to do 100 Mbps UDP throughput in 2x2 MIMO
<rqou>
does it have a firmware blob?
<awygle>
rqou: looks like yes
<awygle>
Along with a license that says "don't reverse this, we don't have to give you source, but and if we give you source you can only use it on our stuff"
<rqou>
that part is pretty typical
<awygle>
Yeah
<awygle>
Is there any wifi chipset that doesn't need a firmware blob?