X-Scale has quit [Ping timeout: 256 seconds]
m_t has quit [Quit: Leaving]
X-Scale has joined ##openfpga
unixb0y has quit [Ping timeout: 244 seconds]
unixb0y has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work> o/ rqou
<azonenberg_work> Bouncing around and tethering off my phone since the wifi AP is now in a box
<rqou> what
<rqou> you're just as bad at packing as me :P
<azonenberg_work> The movers came and left
<azonenberg_work> all the big stuff is gone
<azonenberg_work> we're loading up the little tidbits
<rqou> see, i did it the opposite way
<rqou> but my destination wasn't under construction, so ymmv
<rqou> anyways, i wanted to ask you
<rqou> azonenberg_work: do you know of any fpgas that have "fracturable" block ram or DSPs?
<azonenberg_work> spartan6 bram are 18 Kb TDP fracturable into 9Kb SDP
<azonenberg_work> 7 series are 36 Kb TDP fracturable into 18 Kb SDP
<azonenberg_work> Other than that, dont know
<rqou> hmm ok
<rqou> azonenberg_work: do you have any links to articles or other resources on writing "modern" multithreaded code? focusing on the practical "here is how to structure your program" side, not the comp. arch. "this is a memory barrier" side
<rqou> $FANCY_SCHOOL has decent coverage of the latter, not so much of the former
<rqou> or at least i didn't focus on it
wpwrak has quit [Ping timeout: 256 seconds]
azonenberg_work has quit [Ping timeout: 248 seconds]
wpwrak has joined ##openfpga
<awygle> whitequark: how did we come to the number of decoupling caps we're using?
rohitksingh_work has joined ##openfpga
<whitequark> awygle: we asked azonenberg
<awygle> oops :p
<whitequark> one small and one large cap per IC
<rqou> lol
<awygle> so what it looks like we have is 2 0.1 uF caps per pin, and then one larger cap per IC
<awygle> is that right?
<whitequark> two?
<whitequark> should be one
<rqou> um, that doesn't match azonenberg's usual style
<rqou> i thought azonenberg would usually use 0.47/4.7?
<whitequark> too expensive with the MLCC shortage
<awygle> rqou: yeah but we had 0.1s for some reason, ,or 0.47 was sold out
<awygle> iirc azonenberg only uses .47 because it's the biggest easily available
<rqou> biggest capacitance in the given area
<awygle> right
<awygle> ... is the ice40up pinout just gone from the lattice website?
<awygle> oh no it's because they split it out. nvm.
<whitequark> ha, nextpnr can't route a single glasgow design
<rqou> wait wtf
<rqou> whitequark: how do you have access to nextpnr
<whitequark> i asked?
<rqou> W T F
<rqou> the entire symbiflow team deserves to have large objects shoved up their rectums
<sorear> how much of nextpnr is *not* going to be public tomorrow?
<sorear> er, Wednesday, I can't calender
<whitequark> ok, got it to route
<sorear> also is your beef with siliconpr0n at all public?
<whitequark> daveshah: yeah you're right, without SB_CARRY handling it is not a win over arachne
<whitequark> I think in the designs where I can't pass timing with arachne I won't pass it with nextpnr either in spite of it being timing-driven
<mithro> whitequark: Do you have an example of a design? I'd be interested in trying it with VPR
<mithro> daveshah: So, it seems that specifying a pack pattern for the carry chain just seems to make it not work properly, when I remove them vpr seems to do the right thing...
<whitequark> clone the glasgow repo, then `glasgow run uart`
<mithro> whitequark: I assume you haven't got any timing constraints on the design currently?
<mithro> whitequark: Using a single clock domain too?
<whitequark> yes
<sorear> are carry chains just something that vpr never needed before for research and never got added?
<rqou> vpr is just in general shitty
<rqou> it's optimized for researchers to experiment with (oversimplified) architectures
<rqou> not for actual production use
<mithro> sorear: They have carry chain support but it's not well documented compared to most of it's other stuff
<mithro> sorear: And it actually looks like they might not even need the special casing any more due to other improvements
<mithro> sorear: It also looks like they have looked at stuff which is more like Xilinx style carry chain
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/12a7b0f06aed...499a0b25a9ff
<openfpga-github> Glasgow/master 499a0b2 whitequark: applet: in assertBuilds(), leave build dir around if build fails.
<openfpga-github> Glasgow/master 967798b whitequark: target: use explicit SB_IO+SB_GB instead of SB_GB_IO.
<openfpga-github> Glasgow/master 1f4e443 whitequark: internal_test.TestRegisters: unbreak after 02f390bc.
<travis-ci> whitequark/Glasgow#16 (master - 499a0b2 : whitequark): The build passed.
<kc8apf> rqou: I was not impressed with VPR's codebase or architecture.
<kc8apf> rqou: for multithreading, are you asking about c++? If so, std::thread, std::atomic, and friends
<rqou> i'm asking about language-agnostic "design patterns" not specific APIs
<kc8apf> Ah.
<kc8apf> Not too much new.
<whitequark> ok, after more checking, I currently get about 1ns more out of the UP5K with nextpnr
<whitequark> that's... not too bad
<kc8apf> Design units of work to be independent chunks of state
<kc8apf> Decide on a work queuing strategy up front
<kc8apf> Hard to give general advice without knowing more about the problem
<kc8apf> Feel free to ping me with questions. Performance optimization was my job for many years
<kc8apf> I'm confused about this whole nextpnr thing. Isn't https://github.com/SymbiFlow/symbiflow-arch-defs open to the public?
<rqou> wut
<rqou> are you telling me that you aren't aware of what's actually going on?
<kc8apf> I haven't been involved for months.
<kc8apf> I left Google and only do FPGA stuff on the side
soylentyellow_ has joined ##openfpga
soylentyellow has quit [Ping timeout: 268 seconds]
azonenberg_work has joined ##openfpga
<rqou> o/ azonenberg_work \
soylentyellow_ has quit [Read error: Connection reset by peer]
soylentyellow has joined ##openfpga
<azonenberg_work> o/
<rqou> azonenberg_work: i got a tip for you, via fail0verflow and then via an anonymous hacker
<azonenberg_work> Fully moved out of the old house
<rqou> oh that was fast
<azonenberg_work> now in the hotel for the night
<azonenberg_work> Fast? lol
<rqou> i took like 4 weeks
<azonenberg_work> we've been carrying stuff over for weeks
<rqou> ah ok
<rqou> so similar then
<rqou> anyways
<azonenberg_work> we started moving boxes as soon as we bought it
<azonenberg_work> stopped when it smelled b/c of the demo
<rqou> see the "Defeating read protection" section at the very end
<azonenberg_work> once it was largely deconned, began moving more
<rqou> if you have time, you should try it on stm32
<azonenberg_work> $old_roommate was here a week ago doing construction and moving more stuff
<azonenberg_work> we had 3 truckloads with my friend's moving company fri-sat
<azonenberg_work> then today me and monochroma/lain did probably 8 carloads of other stuff
soylentyellow has quit [Read error: Connection reset by peer]
soylentyellow_ has joined ##openfpga
<azonenberg_work> rqou: i believe that stm32 does not clear ram on reset
<azonenberg_work> so cold boot attacks are definitely a thing
<rqou> it definitely does not
<rqou> i know about that issue already
<rqou> the new issue is about poking the Flash Patch and Breakpoint Unit
<azonenberg_work> yes
<rqou> we should try that trick against stm32
<azonenberg_work> whats funny is, i was just reading about the FPB while adding support to jtaghal
<azonenberg_work> i currently can detect its idcode
<rqou> i didn't even know about it lol
<azonenberg_work> but not actually use it for anything
<rqou> i just filed it under "stuff for the debugger that i don't need to touch"
<azonenberg_work> all i do is determine it exists
<azonenberg_work> that is definitely something to play with
<whitequark> rqou: i knew about it
<whitequark> because i made a debugger once
<whitequark> texane/stlik
<whitequark> *stlink
<rqou> wtf have you done _everything_ before?
<whitequark> lol
<rqou> is your entire life just a giant stack of yak shaving?
<whitequark> yes
<whitequark> yes it is
<sorear> whose isn't?
<azonenberg_work> I never made a debugger, but i made a custom gdbserver to support debug of a mips-ish CPU and its custom jtag protocol
<rqou> pic32?
<azonenberg_work> no, one of my softcores
<azonenberg_work> the goal was mips-elf-gcc compatibility
<rqou> did it support unaligned memory access? :P :P
<azonenberg_work> no, nor coprocessors or supervisor mode
<azonenberg_work> i redefined syscall to trap to antikernel noc send/recv
<rqou> ok, you didn't violate The Patent :P :P :P
<azonenberg_work> The Patent is also expired now
<rqou> yeah i figured
<azonenberg_work> I never implemented lwl/lwh because i saw no need to support unaligned access whatsoever
<daveshah> whitequark: carries in nextpnr are working better now
<azonenberg_work> rqou: also, http://paste.debian.net/hidden/f7fe07e2/
<azonenberg_work> Does this qualify as a debugger? :p
<daveshah> Everything will go public on 1st August
<azonenberg_work> this is the brand new shiny interactive shell for libjtaghal
<rqou> no
<daveshah> Including both iCE40 and ECP5
<daveshah> But ECP5 will be just LUTs, FFs and IOs really
<rqou> yeah well KinglerPAR is public now you fuckers
<azonenberg_work> rqou: why not?
<rqou> no breakpoints?
<azonenberg_work> i mean i can poke memory mapped sfrs to do breakpoints :P but yeah i didnt implement the ui for that yet
<azonenberg_work> But MEM-AP access works
<azonenberg_work> and you can read (but not write) cortex-m registers
<azonenberg_work> cortex-a support is less well developed
<rqou> is this intended to be a universal debug framework or only one for "serious" cores?
<rqou> e.g. afaik pic/avr breakpoints are "fun"
<azonenberg_work> its intended to be a shell for every features jtaghal supports
<azonenberg_work> jtaghal support is the limiting factor, not the ui right now
<azonenberg_work> for cortex-a that is
<rqou> so no ultra-gimped debug interfaces like debugwire
<azonenberg_work> i also have very limited discover-only suport for arm7tdmi
<azonenberg_work> i can tell its there and thats it
<azonenberg_work> And i do plan to support swd
<azonenberg_work> but we'll see after that
<rqou> afaik AVR is so gimped that adding a breakpoint requires erasing and reprogramming the flash
<rqou> so keep that in mind or something
soylentyellow__ has joined ##openfpga
gnufan has left ##openfpga [##openfpga]
soylentyellow_ has quit [Ping timeout: 244 seconds]
rqou has quit [Remote host closed the connection]
rqou has joined ##openfpga
<azonenberg_work> Lol
<azonenberg_work> Well for the moment the primary focus is stuff we see at $work often
<azonenberg_work> Which means arm
<azonenberg_work> And cortex-m is easier to support than cortex-a
<azonenberg_work> So that will be the main focus
<rqou> no 8051s anymore? :P
<azonenberg_work> (if you've ever read the armv7-a arch manual... @_@)
<azonenberg_work> armv7-m is more my style lol
<rqou> i've never looked at -a
<rqou> afaik it's a total disaster
<rqou> afaik -r is similar to what i used in "oldschool" arm chips, and -m is actually pretty nice
<azonenberg_work> docs seem to imply -r and -a are very similar
<azonenberg_work> stm32 is looking like a pretty good option for new low-end designs though
<sorear> re. "fracturable BRAMs" - several FPGAs have BRAMs which have two ports that can be used independently under some conditions
<azonenberg_work> as much as i want to love pic32, microchip is doing a great job of making it a pain :p
<azonenberg_work> things like dual row QFN or 144-TQFP as the only package options
<azonenberg_work> gimme a fscking bga
<azonenberg_work> pic32mx had a bga option, but no mmu
<sorear> stm32 and pic32 are both pretty close to mips as fare as the basic arch goes, right?
<daveshah> The ECP5 also has properly fracturable DSPs, e.g two 9x9 multiplier primitives or 1 18x18
<azonenberg_work> no, stm32 is arm based
<daveshah> So they are definitely something that should be supported in the future
<azonenberg_work> pic32 is mpis
<azonenberg_work> mips*
<azonenberg_work> pic32mx is a M4K with a fixed memory mapping
<azonenberg_work> pic32mz is a microaptiv with full virtual memory support
<rqou> azonenberg_work: btw did you run into this? https://twitter.com/whitequark/status/1023819477987811328
<sorear> most "weak simd" CPUs have "fracturable" multipliers that use the same multiplication array for e.g. 2 double multiplies or 4 single multiplies
<azonenberg_work> rqou: yes i did
<rqou> lolol
<azonenberg_work> most local stores had no .22 at all
<rqou> "thanks obama" :P :P :P
<azonenberg_work> if they did, they limited you to 1-2 boxes per day
<azonenberg_work> to ration it out and make sure more customers had a chance
<azonenberg_work> luckily WA isn't braindead and lets you mail order... it was significantly more expensive but at least i could get it
<azonenberg_work> Interestingly enough, trump's election had the opposite effect
<azonenberg_work> shares of e.g. smith & wesson tanked
<sorear> that sounds like the same effect
<azonenberg_work> the market had priced in the expected panic buying after a democrat win
<azonenberg_work> Which never happened
<azonenberg_work> so they corrected
<sorear> you don't get to call it the opposite effect just because the response is negative if the stimulus is also negative, slope is still positive
<azonenberg_work> What i meant was, it wasnt panic buying per se
<azonenberg_work> it was the expectation of it
<azonenberg_work> anyway the problem with the "obama's gonna take our guns" crowd is that they hoard ammo and make it impossible for sport shooters to find it when things like that happens :p
<azonenberg_work> Which leads to people like me stockpiling, because i never know when the next panic buy is going to result in me being unable to practice before a competition etc
<sorear> how continuous is analytic PnR? does a small change to the verilog still cause large and essentially random QoR changes?
<azonenberg_work> sorear: my experience with vivado is that it's continuous but with fairly high gain
mwk has quit [Ping timeout: 240 seconds]
<sorear> is vivado analytic or SA?
<azonenberg_work> Vivado is analytic
<azonenberg_work> ISE is SA i belive
mwk has joined ##openfpga
<rqou> i found a paper that claimed otherwise
<rqou> at least for virtex 5
<azonenberg_work> wait what
<azonenberg_work> they claimed ise was analytic?
<rqou> it may be incorrect
<sorear> are any of the currently supported products of {xilinx, altera, microchip, lattice} SA?
<rqou> define "currently supported"
<daveshah> Fairly certain all the Lattice stuff is SA
<sorear> you can buy a new chip which requires product X to program
<daveshah> It's whatever NeoCAD has in '95
<rqou> well, coolrunner-ii is still not NRND :P
<azonenberg_work> I consider all ise-only chips to be de facto NRND
<rqou> although my algorithm for that would not be considered SA
<azonenberg_work> that said, i also know of at least one firm working on a new spartan6 design
<daveshah> OTOH we were told by someone who had worked in the industry for many years that analytical placement didn't bring that much benefit in the end
<azonenberg_work> b/c s7 isnt yet available in the low-gate-count size they wanted, and s6 was chepaer than a low end a7
<daveshah> Compared to a well tuned SA
<rqou> (my algorithm for it is based on iterative improvement, but does not have the SA "temperature" adjustment)
<sorear> i'm idly curious if a fpga compiler continuous enough to make binary patches work is even theoretically possible
<rqou> altera has an "ECO mode"
<rqou> but afaict you get to manually patch things, by hand
<azonenberg_work> ise had "smartguide"
<azonenberg_work> that basically says, here's my netlist
<azonenberg_work> here's a previously par'd NCD from a very similar netlist
<azonenberg_work> use the existing placement and routing for whatever you can match up 1:1
<rqou> wait wut
<rqou> that in itself is np-hard
<rqou> or was it dumb and used e.g. the name of the wires?
<azonenberg_work> I believe it used net names
<azonenberg_work> since NCD has symbol names
<rqou> ah, so cheating :P
<mithro> Seems to be part of https://electron-lang.org/
<azonenberg_work> Also, it looks like the new ddr2-capable pic32s have bga package options
<rqou> wtf
<azonenberg_work> 169-ball 0.8mm though, so not oshpark friendly
<sorear> is ddr2 not nrnd
<azonenberg_work> has 32 MB of ddr2 internal to the package
<rqou> why are microcontrollers moving towards full AP levels of features?
<azonenberg_work> you can also get it with the ddr2 pins bonded out to an external bus but thats a 288-ball package
<rqou> e.g. the stm32h7 (and even f4/f7) can run linux
<azonenberg_work> same cpu die either way
<rqou> ooh that's actually reasonably neat
<azonenberg_work> i actually think thats a sweet spot for embedded systems because it eliminates a lot of the hassles of working with a full AP
<rqou> too bad it's a pic :P
<sorear> because the niche for super-limited stuff exists entirely in the IP core market?
<azonenberg_work> While still being pretty beefy
<azonenberg_work> The pic32 i'm looking at now is probably near wrt54g cpu performance?
<rqou> azonenberg_work: boot linux on it :P
<azonenberg_work> 200 MHz / 330 DMIPS
<rqou> yeah pretty much
<azonenberg_work> 12 bit 18 Msps ADC (wow, thats the fastest i've seen in a mcu)
<rqou> but if you don't bind NDAs you might as well use an atheros wifi soc in that case :P
<azonenberg_work> 2 MB of internal flash
<rqou> *mind
<azonenberg_work> 640 KB of SRAM plus 32 MB of wirebonded in-package DRAM
<rqou> also atheros wifi socs come in the worst packages
<azonenberg_work> Or, as i mentioned, up to 128 MB of off chip DDR2
<rqou> azonenberg_work: how do you feel about a dual-ring QFN :P
<azonenberg_work> An internal 2D GPU of some sort for LCD control
<azonenberg_work> 10/100 etherne
<azonenberg_work> And hardware crypto accelerator
<rqou> atheros wifi soc still better :P
<azonenberg_work> yes but ndas
<azonenberg_work> anyway my big complaint is that its not a batch fab friendly packag
<azonenberg_work> your only alternative is a whopping 176-pin TQFP
<azonenberg_work> But hey, bga is better than the old pic32 dual row qfn offering
<rqou> wait pic32 did that too?
<azonenberg_work> Yes
<azonenberg_work> they called it a VTLA but it was a dr-qfn
<azonenberg_work> and basically impossible to use without microvias
<rqou> why are all the MIPS people bad at things?
<azonenberg_work> even 3/3 traces wouldnt fan it out
<azonenberg_work> (i did the math)
<azonenberg_work> and lol good question
<azonenberg_work> interestingly enough there are no good 1mm pitch stm32s last i checked too
<azonenberg_work> 0.8 seems to be what all the cool mcus are using
<rqou> yeah it's not really intended for that
<azonenberg_work> my other complaint is that the ethernet isnt gigabit :p
<rqou> i don't think i've seen gigE on a microcontroller yet
<azonenberg_work> it has ddr2 400 support
<azonenberg_work> Which is more than enough b/w for gig-e
<azonenberg_work> But yeah i havent seen any yet
<daveshah> Apparently XMOS have some of their weird multicore mcus with GbE
<azonenberg_work> If i could get a sshd running on one of these
<azonenberg_work> it would be a serious alternative to the cortex-a8 + linux platform i was planning to use for my switch
<azonenberg_work> i'd much prefer a little mcu
<azonenberg_work> way easier to work with
<rqou> you can always add another fpga :P
<azonenberg_work> lool
<azonenberg_work> if i was gonna do that i'd throw in a zynq and run linux
<rqou> <troll> add a broadcom switch asic </troll>
* azonenberg_work runs away screaming
<rqou> they have some "whatever" cortex-a in the newer parts
<azonenberg_work> lool
<azonenberg_work> Anyway, i need some sleep
<azonenberg_work> running off my phone to tether so afk
<rqou> they have a pcie interface too
gnufan has joined ##openfpga
azonenberg_work has quit [Ping timeout: 240 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
massi has joined ##openfpga
ironsteel has joined ##openfpga
ondrej2 has joined ##openfpga
Patater has quit [Remote host closed the connection]
Patater has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 3 new commits to master: https://github.com/whitequark/Glasgow/compare/499a0b25a9ff...40a7f93b9b3a
<openfpga-github> Glasgow/master 40a7f93 whitequark: 0x19+1 is 0x1A, not 0x20, oops.
<openfpga-github> Glasgow/master 74d333a whitequark: Rename *Mock* to *Simulation* and split target/device packages.
<openfpga-github> Glasgow/master ca34c8e whitequark: gateware.i2c_regs: rename to registers, split I2C part off.
mumptai has joined ##openfpga
wpwrak has quit [Ping timeout: 260 seconds]
m_t has joined ##openfpga
ondrej2 has quit [Quit: Leaving]
ondrej2 has joined ##openfpga
ondrej2 has quit [Client Quit]
ondrej2 has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
<gruetzkopf> hmm, i have a stm32f103 which didn't spit out it's firmware when asking nicely with st-flash
<gruetzkopf> (as opposed to the nrf51802 in the same product, which did and also contains all the easily accessible interfaces (read BLE))
genii has joined ##openfpga
Bike has joined ##openfpga
rohitksingh has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
X-Scale has joined ##openfpga
azonenberg_work has joined ##openfpga
<florolf> azonenberg_work: you spoke fondly of SSP21. do you have access to the draft spec and/or any idea how the release process is progressing?
<azonenberg_work> I do have access to the draft spec
<azonenberg_work> Havent talked to them in a while and dont know what the release process is like
<azonenberg_work> i've been out of the con scene this year due to construction on the new house
<florolf> okay
azonenberg_work has quit [Ping timeout: 276 seconds]
<mithro> florolf: Heyo!
rohitksingh has joined ##openfpga
<florolf> mithro: hi
<gruetzkopf> if it's the SSP21 i'm thinking about, let's hope it's less "interesting" than DIN VDV V 0831-200 "RaSTA"
<gruetzkopf> (which is basically a TCP replacement for rail applications in germany)
<gruetzkopf> (constructed with state-of-the-art primitives such as CCITT-CRC16 and MD4!)
<florolf> so we're probably thinking of the same thing
<florolf> sounds much saner than your standard, though :p
<gruetzkopf> yes, much better
<gruetzkopf> (RaSTA tries to abstract unreliable links and multipathing and deciding which packet was good away from the user, and i have a few ideas how to troll it)
m_t has quit [Quit: Leaving]
<whitequark> gruetzkopf: holy shit MD4
<whitequark> can you break that on a napkin yet
<gruetzkopf> "but it's not meant for security"
<whitequark> " Since local
<whitequark> collision and message differences are improved, we can find a collision with complexity
<whitequark> less than 2 MD4 operations"
<whitequark> actually, yes.
<whitequark> you fucking can
<gruetzkopf> i'm so gonna kill the proof of safety for all modern computer-controlled signalboxes in germany :D
<whitequark> they actually managed to find -the- most broken hash function in existence
<whitequark> the next most broken is 2^6
<whitequark> MD2 is 2^64
<whitequark> amazing
<gruetzkopf> what, <2^1 is.. impressive :D
<whitequark> gruetzkopf: just to recheck, 0831-200 is still used, right?
<whitequark> when was it written?
<gruetzkopf> it's currently starting to be rolled out
<gruetzkopf> it's from 2015-06 iirc
<gruetzkopf> it's still in pre-normative state
<whitequark> amazing
<gruetzkopf> (i'd like it much better if german law treated rail systems like nuclear power plants, that is: no computers anywhere in safety-critical systems)
<gruetzkopf> (most features of modern interlocking systems were available in 1960s relay tech, ALL features are available in 1970s relay tech)
<gruetzkopf> and *both* are faster than the computer based systems and have far better ui
mumptai has quit [Quit: Verlassend]
<gruetzkopf> (the latest-gen-relay-only systems use some especially fun tricks to be faster than their predecessor)
<whitequark> what about e.g. hot box detection?
<whitequark> doesn't that use microcontrollers?
<whitequark> or at least something more complex than relays for driving sensors
<gruetzkopf> at least over here that was always a completely seperate system
<gruetzkopf> (yay, x.21 and x.25)
<whitequark> right, but isn't it "safety critical"?
<gruetzkopf> it's not "will immediately kill people" critical
<gruetzkopf> mostly relevant for freight trains over here, and there's quite a few of these systems deployed
<whitequark> ah I see
<gruetzkopf> i'd claim that prior to LED signal lamps being a thing, the relay based stuff drew less power than the computer stuff
<gruetzkopf> our room full of relays draws around 5A @ 60V idle
<whitequark> huh
* prpplague reads the log
<prpplague> gruetzkopf: that's interesting
<prpplague> gruetzkopf: i'd heard that the UK and Germany still used PO3000 relays in a bunch of their train switching
<gruetzkopf> The other big manufacturer still uses relays like that today
<gruetzkopf> In the interface between computers and outside world
<gruetzkopf> And also in their relay-only interlocking systems
digshadow has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
<azonenberg_work> awygle: around?
<awygle> azonenberg_work: yup, sup?
<azonenberg_work> So i was thinking more about the design i had for my switch brain board
<azonenberg_work> Plan was to use an xc7k160t in fbg484 as the switch fabric
<azonenberg_work> Then an osd3358 SiP as the ssh interface
<azonenberg_work> But i didnt have enough GPIOs, so i started thinking about throwing a little ftgb196 spartan7 on there
<azonenberg_work> But now i'm looking at $25.40 for the spartan7 plus $43.73 for the SoM is $69.13 (digikey q1 price) plus now i have pcb area for 3 big bgas
<sorear> How do you do moving block with relays?
<azonenberg_work> An xc7z010 in clg400 is $62.79
<azonenberg_work> plus a ddr2 chip or so
<daveshah> FYI, an ECP5 would probably be half the price of the Spartan 7
<azonenberg_work> It would let me go from a single a8 to dual a9's, and probably shrink the pcb footprint
<awygle> does an 010 have the 10g serdes? thought that was one of the artix zynqs
<azonenberg_work> It is an artix, and has no 10G
<azonenberg_work> this would not be replacing the kintex
<awygle> oh replacing the octavo and the spartan
<azonenberg_work> The choice is between kintex, sitara, spartan
<azonenberg_work> or kintex, zynq
<awygle> i getcha
<azonenberg_work> Basically moving the sshd and the io expander into one chip
<azonenberg_work> two totally separate functions, i probably wouldnt even be using the axi bus between the arm and the fpga at all
<azonenberg_work> The arm would be using a MIO uart to the kintex
<azonenberg_work> and the fpga would be using a few LVDS IOs to the kintex
<whitequark> $69.13, you gotta add a 29¢ part to it
<azonenberg_work> lol :p
<azonenberg_work> The bom cost might go up a touch because i'd need to throw a dram chip on there (which the octavo has integrated)
<azonenberg_work> and i'd need denser pcb design rules since 0.8mm bga vs 1mm and 1.27mm
<azonenberg_work> But honestly i'm paying for a 6L "real fab" board anyway
<azonenberg_work> going to 4/4 vs 5/5 is NBD
<azonenberg_work> And i think it would give a much neater design
<azonenberg_work> probably quite a bit less pcb area, comparable component cost
<awygle> yeah that's definitely a "dense rules" board regardless
<azonenberg_work> Exactly
<awygle> doesn't seem unreasonable
rohitksingh has quit [Quit: Leaving.]
<azonenberg_work> Plus it would give me an excuse to use a zynq in a project finally :p
<awygle> haha
<awygle> based on my current experiences at work you may regret it
digshadow has joined ##openfpga
<azonenberg_work> well if you notice, my design calls for the fpga and the arm to be totally independent
<azonenberg_work> and just colocated on one die
<whitequark> i've yet to hear anything good about zynq
<awygle> (note that those experiences are almost certainly our fault)
<azonenberg_work> So i dont see it being a problem
<whitequark> the most specific complaint i remember is the interface between it and fabric being slow and generally obnoxious
<azonenberg_work> well, thats a non issue for this application
<whitequark> so that you're actually better off with a softcore
<azonenberg_work> o_O
digshadow has quit [Client Quit]
<whitequark> wow, I crashed yosys
<azonenberg_work> whitequark: because in this application i'm going to have the arm be basically a ssh to uart bridge plus run a CLI that translates human readable commands to binary fpga register writes
<whitequark> why not implement ssh in gateware
<azonenberg_work> Then the fpga on the zynq will be doing things like power rail and reset sequencing for the line cards
<azonenberg_work> Because either way i would need the CLI to be on some kind of cpu
<daveshah> whitequark: well done, that means you win our daily 100btc prize
<whitequark> daveshah: gimme
<azonenberg_work> i am not going to implement readline in verilog
<azonenberg_work> i'm nuts, but not THAT nuts
<whitequark> azonenberg_work: i actually would
<awygle> azonenberg_work: coward :p
<azonenberg_work> ssh in fpga is plausible but i dont have the time for it now
<whitequark> in migen
<whitequark> i'm going to write a DSL in glasgow on top of migen that lets you define state machines for processing command streams
<whitequark> readline would be trivially expressible in terms of it
<whitequark> without the termcap database obviously
<azonenberg_work> what about an IOS-esque CLI?
<azonenberg_work> i mean it could be microcoded
<azonenberg_work> but i think C is a better language :p
<whitequark> ... I do not think C is a better language
<azonenberg_work> Ok fine, C++
<azonenberg_work> is what i was actually planning to use
<whitequark> I still don't agree lol
<azonenberg_work> throw a minimal linux kernel and a C++ binary plus openssh
<whitequark> ew, linux
<azonenberg_work> It will be on an admin-only physical interface, not bridged to the main network fabric
<whitequark> when did you start making such bloatware? :P
<whitequark> well, i would personally write it in rust and run on bare metal, if i really wanted to bother with an entire programming language toolchain
<whitequark> but i would also honestly consider a microcoded fpga impl
<gruetzkopf> sorear: you don't. but 500m stationary block lenght was common-ish, 250m exists, 100m does too
<azonenberg_work> So, i am not opposed to running bare metal on the fpga
<azonenberg_work> in fact i'd prefer that
<azonenberg_work> if i could find a sshd for bare metal that i trusted
<azonenberg_work> the only one i can find is wolfssl
<azonenberg_work> And, based on past experience doing security audits of it
<azonenberg_work> i'm not sure i'd want to deploy it :p
scrts has quit [Ping timeout: 240 seconds]
rohitksingh has joined ##openfpga
<azonenberg_work> bare metal on the arm*
<whitequark> why do you need ssl?
<azonenberg_work> I wanted SSH
<azonenberg_work> For the admin shell
<whitequark> can't you use the djbssh mode?
<whitequark> poly1305-whatever
<azonenberg_work> wolfssl includes a ssh server library
<azonenberg_work> has nothing to do with their tls impl
<whitequark> oh
<azonenberg_work> But i've found bugs in their codebase in the past that allowed full undetected mitm and other nasties
<azonenberg_work> i could create a crafted tls cert that it would parse as an intermediate CA
<azonenberg_work> etc
<azonenberg_work> The bugs are patched now but i still dont feel comfortable deploying something where the general code quality is as bad as that
scrts has joined ##openfpga
<jn__> is bearssl good? it's another one of those small TLS libraries
<azonenberg_work> never heard of it
<azonenberg_work> do they have a sshd?
<azonenberg_work> i'm not super duper concerned about security on the mgmt port since it should be a dedicated network not bridged to the main switch fabric but i dont want to run cleartext or joe schmoe's github sshd if i can avoid it :p
<jn__> apparently not
<awygle> i'm gonna start naming all my projects "joe shmoe's github X"
<whitequark> ah yes, js-sshd
<awygle> whitequark: "microcoded fpga impl [of ssh/readline]" this is why your life is an infinite stack of yaks
<awygle> :p
<whitequark> ok but
<whitequark> bUT
<pie_> ^^^ BUT
<azonenberg_work> If i could find an fpga sshd that was well reviewed and trusted
<azonenberg_work> I'd love to use it, although i'd prob still use a softcore for the CLI
<azonenberg_work> The problem is, i dont think one exists and i wouldn't even trust your implementation until it had been carefully looked at by multiple people with expertise in crypto
<pie_> otoh hardware is harder to get reviewed than software?
<awygle> inb4 formal verification
<azonenberg_work> well a lot of the easy bugs in sw dont exist in hw
<azonenberg_work> like cache timing, OoO side channels, etc
<azonenberg_work> all go away when you have deterministic RTL timing
<azonenberg_work> But you can still have actual crypto bugs in things like cert verification or ecc curve parameter verification etc
<pie_> i guess
<azonenberg_work> As soon as this construction is over
<awygle> i imagine ssh/ssl is actually a pretty good use case for fpgas
<awygle> for a number of reasons
<azonenberg_work> i'd be willing to donate a bit of $$, and time, to support creation of a formally verified rtl implementation of ssh
<azonenberg_work> Along with a tcp/ip stack to go under it obviously
<whitequark> obviously
<azonenberg_work> I am working on a stack now, but its a ways from being generally useable and lacks client support entirely
<awygle> we need a smaller diminutive than smol
<whitequark> well, i wrote one tcp/ip stack, how hard ca[is immediatelly killed by a PDP-11 attacking from an ambush]
<azonenberg_work> it can only respond to incoming connections
<azonenberg_work> no outbound
<azonenberg_work> this is bare metal unlike my old antikernel stack that was too closely coupled to the antikernel noc to be generally useable
<azonenberg_work> this will be a native bus interface that you could build an axi, wishbone, antikernel noc, etc wrapper around
<azonenberg_work> And right now its ipv4 and udp only bc thats what the one niche use case i had for it required
<azonenberg_work> And it doesn't support ARP tables yet so all outbound packets are layer 2 broadcasts :P
<azonenberg_work> (it correctly responds to inbound arp)
<azonenberg_work> Anyway for LATENTRED i will probably go wiht linux or at least a software ssh stack just in the interests of getting it working in a relatively timely fashion
<azonenberg_work> by the time i get to LATENTORANGE i'd be willing to consider a more hardcore rtl sshd
<awygle> a hardcore softcore, if you will
<azonenberg_work> lol
* awygle hums the red hot chili peppers
azonenberg_work has quit [Ping timeout: 268 seconds]
<rqou> wait wait whitequark you're calling readline "easy"?!
<rqou> you must have a totally different scale of difficulty from me since i briefly investigated what this would require and nope-d out
<gruetzkopf> and what's LATENTYELLOW gonna be? :D
<awygle> skip all the way to LATENTVIOLET
<whitequark> LATENTGAMMA
<gruetzkopf> need to implement LATENTFARIR
<gruetzkopf> for 3MBit/s ethernet
<awygle> all of these should get 20% faster when used with optics whose wavelength matches their names
<whitequark> LATENTFARIR is a dropbear process running on a broadcom SOHO router chipset
<whitequark> on linux 2.6.22
<gruetzkopf> oh, you mean like openwrt 9.something :D
<rqou> certainly you mean 2.4.x
<whitequark> i haven't met 2.4.x in years now
<whitequark> but i met 2.6.22 literally days ago
<gruetzkopf> i'm sitting next to a 2.2 device atm
<rqou> all the BRCM SOHO routers used to be 2.4 because of nasty hooks that the blob wifi driver used
<whitequark> ok you all win.
<whitequark> you win at suck
<whitequark> congratulations :
<whitequark> :p
<rqou> BRCM is bad at software
<jn__> and documentation
<whitequark> stop the presses
<whitequark> is there anything BRCM is good at, other than lawyering?
<jn__> and sometimes hardware
<rqou> hey, the StrataXGS switch chips in general actually work
<gruetzkopf> except when they confuse a packet with a mac starting with 6 with a v6 raw frame
<rqou> what
<rqou> i didn't hear about that
* rqou blames SDK
rohitksingh has quit [Quit: Leaving.]
<jn__> you blamed correctly
<rqou> also, afaik broadcom is actually pretty good at RF design
<rqou> (the problem is that many of these chips then get gimped by shitty firmware)
<whitequark> oh this reminds me of this ecisco switch
<whitequark> i mean router
<whitequark> it had 6 antennas riveted flat onto the case plastic
<whitequark> do you think they used u.fl to connect them to the pcb? you think wrong
<whitequark> they did use u.fl. on exactly three of the antennas. so you can flip over the board and, probably, look for burn marks
<whitequark> the other three are soldered shut
<rqou> well, that's cisco
<rqou> cisco is crap
<rqou> although ime meraki is fine
<awygle> i have personally advocated a move from 2.4 to 4. ... 10? whatever the LTS one is, within the last two years
<awygle> 4.4 i guess
<rqou> what would be worse, ancient Linux or ancient VxWorks?
<rqou> hmm, awygle, whitequark: ancient WinCE :P
* whitequark winces
<rqou> inb4 "not a voting machine"
<awygle> hm, winCE vs old vxworks is tough actually
<awygle> probably because i've been more proximately burned by vxworks
<gruetzkopf> old eCos
<cyrozap> whitequark, awygle: Hey, random question: For that logic analyzer (etc.) you're building, will there be a clock input/output? I was just thinking, it would be nice to be able to synchronize an arbitrary number of devices for more data throughput/extra LA channels.
<rqou> gruetzkopf: hacked up DOS :P
<rqou> I'm sure there are nonzero industrial machines that work this way
azonenberg_work has joined ##openfpga
<gruetzkopf> yep
<whitequark> cyrozap: yes, it has a SYNC port
<whitequark> open drain
<gruetzkopf> jn and i recently happened upon a VME machine (68030) that's running basically a terrible dos clone, apparently
<cr1901_modern> winces... WinCEs... w- was that an intentional pun?
<whitequark> yes
<rqou> gruetzkopf: i have a machine that i will be working on eventually that's running OS-9 on a 68k
<rqou> not the 🍎 OS-9, the other one
<jn__> microware OS-9?
<rqou> yeah
<rqou> wow, less obscure than i expected
<gruetzkopf> the boardset we have is fairly undocumented
<gruetzkopf> it's a old adept robot controller (board: 030, SIO, DIO, MI-6 and some encoder interface)
<jn__> rqou: but does it run Dinkumware libc++? (just kidding)
<gruetzkopf> hey, SCSI HDD and pc compatible floppy
digshadow has joined ##openfpga
<pie_> i
<pie_> what
<pie_> lol
<pie_> what
<pie_> rqou, will there be one for yuri or are all boys just horny bastards
* pie_ being ironically antithetical
renze has joined ##openfpga
Miyu has joined ##openfpga
<awygle> ot but wow, is rustup really only two years old?
<sorear> rustup, multirust, or rustup.rs?
<sorear> I’ve used all three …
<awygle> rustup in its current form
<awygle> i have never known a world where multirust was anything but legend, and i thought i'd been following rust at least for more than two years
<awygle> apparently not. long two years lol
<sorear> I got to into it shortly after 1.0 hit stable, I already feel very new
digshadow has quit [Remote host closed the connection]
pie_ has quit [Ping timeout: 268 seconds]
digshadow has joined ##openfpga
<azonenberg_work> rqou: so in case you are wondering
<azonenberg_work> with security level 0 (disabled)
<azonenberg_work> it appears the stm32 FPB isn't cleared by a warm reset
<rqou> hmm
<rqou> what about the flash lockout in rdp1?
indy has quit [Remote host closed the connection]
<azonenberg_work> Not tested yet
<rqou> we need that to get cleared in warm reset i think?
digshadow has quit [Ping timeout: 265 seconds]
m_t has joined ##openfpga
indy has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
digshadow has joined ##openfpga
GenTooMan has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
pie_ has joined ##openfpga
digshadow has joined ##openfpga
<sorear> nextpnr and vpr are both SA, right?
Bike has quit [Ping timeout: 252 seconds]
<digshadow> sorear: what is SA?
<digshadow> simulated annealing?
<sorear> yes
<daveshah> sorear: yes, nextpnr for now at least
<daveshah> We would like to have an analytical placer at some point. ZipCPU was going to work on that
<sorear> i'm still baffled by the level of pettiness around nextpnr and kingler but if it's the only foss analytic pnr it at least has a reason to exist
<daveshah> Yeah, I want kingler to happen for that reason alone too :D
<daveshah> Seriously, I would love to see what difference analytical par makes
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/66aa94242759f42f4565fdd474a1d5b42b96845c
<openfpga-github> Glasgow/master 66aa942 whitequark: Rewrite the entire thing to use Python asyncio.
<whitequark> phew, this took an eternity
<whitequark> and still seems kind of buggy
<florolf> azonenberg_work: rqou: tried that just now on an f103. it seems that while FPB is in fact preserved (both in RDP0 and 1), flash access is only restored after a POR once a debugger has been attached
<rqou> damn
<gruetzkopf> :(
<rqou> wait a sec
<florolf> the f103 is probably a remarked gd32, though. i'm torn whether this might make a difference in this case
<rqou> the fraunhofer research from a while back mentions that not all debug access trips the readout protection
<gruetzkopf> there's quite a few ways to tell them apart
<rqou> wait where are you getting gd32s?
<gruetzkopf> mostly around the usb hardware
<rqou> i actually want one of those
<florolf> otoh, in most cases where you'd want to dump the firmware off an f103, you're probably dealing with a gd32 anyway..
<rqou> really?
<florolf> rqou: i'm buying bluepill boards off aliexpress :p
<rqou> hmm ok
<rqou> anyways, gd32 is pretty "straightforward" to pwn with "just" some microprobing
<digshadow> what is the name of the paper you are referencing?
<florolf> gruetzkopf: do you have an address i could poke to check that?
<rqou> the fraunhofer research mentions that if you don't touch the AHB-AP you won't trigger the lockout
<digshadow> cool thanks
<rqou> can so access the FPB without touching that?
<azonenberg_work> yes
<rqou> *can you
<azonenberg_work> that's done over the APB MEM-AP
<azonenberg_work> however, you do have to use AHB to write to sram
<azonenberg_work> so the FPB actually does something useful
<rqou> hmm, maybe this is still exploitable
<azonenberg_work> unless you could figure out a way to get your shellcode into ram somehow through a e.g. uart buffer
<azonenberg_work> at a known address
<azonenberg_work> then use the FPB to jump to it?
<rqou> you can do your sram write and then a full reset
<azonenberg_work> you mean a POR?
<rqou> yeah
<azonenberg_work> after killing power sram data is probably gone
<azonenberg_work> no?
<rqou> not instantly
<azonenberg_work> or do you just glitch it briefly
<azonenberg_work> and hope the data is alive
<rqou> yeah
<rqou> also, iirc you don't need a full POR, just assert external reset
<azonenberg_work> oh
<azonenberg_work> well i tested, poking external reset does not appear to wipe the FPB
<rqou> either way your sram data stays for the order of seconds
<rqou> O_o
<azonenberg_work> Only a POR will clear it
<rqou> did they fuck it up? i hope they fucked it up :P
<rqou> stm32 security is a disaster
<azonenberg_work> i'm testing in RDP 0 right now still
<azonenberg_work> just to make sure my tools are working
<rqou> seriously, test RDP 1
<florolf> rqou: all tests above were done using an external reset
<rqou> so the proposed pwning is to load code into sram, possibly do a full POR, poke FPB, and then do a reset?
<florolf> if the apb mem-ap thing actually works. the paper isn't really clear about that
<rqou> hmm yeah
<rqou> anyways, if it does work, nice 0-day we've got here
<rqou> no bitching about disclosure required
<florolf> i only have openocd and a jlink at hand, which doesn't really afford enough control to try that, though
* florolf waits for azonenberg_work :p
<azonenberg_work> my recollection is that writing to sram over ahb mem-ap didnt work in rdp 1
<azonenberg_work> but if you combine with the cold boot bug might be exploitable
<rqou> wait no
Miyu has quit [Ping timeout: 264 seconds]
<rqou> writing sram should work
<florolf> i was definitely able to write to sram in rdp1
<azonenberg_work> Might have been a bug in my tool
<azonenberg_work> i'll poke more
<azonenberg_work> Right now i want to finish bringing up the FPB
<azonenberg_work> i'm patching the demo stm32 discovery app so it toggles different LEDs than normal\
<gruetzkopf> i have a few perfectly legit stlinkv2 around
Bike has joined ##openfpga
Miyu has joined ##openfpga
cr1901_modern has left ##openfpga [##openfpga]
<florolf> rqou: gruetzkopf: fwiw, judging from the flash configuration registers, the chip i've been looking at actually seems to be an stm32
Miyu has quit [Ping timeout: 240 seconds]
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
jn__ has quit [Ping timeout: 248 seconds]
jn__ has joined ##openfpga