<sorear>
the privileged architecture is separate from the user ISA, there's just no letter for the privileged architecture
<rqou>
so you technically don't need to implement it?
* rqou
goes to berkeley and doesn't know how risc-v works :P
<sorear>
there's a lot of design space with interrupts that I'm not sure is being adequately handled
<rqou>
japaric over in rust-land has been cleverly abusing the cortex-m nvic into a task scheduler
<sorear>
liviu ionescu, who sifive hired for the eclipse port(?), is very annoyed that it's not memory-mapped everything and you have to use asm() to access privileged registers
<rqou>
the cortex-m nvic probably has a silly patent on it though
<sorear>
the interrupts stuff in the spec is designed for multicore systems which need nesting but don't have especially stringent latency rules
<rqou>
but that's not what i would need
<sorear>
stupid and possibly insulting question: I know you're a Berkeley student but is your shared name with Albert Ou on the riscv core team a coincidence
<rqou>
coincidence
<rqou>
this name isn't _that_ rare
<cr1901_modern>
I can't decide whether I like the priv ISA or not. It's overkill for a small impl tho.
<rqou>
yeah
<cr1901_modern>
I know I've seen a number of ppl on birdsite who hate it
<rqou>
iirc it also has hypervisor mode and nested paging?
<cr1901_modern>
wtf is nested pa- ya know what, I don't want to know
<sorear>
the hypervisor mode was a terrible idea (independent reinvention of everything wrong with EL2) and has been expunged after a long fight
<sorear>
there's a new "virtualization extension" which I'm fairly sure will be slower to use in practice than what you can do without it
<rqou>
does it also have the bikesheds of "hardware walk vs TLBs" and "direct vs inverted page tables" with the answer being "all of the above!"
<rqou>
or did they just pick one
<sorear>
no
<sorear>
the only thing I know that that describes is ia64, a very messed up design
<cr1901_modern>
what's an inverted page table? Is that similar to what SPARC used (and Linus hated it)?
<sorear>
riscv is architecturally hardware walk and direct page tables only, although there's a note in the spec clarifying that you're allowed to use microcode for the walk, because apparently hardware designers are idiots and don't understand the as-if principle
<cr1901_modern>
PowerPC*
<sorear>
cr1901_modern: precisely that
<rqou>
PPC is confusing AF
<rqou>
i'm sure Dolphin devs love it
<sorear>
paging is also optional
<cr1901_modern>
sorear: I see
<cr1901_modern>
sorear: Okay, a _lot_ to unpack here: "although there's a note in the spec clarifying that you're allowed to use microcode for the walk, ... as-if principle"
<cr1901_modern>
1. if you're using microcode for the walk, that's still a hardware walk
<cr1901_modern>
2. What is the as-if principle
<cr1901_modern>
3. I do not imagine a hardware walk is pleasant to do without microcode (and even then it's not pleasant)
* cr1901_modern
would much rather do a software walk
<sorear>
a minimal implementation of the privileged spec consists of (1) mepc, mscratch, mtvec, mtval registers, pointer-sized and have no read or write effects, can be part of a combined register file (2) mip, mie, mstatus registers, only have a few implemented bits each (3) decoding for CSR instructions, including tying certain unimplemented registers to 0 (4) sequencing for traps and trap returns
<cr1901_modern>
Does that incl paging?
<sorear>
as-if principle: rule explicit in the C spec but widely used elsewhere that says that the spec is not a literal description of how a computer is constructed but describes how the abstract machine is viewed by software
<sorear>
no paging
<cr1901_modern>
sorear: I meant specifically w/ paging.
<sorear>
adding paging support requires a second bank of trap registers and interrupt enables, the MMU, the MMU control register (satp), and the MMU control instruction (sfence.vma)
* awygle
always thought the N in NVIC was "non"
<cr1901_modern>
If you need to do the walk in hardware, hardwired, that's gonna be a potentially complex state machine.
<awygle>
which, admittedly, makes no sense
<cr1901_modern>
and second bank of trap registers? I should reread the spec
<sorear>
sepc, sscratch, stvec, stval
<awygle>
something about that set sounds vaguely sinister, like it was created by an evil snake wizard
<sorear>
machine mode interrupts are close to what NMIs are elsewhere, and need to be handleable even when S-mode is in the middle of saving state for a normal interrupt, hence the second set of registers
<cr1901_modern>
Not really familiar w/ NMIs on anything modern, tbh
<cr1901_modern>
I know on old CPUs they don't bother having shadow regs
<cr1901_modern>
Ahhh, well why'd they decide against software walk :/? I mean, I have a few ideas to make a hardware walk look like software, but nothing that doesn't take up a lot of space.
<cr1901_modern>
s/Ahhh/Also/
<sorear>
you can make a software walk look like hardware by doing it in microcode/super-privileged mode, but the reverse is not possible
<cr1901_modern>
I'll think on this and talk more/join in #riscv when I've had time to really parse this
<awygle>
every time somebody talks about taking time to really digest a complex point of software i have the same fantasy of quitting my job to do 100 days of code and spend it implementing 100 algorithms based on their original papers....
<cr1901_modern>
Yea, I'll be lucky if I have the concentration/patience to do 5
<awygle>
yea, it's an unrealistic fantasy for many reasons lol
<cr1901_modern>
That looks abnormally small. What's the Nil mean?
<cr1901_modern>
it's a 4 state fsm... with 5 Identifiers?
<sorear>
i assume it's pattern matching a lisp/haskell style list
<sorear>
let a:b:c:d:[] = list_of_4 in ...
<sorear>
i don't actually know scala beyond what I've picked up trying to read the rocket/boom sources
<cr1901_modern>
In any case, I would've expected at least the following states: idle, fetch_1st_level, 1st_level_miss, 1st_level_hit, fetch_2nd_level, 2nd_level_miss, etc
<sorear>
what do you mean by hits and misses?
<cr1901_modern>
present bit not set
unixb0y has quit [Ping timeout: 240 seconds]
ZipCPU|Laptop has joined ##openfpga
unixb0y has joined ##openfpga
<sorear>
if the present bit isn't set at any level, you immediately bail out of the entire walk and generate a page fault
m_w has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
rohitksingh_work has joined ##openfpga
digshadow has joined ##openfpga
genii has quit [Read error: Connection reset by peer]
mithro has quit [Read error: Connection reset by peer]
bubble_buster has quit [Read error: Connection reset by peer]
marex-cloud has quit [Read error: Connection reset by peer]
JSharp has quit [Ping timeout: 260 seconds]
daveshah has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Read error: Connection reset by peer]
Ishan_Bansal has quit [Read error: Connection reset by peer]
sorear has quit [Read error: Connection reset by peer]
pointfree has quit [Read error: Network is unreachable]
jeandet has quit [Read error: Connection reset by peer]
cblam has quit [Ping timeout: 256 seconds]
nickjohnson has quit [Read error: Connection reset by peer]
elms has quit [Ping timeout: 256 seconds]
kem_ has quit [Ping timeout: 256 seconds]
_florent_ has quit [Ping timeout: 255 seconds]
m4gul0 has quit [Ping timeout: 256 seconds]
ovf has quit [Ping timeout: 256 seconds]
daveshah has joined ##openfpga
futarisIRCcloud has joined ##openfpga
bubble_buster has joined ##openfpga
pointfree has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
m4gul0 has joined ##openfpga
nickjohnson has joined ##openfpga
Ishan_Bansal has joined ##openfpga
mithro has joined ##openfpga
kem_ has joined ##openfpga
_florent_ has joined ##openfpga
cblam has joined ##openfpga
ovf has joined ##openfpga
sorear has joined ##openfpga
jeandet has joined ##openfpga
marex-cloud has joined ##openfpga
elms has joined ##openfpga
JSharp has joined ##openfpga
Bike has quit [Quit: Lost terminal]
<azonenberg>
awygle: first step is "install and run splash"
<azonenberg>
Which needs some work :p
<awygle>
yeah i was going to make a joke about "negative semver" earlier
<awygle>
"not only is this not stable, neither is the build system"
<awygle>
i'm substantially more likely to submit a PR for e.g. CMake support :P
<azonenberg>
awygle: so the issue is, in order to have clean builds of both rtl and software
<azonenberg>
a lot of tables of constants etc are auto generated
<azonenberg>
by the build system
<azonenberg>
So you'd have to implement a yaml parser in cmake to generate those .h files
<awygle>
scons then lol
<awygle>
there's RTL in libjtaghal/
<awygle>
?
<azonenberg>
No, but the jtaghal protocol was intended to be implemented in rtl by starshipraider
<azonenberg>
so all of the opcodes are in constant files
<azonenberg>
This will get a lot better in a few months
<awygle>
ah
<azonenberg>
because i plan to refactor it to use protobufs
<azonenberg>
once i have my fpga protobuf lib
<azonenberg>
then an out-of-antikernel cmake build will be practical
<awygle>
right
<azonenberg>
I have logtools and a few other libraries dual-builded already with splash plus cmake
<azonenberg>
thats the big holdup for jtaghal
<awygle>
well i'll keep an eye on it
<azonenberg>
although, actually
<azonenberg>
Given that i do not currently have a working hardware implementation of the protocol
<azonenberg>
changing it wont break any rtl
<azonenberg>
So i may do the protobuf refactoring sooner rather than later
<azonenberg>
if you're interested in helping out, PRs are welcome
<azonenberg>
basically NetworkedJtagInterface and jtagd (in the antikernel repo right now, i have to figure out a good spot for it) need to be converted to use protobufs
<awygle>
i was considering adding support for one or more Lattice boards i'm working with
<awygle>
because vendor jtag tools are garbage
<azonenberg>
In the short term if you want to just make a parallel cmake script
<awygle>
and reverse engineering protocols is fun
<azonenberg>
and manually convert the protocol .yml to a .h and include that
<azonenberg>
i'll accept the PR
<awygle>
duly noted
<awygle>
i'll see if i can find time to do that this weekend
<azonenberg>
all of the code is standard C++, thats the only odd bit
<azonenberg>
the antikernel core is what will need more work to get buildable by joe public
<azonenberg>
basically i just have to get splash more usable and stable
<awygle>
splash sounds cool, but i don't like build system issues so i try not to use unstable build systems
<whitequark>
azonenberg: hmmm if I ever finish my jtag adapter looks like it will work out of box with libjtaghal
<azonenberg>
whitequark: nice
<whitequark>
since libjtaghal supports mpsse
<azonenberg>
right now i assume i think gpio8 on the ftdi is an output enable
<azonenberg>
thats the one thing that should probably be ported to be configurable
<azonenberg>
But yes otherwise it will work out of the box
<azonenberg>
That's what the digilent hs2 does
<azonenberg>
hs1 sorry
<whitequark>
or it could be made configurable inside the bitstream :P
<azonenberg>
my adapters use my own pid under ftdi's vid, and a different level shifter
<awygle>
i think the versa also does mpsse
<azonenberg>
but are otherwise basically hs1's
<awygle>
so that's nice
<whitequark>
azonenberg: any interest in giving me feedback on hardware once I have something I can show?
<azonenberg>
Sure
<whitequark>
k thanks
<azonenberg>
My first feedback is, usb-jtag chipsets all suck so dont use any of them
<azonenberg>
:P
<whitequark>
well obviously
<azonenberg>
but ftdi is the least sucky
<whitequark>
have I ever told you what I want?
<azonenberg>
At some point i want to make jtaghal able to speak the xilinx virtual cable protocol as both a client and server
<azonenberg>
so i can bridge cleanly to vivado and the xilinx platform cable etc
<whitequark>
cy7c68013a plus ice40up5k emulating ftdi chips
<whitequark>
sans all the bugs
<whitequark>
and then you can build a custom protocol starting there
<azonenberg>
yeah
<whitequark>
the idea is to be a drop-in replacement for "some jtag cable" so that the board is universally usable but potentially be much more powerful
<azonenberg>
the new jtaghal protocol is going to be protobuf based
<azonenberg>
and intended to run over 1/10G ethernet
<azonenberg>
i mean it will work over a WAN too
<azonenberg>
but the intended use case is mostly a little hardware server plugged into a DUT somewhere on the lan
<awygle>
whitequark: i may have asked you this last time you brought this up but are you familiar with the bus blaster?
<whitequark>
awygle: vaguely
<awygle>
your board sounds like that on steroids
<whitequark>
yes
<whitequark>
that's the idea
<awygle>
(but not azonenberg-level steroids)
<whitequark>
I want to be able to e.g. do SWD, including sucking in data from SWO pin, too
<whitequark>
as for not having azonenberg-level steroids that's a feature :]
<whitequark>
i want a BOM of $25 or so
<awygle>
oh no question :p
<awygle>
i was going to ask about bom target - is that board-included?
<awygle>
i have longer-term interest in something like this
<whitequark>
yeah, I think I'll go for 4-layer and use BGA packages so that it's tiny
<whitequark>
I think it misses a bunch of command bytes
<awygle>
misses as in they're not implemented or as in it drops them during transfer?
<whitequark>
they're not implemented
<awygle>
okay sure, i can do some work on that
<awygle>
fun excuse to learn migen finally
<whitequark>
I think the ones we should implement are 4A 4B 6A 6B 6E 6F 84 85 8A 8B 8E 8F
<whitequark>
the CPU mode, the I2C mode, and GPIO wait commands aren't as useful
<awygle>
makes sense
<whitequark>
I've added links to MPSSE docs at the top of that file
<whitequark>
have fun!
<awygle>
will do :)
<whitequark>
the tests can be somewhat of a pain to write, tell me if you have trouble
<azonenberg>
whitequark, awygle: starshipraider is not meant to be just a jtag tool
<awygle>
i know lol
<azonenberg>
its meant to be a jtag plus LA, GPIO bitbang, and a bunch of other tools all in one board with a very wide io voltage range
<azonenberg>
I think my BOM target is a fair price for what it will do
<azonenberg>
That said, it is overkill for people who don't build / RE nontrivial hardware for a living
<awygle>
right, i don't need something that can do picosecond timing analysis. i just want to jtag some boards.
<azonenberg>
lol its not picosecond
<azonenberg>
its going to be 500 Msps on the digital I/O card
keith-man has joined ##openfpga
<whitequark>
azonenberg: my board isn't just a JTAG tool either
<whitequark>
even in the basic configuration it's JTAG plus two serial
<azonenberg>
The big thing that jacked up the cost/complexity of my design was the wide io voltage range requirement
<azonenberg>
1.2 to 5V across four independent banks
<azonenberg>
with +/- 12V tolerance
<azonenberg>
i need to respin my board again some time soon ans see if i have it debugged yet
<azonenberg>
and*
<azonenberg>
the io buffer is decidedly nontrivial
<whitequark>
I'm thinking on my board I'll just use a DAC with a buffer for VCCIO for the banks
<azonenberg>
I was going to use a variable LDO to get increased output current
<azonenberg>
But i'm also using comparators on every input to get a precise threshold
<azonenberg>
thats straightforward if a bit pricey
<azonenberg>
The really hard part is the +/- 12V input tolerance while making every pin bidir
<azonenberg>
if i can hit +/- 24V that would be even better
<azonenberg>
but 12 is a minimum design target
<sorear>
(why is the input tolerance really hard? what would make it easier?)
<azonenberg>
sorear: Making things that survive / work at high voltage generally means thick gate oxide
<azonenberg>
Making things fast generally means thin
<azonenberg>
The two are directly at odds with each other
<azonenberg>
This is one of the reasons logic keeps moving to lower voltages
<azonenberg>
as it is, in order to get acceptable performance across the 1.2 to 5V range i have to use two different output buffers for level shifting
<azonenberg>
one for 1.2 to 3.3 and one for 3.3 - 5
<azonenberg>
the 3.3-5 part works down to 1.2 but the speed is like 40 Mbps at that range
<azonenberg>
meanwhile the fast part is like 400 Mbps at 1.2V but dies if you give it >3.6V
<azonenberg>
And i have to mux between the two without degrading the signal, and ensure that when operating at 5V the low voltage part is completely isolated from ever touching either the supply or data line with the higher voltage on it
<sorear>
how much output resistance can you tolerate?
<azonenberg>
About 30-40 ohms to match my output to a 50 ohm line
<azonenberg>
Using clamp diodes doesn't work, because they have too much capacitance
<azonenberg>
i tried that
<azonenberg>
in order to clamp a 12V fault to ground through 40 ohms without melting, you need a diode with several tens of pF capacitance
<azonenberg>
through 40 ohms you get a terrible low-pass filter on the input
<azonenberg>
My proposed new design, not yet tested, splits the AC and DC path
<azonenberg>
They're connected in parallel at both ends
<azonenberg>
AC path: coupling capacitor then low-capacitance ESD diode
<azonenberg>
The diode is there to block transients when you suddenly apply a high voltage to it, but DC can't get through so the diode doesn't have to be able to short 12V to ground for any significant length of time
<azonenberg>
DC path: ferrite choke in series with the signal (to prevent AC from getting through and being degraded by the power protection)
<azonenberg>
then a big-ass clamp diode with massive capacitance but IDGAF because the RF signal never touches it
<azonenberg>
then a second ferrite on the far side to keep the TX waveform from going through that path
<azonenberg>
On the probe side, after they join, i have a ~33 ohm resistor (serves as seires terminator for the output, and current limits the clamp diode when faulting on input) and a relay
<azonenberg>
actually no, not a realy
<azonenberg>
there's a small FET between the ferrite and the clamp diode
<azonenberg>
Doesnt need good RF performance
<azonenberg>
This design lets me separately optimize the signal path for high speed (AC coupled) while also having a DC coupled path that can drive against a pullup resistor or hold a signal at a steady logic level
<awygle>
azonenberg: did you try a PNNP clamping diode?
<awygle>
(splitting the paths is the right solution, just wondering)
<azonenberg>
awygle: so the issue is, i have to clamp really close to the rails
<azonenberg>
the negative rail i only have ~500 mV of tolerance from "normal operating range" to "things might fry"
<azonenberg>
which basically mandates a schottky
<azonenberg>
schottkies have high capacitance
<azonenberg>
I actually did transient testing and eye plots of my waveform through a characterization board
<azonenberg>
It wasnt going to happen, there isnt a diode on the planet that had the specs i needed
<azonenberg>
i looked through basically digikey's whole inventory and a couple of other places
<azonenberg>
By splitting the paths i can get what SHOULD be a really nice result
<azonenberg>
The tradeoff is, this approach does not protect against high energy RF faults
<azonenberg>
So if i probe the SW line of a SMPS fed by 12V or something, i'm likely to blow the buffer
<sorear>
add an extra ~0.5V rail for the negative clamp?
<azonenberg>
I got halfway through designing that
<azonenberg>
before realizing i had a problem
<azonenberg>
Diode I/V curves
<azonenberg>
(digikey doesnt let you search for this btw)
<azonenberg>
I was actualyl planning to run the diode partially on, leaking a mA or so
<azonenberg>
so i could get really close to the knee and have it turn on super fast when i faulted
<azonenberg>
but parasitics ate my signal alive in that regime
<azonenberg>
junction cap, man
<azonenberg>
it's a thing
<awygle>
if you're actually worried about RF faults you can put a -20 hybrid on it, i suppose
<azonenberg>
this is bidir though :)
<azonenberg>
I need to be able to drive LVCMOS12 at 500 Mbps OUT from this probe too
<azonenberg>
like i said the engineering challenges are nontrivial
<awygle>
it's been a while since i've designed a hybrid but i think bidirectional is actually easier, you just don't terminate the other leg
<azonenberg>
Can you make something with unity gain one way and 20 dB attenuation the other waY?
<azonenberg>
way*
<sorear>
can the input side tolerate higher resistance than the output side?
<azonenberg>
sorear: potentially
<awygle>
ah, yeah i see what you're saying
<awygle>
yes, you can, it's called a circulator
<azonenberg>
awygle: I think this new solution is the best route, it eliminates a relay from my signal path
<azonenberg>
and generally simplifies the bom
<awygle>
but they're basically not the solution to any problem
<azonenberg>
while potentialyl increasing the voltage range i can tolerate
<azonenberg>
keep in mind, i need 32 channels of this
<azonenberg>
board area is a nontrivial consideration
<awygle>
and circulators a billion dollars
<azonenberg>
As is BOM cost... adding a $3 component suddenly brings your BOM up by $100
<azonenberg>
so one little opamp is a big deal
<awygle>
like i said, splitting the path is the right solution
<azonenberg>
Yeah
<azonenberg>
I just have to prototype it
<azonenberg>
And i have this whole house project getting in my awy
<azonenberg>
i wont be donig any boards until thats done
* sorear
wonders if bipolar level shifters are a thing
<azonenberg>
I also need to finish my active differential probe board
<azonenberg>
i have an assembled PCB sans a few components
<azonenberg>
a) i have to write firmware for the control ,cu
<azonenberg>
mcu*
<azonenberg>
b) when i first made it, it shorted out
<azonenberg>
i pulled a bunch of parts which seemed to fix it
<awygle>
my solder got here today, i should build that mixer board
<azonenberg>
havent had time to put them back on one by one until i figure out what was wrong
<azonenberg>
That one was a fun design too, DC to 500 MHz active diff probe
<awygle>
i still don't have an SDR to do proper testing with though
<azonenberg>
With 50 ohm matched input and output
<awygle>
should do 400 MHz to 2.2 GHz for <100 mW
<azonenberg>
nice
<awygle>
i saw an ice40-based SDR design earlier that was pretty cool
<awygle>
i was trying to get a PSK design under 250 mW and couldn't do it around this time last year
<awygle>
might have to give it another go
<awygle>
i still need a good Class C amp at S-band too
<awygle>
high power RF transistors are stupid expensive
* azonenberg
wants to build a C-band electronically scanned phased array at some point
<azonenberg>
low power, like tens or maaaybe hundreds of mW output
<azonenberg>
and just 1D to start
<awygle>
i need a 5W 2.2 GHz power amplifier with a PAE > 50%
<azonenberg>
ok thats a lot of output power
<awygle>
that transistor is $$$ :(
<awygle>
i'd take like 2W but the best i found for less than 50$ was 1W
<azonenberg>
i wanted to just have enough power to see cars driving down the street or something
<azonenberg>
so << 1W is plenty
<awygle>
i wanted to have enough power to transmit from space, so ... different parameters lol
<azonenberg>
Yeah, lol
<sorear>
meanwhile NASA seems to think that 10W is the appropriate point to break out the vacuum tubes
<azonenberg>
eventually i want to do a 2D AESA
<sorear>
for deep-space microwave links
<azonenberg>
but that would be waay more expensive
<azonenberg>
i think my first phased array project will be in the audio band rather than microwave
<azonenberg>
Because the components are so cheap
<whitequark>
sorear: wow, that little
<awygle>
TWTAs
<azonenberg>
awygle: do you think i could build say an 8x8 phased array in the DC to 20 kHz band fairly cheaply?
* azonenberg
wants to be able to pipe music to one corner of a room, etc
<azonenberg>
even if it's telephone quality or thereabouts
<awygle>
20 kHz? the problem is antenna size at that point
<azonenberg>
this is audio not EM
<awygle>
oh
<azonenberg>
so MEMS mics and little tiny piezo speakers or something
<awygle>
uhhhhh sure? probably
<awygle>
i don't see why not
<azonenberg>
If i want to have useful performance start at say 1 kHz
<whitequark>
azonenberg: people usually do that with ultrasound
<azonenberg>
i'd want my elements a few inches apart (wavelength ~1 foot)
<whitequark>
two beams interfere and play what you want
<whitequark>
there are several commercial systems
<azonenberg>
whitequark: i'm talking about doing the whole thing in audio, just to learn about phased arrays
<awygle>
whitequark: like, mixing the ultrasound down to audible?
<azonenberg>
and debug by ear instead of with a fancy specan etc
<whitequark>
awygle: yup
<awygle>
whitequark: woah. awesome
<azonenberg>
hear all of the sidelobes etc
<azonenberg>
just by moving your head
<whitequark>
awygle: it's mostly used to blast targetd ads
<azonenberg>
eeew
<awygle>
less awesome
<sorear>
i haven't encountered that in person
<whitequark>
I've only read about these
<whitequark>
I assume they're only deployed in the US
<azonenberg>
you mean advertising central? lol
<azonenberg>
i did see one really annoying thing in the UK though
<awygle>
hmm i wonder how much bandwidth a reasonable PSK system would need
<awygle>
i can already push 500 kbps FSK so probably at least a few Mbps to be compelling
<azonenberg>
or was it the netherlands? i cant remember, it was on a trip from Seattle -> Amsterdam -> Dusseldorf -> Weeze -> Stansted -> London
<azonenberg>
and it wasn't SEA or AMS for sure
<azonenberg>
anyway, the path from the security checkpoint in the airport to the gate area takes you RIGHT THROUGH the duty-free shop
<azonenberg>
there's literally no way to not go through the store
<awygle>
anybody have a good low-power ~20 Mbps ADC or DAC to recommend?
<awygle>
Err 20 Msps
<azonenberg>
and its a long snaky path that brings you past every shelf
<rqou>
potentially flame-attracting opinion: "web infosec people" have no f*cking idea what they're doing when it comes to low-level apis (ie ones that can touch hardware)
<azonenberg>
Web infosec people spans a wide range
<azonenberg>
Those who specialize in web, i agree
<azonenberg>
but we have folks at IOA that do, for example, SCADA hardware webapp pentests
<awygle>
all the good DACs and ADCs are expensive :(
<awygle>
i feel like pentesting SCADA is probably like shooting fish in a barrel
<azonenberg>
awygle: lol
<azonenberg>
my first gig with IOA was for a power company
<azonenberg>
Makes me wonder how the lights stay on
<rqou>
azonenberg: was that the one you accidentally leaked?
<azonenberg>
No
<azonenberg>
this was actually a system vendor, not a utility
<rqou>
ah
<rqou>
was the one you accidentally leaked actually competent? :P
<azonenberg>
No comment
<awygle>
did you email their private keys to them?
<rqou>
lolol
<awygle>
i hear that's frowned upon
<rqou>
what about emailing their root password to them?
<rqou>
extracted from a press photo of their office of course (written on a postit and taped to a monitor)
<rqou>
:P
<azonenberg>
rqou: lol
<azonenberg>
i have not had that happen yet
<rqou>
btw iirc some french tv studio actually did this with their twitter password
<awygle>
our company gave us webcam covers with our bonuses this year
<azonenberg>
yes i remember hearing about that
<azonenberg>
We give them out at promo events
<rqou>
bonus points was that their twitter password was "the password for twitter" in french
<azonenberg>
But i never got around to stealing one for myself
<azonenberg>
So i just have tape over mine :p
<rqou>
but it's french, so you need a french dictionary before you can bruteforce :P :P
<rqou>
azonenberg: does IOA do physical security pentests?
<rqou>
any horror stories?
<awygle>
hm looks like i can do 20 Msps for <50 mW if i was willing to pay 35$ per ADC :(
<azonenberg>
Yes, here and there - it's a very small fraction of our overall business
<azonenberg>
And i've never been on one
<awygle>
arright enough of this, i don't do RF anymore, time to do real work
<azonenberg>
awygle: lol
* azonenberg
pokes awygle with a parallel PAR paper
* awygle
whistles nonchalantly
<azonenberg>
i have a 16 core / 32 thread rig with 192GB of RAM to test your algorithms on
<rqou>
awygle go use your fancy berkeley piece of paper for something :P
<awygle>
i'm stalling until they get the Artix stuff a little further along
<rqou>
(says the guy who also has one)
<azonenberg>
awygle: work on the core engine then?
<awygle>
mithro's vtr work makes me lazy :P
<azonenberg>
thats exactly what i dont want :p
<awygle>
i know lol
<azonenberg>
i want vpr to be the reference implementation and then we blow it out of the water
<awygle>
oh i want that too
<awygle>
but having a reference implementation makes beating one a lot easier
<awygle>
anyway
<awygle>
shame me some more tomorrow
<awygle>
i'm going to finish this work i get paid to do and then go to bed
Morn_ has quit [Ping timeout: 256 seconds]
Morn_ has joined ##openfpga
<mithro>
awygle: I could use help with that reference implementation :-P
<sorear>
how large are the architecture definitions / how well are they compressed relative to the number of unique pips on the target?
<mithro>
sorear: Hrm?
<awygle>
mithro: if you have specific things that you need done, i can probably help with that. what i can't take on right now is "project managing" anything else
<awygle>
(and yes i'm aware that by the time you get to that point it's often easier to just do it yourself)
<mithro>
awygle: I have a bunch of things that would be *super* helpful
<rqou>
anything that clifford-intern won't steal?
<mithro>
rqou: If you finish it in less than a month :-P
<rqou>
lol
<rqou>
unfortunately ETOOMANYTHINGS
<awygle>
mithro: i'll ping you tomorrow and we can discuss? i really do want to help, within the bounds of my currently-crazy life
<rqou>
awygle i'm curious what you're doing other than breaking your foot :P
<mithro>
awygle: Sure -- I'm happy to give you things which are not on the current critical path
<awygle>
rqou: you would be amazed at how much work breaking your foot is
<awygle>
and on that note i have physical therapy tomorrow at 7am so... goodnight all1
<rqou>
goodnight
<mithro>
awygle: The first question I'll ask you tomorrow is how good is your Python, C++ and/or Verilog? :-P
<whitequark>
it's subject to some caveats, i think in certain circumstances you have things like DWARF build ids not matching, so you don't get bit-for-bit identical binaries
<whitequark>
pretty much all differences are due to debug information
mumptai has quit [Quit: Verlassend]
<pie_>
yeah i just saw diffoscope in the thread, will look at that later, looks neat
digshadow has quit [Ping timeout: 252 seconds]
<awygle>
my work laptop is a sad, sad, toaster of a computer
<awygle>
wonder how mad IT would be if i used either of the twice-as-powerful computers within arms reach
zino has quit [Ping timeout: 260 seconds]
zino has joined ##openfpga
<mithro>
awygle: So my understanding is that you have short bursts of time when you can do things (because your avoiding doing other things you should be doing?) -- hence projects which have a bunch of small progress milestones would be good?
<mithro>
awygle: I'm guessing that getting familiarity with the architectures will also help with your planned llvm of FPGAs too -- so I was thinking helping figure out how to write unit tests and do simulation of models with timing taken into account could be a useful task? Have you use cocotb at all before?
mumptai has joined ##openfpga
<awygle>
mithro: that sounds reasonable. i haven't used cocotb before
<awygle>
mithro: per your last comment there, i also have ~some experience with yosys formal tools
<awygle>
if that's useful
<mithro>
awygle: Most of the stuff is *super* simple at the moment -- so I don't know if that makes it better or worse for formal
<mithro>
awygle: I have no formal experience
<mithro>
awygle: I like the idea of Cocotb as it seems to support easy testing in a both the commercial and open source simulators
<awygle>
mithro: a quick overview of what "sim.v" is would be helpful
<awygle>
my off-the-cuff guess is it's a simulation model in Verilog of a slice?
<mithro>
awygle: They are supposed to be verilog simulation models of the /actual/ parts inside an FPGA
<rqou>
hmm mithro i noticed you seem to really like frameworks
<mithro>
rqou: I really hate writing my own frameworks
<rqou>
i usually just write code without frameworks
digshadow has joined ##openfpga
<awygle>
mithro: and what are the unit tests unit testing?
<mithro>
awygle: That the sim models function how they are suppose too
kc8apf has quit [Quit: leaving]
kc8apf_ is now known as kc8apf
<awygle>
mithro: okay, but that's a little tautological if the sim.v model represents our best current understanding. Are we looking for "someone changed how this works without noticing", or are we testing *against* something?
<daveshah>
To an extent we can compare against vendor provided simulation models
<daveshah>
Otherwise it's really just a typo catcher
<awygle>
okay, gotcha
<awygle>
daveshah: I'm guessing the vendor sim models are dissimilar enough from our model that formal equivalence checking is a bad approach?
<daveshah>
It might be OK for the basic primitives,but I'm not sure how easy it would be to get going
<daveshah>
Also, I don't think Yosys' formal equivalence checks would consider all possible parameter values, which are important in this case
<daveshah>
So it wouldn't be a correct equivalence check unless all parameter possibilities were considered - easy for a DFF, hard for a LUT
<awygle>
That is true. Parameter support in Yosys formal tools would be really nice.
<awygle>
But does not exist currently
<daveshah>
No, only option would be to enumerate parameters using `chparam`
<azonenberg>
Yeah you cannot do formal over parameters and i dont think that will happen any time soon
<azonenberg>
but for smaller search spaces like a LUT
<azonenberg>
like a DFF*
<azonenberg>
you can probably iterate over the parameter space
<azonenberg>
for a lut, less so
<azonenberg>
you'd have to spot check and hope for the best
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
<mithro>
awygle: Everyone sucks at writing code - having tests which show our code is correct is good
<awygle>
mithro: sure, I just see way too many tests that aren't actually testing anything. "does + still add" is not a useful test, yknow?
digshadow-i has joined ##openfpga
<mithro>
awygle: Yeah - although that is surprisingly frequently borked in the corner cases in Verilog systems :-P
<mithro>
yosys doesn't do any formal verification when you take timing into account, right? It can't say that X must always go low before Y?
<mithro>
awygle: The tests are also more to show "how" something should work too -- IE they should be written to demonstrate the behaviour to a newbie too
<rqou>
oh, the "interpreter" is for running TrustedWorkers on a smartcard. you can use a jit if you're running on EL3/ME and want the chainsaws you're juggling to additionally be on fire
<whitequark>
JIT?
<whitequark>
why would you want to use a JIT for WASM code, ever?
<rqou>
er, AOT
<rqou>
the attack surface is marvelous either way
keith-man has quit [Ping timeout: 252 seconds]
<whitequark>
is it?
<whitequark>
what are you attacking and from where anyway
<rqou>
attacking the "trusted computing" device/environment to get native code exec and exfiltrate encrypted secrets
<rqou>
and/or backdooring the os in case of EL3/ME
<rqou>
given what I've heard about the code quality in these "trusted computing" environments, i definitely don't want them to have a web-exposed interface
<rqou>
but it's not inherently flawed
<rqou>
hence "I wonder how many people would take it seriously"
<awygle>
Hm, ATMega4809
<whitequark>
so you mean some sort of device that runs untrusted code but in a way that contains it and supposedly protects from interference, from both outside the device and other code on the same device?
<rqou>
yes
<rqou>
i know, browsers do that too
<whitequark>
no, browsers only do a half of this
<rqou>
ok, fine. normal "trusted computing" environments are supposed to do the other half
<rqou>
you can think of the idea as "replace the 'java' part of javacard with JS/WASM, but also allow anybody to deploy an applet to a card"
<rqou>
or maybe only the first half of that? that actually sounds not too unreasonable