<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
<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
<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>
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
<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/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?