<azonenberg>
cr1901_modern: My scope has a Vref that has 12 bit resolution from 0 to 3.3V
<azonenberg>
When you attenuate a 3.3V signal by 20x, plus the 2x attenuation i already had in the PCB, you get a 40x weaker signal
<azonenberg>
or 82.5 mV p-p
<azonenberg>
One DAC code is ~0.8 mV
<azonenberg>
so i only have about a hundred steps from 0 to 3.3 at the input
<azonenberg>
Which jives nicely with the data i'm collecting
<azonenberg>
But it means most of my 12 bits of resolution is being wasted
<azonenberg>
I may have to add a front end with a bit of gain to make full use of the comparator
<azonenberg>
alternate strategy: use a DAC with higher resolution, and just accept that the top ~90% of the range won't get used ever
<azonenberg>
i.e. if i have a 16 bit DAC and only use codes 0 to 2^11-1 have 11 bit resolution with a 16-bit dac, and didn't have to deal with the hassles of an ultra wideband front end amplifier
<azonenberg>
But this makes my circuit a lot more sensitive to noise
<cr1901_modern>
azonenberg: Cool, good explanation. But why not just reduce vref of the DAC for the purposes of this test?
<azonenberg>
you're missing the point
<azonenberg>
And, that would require reworking the board as i think this is vdd referenced
<azonenberg>
at a minimum i'd have to swap some pins around
<azonenberg>
Even if i did, though, i still have to live with the fact that my comparator input is low tens of mV p-p
<azonenberg>
which means <1 mV of supply noise or coupled interference is a Big Deal
<azonenberg>
My 100 Gsps design may end up living under an EMI can or something just to keep that sensitive input clean
<azonenberg>
And require ultra super duper stable power rails
<azonenberg>
Right now my board is being fed by the 3.3V PMOD supply which is not exactly clean
digshadow has joined ##openfpga
<azonenberg>
When i build the 100 Gsps design i'll probably take in 5V from the expansion card rail then LDO down to whatever voltage i need
<azonenberg>
add some ferrites to reduce noise on vdd, etc
<azonenberg>
With the 1x probe 1 mV p-p of supply ripple was no big deal
<azonenberg>
But now, especially with a vdd-referenced dac, it basically cuts one bit off my vertical resolution
<azonenberg>
Anyway, this is separate from the other issue
<azonenberg>
Namely, I have not observed a risetime faster than ~1 ns in my current design
<azonenberg>
and i don't know if this is b/c my front end is limiting risetime, or because a 7-series IOB is really that slow
<cr1901_modern>
"it basically cuts one bit off my vertical resolution"?
<azonenberg>
cr1901_modern: ok not quite 1 bit but, with an R-2R type DAC
<azonenberg>
if i have 1 mV of supply ripple on Vdd
<azonenberg>
I'm going to get 0.5 mV ripple on Vout
<azonenberg>
at mid-scale
<azonenberg>
(which is where an AC-coupled signal is going to naturally live)
UmbralRaptor has quit [Ping timeout: 255 seconds]
<azonenberg>
one LSB in my design is about 0.8 mV
UmbralRaptor has joined ##openfpga
<cr1901_modern>
azonenberg: You could do a integral/differential error analysis I'd imagine to figure out the true loss of resolution :). I'm not going to do it at 3AM, but thought I'd offer
<azonenberg>
I'm not going to just yet
<azonenberg>
I can see the jittering in the plot :p
sgstair_ has joined ##openfpga
sgstair has quit [Disconnected by services]
sgstair_ is now known as sgstair
mifune has quit [Ping timeout: 260 seconds]
<rqou>
azonenberg, digshadow: not a coolrunner2, but I just picked up an alleged xc95288 for the decap pile
<azonenberg>
Cool
<azonenberg>
I dont have one of those yet
<azonenberg>
If you can find any 2c384/512 those are worth looking at
<azonenberg>
especially if they're legit :p
<rqou>
got some old Broadcom switch parts
<digshadow>
rqou: fwiw lab activities are basically down right now
<digshadow>
no ETA at time time
<digshadow>
this
<azonenberg>
digshadow: well i happen to be ramping back up at $WORK
<azonenberg>
So, good timing :p
<rqou>
btw it's pretty funny how all the sellers are asking me "wtf do you want this for" and my Mandarin isn't good enough to explain to them
<azonenberg>
Lol
<azonenberg>
You are technically a chinese citizen no? :p
<digshadow>
rqou: fwiw you do know I have a pretty large stockpile of xilinx chips right
<digshadow>
dev boards even
<digshadow>
ex: I have an xc2018 dev board
<azonenberg>
digshadow: we have tubes upon tubes of plcc xc4000 parts floating around IOA
<azonenberg>
i can probably get permission to decap some, its not like we need them for anything
<azonenberg>
So if you ever need extras...
<azonenberg>
(i know you have images of most of the family already)
<rqou>
seller here claims to have 512 and 384, hope they're legit :P
<rqou>
ooh shit these are NV
<digshadow>
rqou: why are you interested in that particular part
<rqou>
azonenberg: we need a way to pull bitstreams from them :P
<rqou>
512 and 384 are the ones we're missing images of in the coolrunner2 family
<digshadow>
ah right
<azonenberg>
rqou: lol we are not going to pull bitstreams from them
<azonenberg>
what good is that?
<azonenberg>
(assuming they're even functional)
<azonenberg>
digshadow: i got a 384 once and it was fake
<azonenberg>
from ebay, not digikey etc
<digshadow>
rqou: more regarding the xc95288
<digshadow>
was that a dumpster dive?
<rqou>
these are almost definitely pulls from a commercial product
<digshadow>
or purchased
<azonenberg>
digshadow: we dont have pics of it either
<rqou>
so we can steal their IP :P
<azonenberg>
it was the last xc9500xl missing
<digshadow>
azonenberg: well FWIW I have piles of xilinx chips, decapped and not, that aren't photod I think
<azonenberg>
digshadow: funny thing is, i decapped the chip, it turned out to be a TI die and not a xilinx part
<digshadow>
ah
<azonenberg>
So i contacted the ebay seller
<azonenberg>
sent them a die shot
<azonenberg>
and was like "i want my money back"
<azonenberg>
:p
<davidc__>
azonenberg: good luck with that
<digshadow>
azonenberg: and they did right
<azonenberg>
Yes
<azonenberg>
I got a full refund, i was amazed
<digshadow>
ebay will almost always side by the buyer
<azonenberg>
Anyway, gonna get to sleep soon but had a fun night of playing with the scope
<azonenberg>
Tomorrow going to try and finish debugging this weird coolrunner macrocell issue
<digshadow>
azonenberg: haven't been paying attention
<digshadow>
is xc2c support getting revamped?
<azonenberg>
Yes
<digshadow>
cool
<azonenberg>
i wrote a generic PAR engine for crossbar-based devices
<azonenberg>
rqou is porting it to yosys
<azonenberg>
i meant
<azonenberg>
to coolrunner
<digshadow>
very nice
<azonenberg>
and adding yosys synthesis support (which was not possible at the time of my recon talk)
<azonenberg>
We collectively RE'd the entire xc2c32a bitstream and have good progress toward the rest of the family
<azonenberg>
i'm currently writing an artix7 based emulator that runs xc2c32a bitstreams in real time on hardware
<azonenberg>
like, you hook a jtag dongle up to a pmod
<azonenberg>
and it sees a coolrunner
<digshadow>
azonenberg: I have a kcu105 you can remote into
<azonenberg>
and other than lower fmax it works (in theory) the same as the real chip
<digshadow>
if thats ever useful
<digshadow>
on that note
<azonenberg>
At the moment, no... the 2c32a fits in a 7a100t
<azonenberg>
I have a 7a200t
<digshadow>
I have a giant pile of kc705 node locked vivado licenses
<azonenberg>
digshadow: anyway i have the combinatorial engine workign correctly, i think, but having issues with the macrocell flipflops
<azonenberg>
counters are not counting correctly
<azonenberg>
i need to investigate but its getting late
<rqou>
is vivado vulnerable to the old "lmcrypt" trick?
<azonenberg>
When i get everything working i'm gonna try and make a JIT
<azonenberg>
For lulz
<digshadow>
rqou: last time I uh...investigated...vivado
<digshadow>
it was not very secure
<azonenberg>
i.e. jtag in a coolrunner bitstream then turn it into lut equations for SRLC32Es
<davidc__>
define secure?
<rqou>
is it still lmcrypt with short keys?
<davidc__>
Oh, uh, in terms of licensing
<digshadow>
davidc__: first time I ever used gdb
<digshadow>
took about 15 min
<rqou>
(xor-based symmetric keys vs EC keys)
<azonenberg>
digshadow: i think he means for secureip
<davidc__>
Also, amusing thought: Amazon rents FPGAs. Amazon presumably has tooling to compile the bitstreams, since you don't want random people handing un-DRC'ed bitstreams to the FPGA
<davidc__>
Anyone fuzzed vivado? ;)
<digshadow>
davidc__: I was talking to nedos last week
<digshadow>
I think it was him anyway
<azonenberg>
i've segfaulted ISE, but no reliable mem corruption
<azonenberg>
not that i was trying
<digshadow>
anyway someone was saying you have to rent time on amazon servers to compile for amazon servers
<azonenberg>
havent looked at vivado yet
<digshadow>
davidc__: the .bit format has null terminated strings in it
<digshadow>
I always wondered what would happen if they weren't
<azonenberg>
lol
<rqou>
try fuzzing pcie host controllers as well? :P
<rqou>
I know Google fuzzed iommus and they passed
<azonenberg>
digshadow: also i forget if i mentioned but i want to try to make a polyglot that's a 7-series bitstream, a zip file, and a few other things
<azonenberg>
maybe a BMP
<azonenberg>
that should be almost a freebie
<digshadow>
yeah you did
<digshadow>
i'm sure corkami would approve
<rqou>
that sounds pretty trivial
<azonenberg>
rqou: yes, doing it without overlap is trivial
<azonenberg>
the fun part will be trying to RE enough of the bitstream format (maybe do spartan3a to start?)
<azonenberg>
so that you can actually overlap content
<azonenberg>
e.g. use block ram init values as parts of another file
<azonenberg>
or lut equations, etc
<azonenberg>
ooh i know, make it an ELF
<azonenberg>
a ZIP
<azonenberg>
and a bitstream
<azonenberg>
make the ELF be something that talks over uart to the fpga
<azonenberg>
... running that bitstream
<azonenberg>
then the zip would contain the source or something
<azonenberg>
With ELF if you are careful and fragment the code enough
<davidc__>
bonus points if the bitsream contains a softcore
<davidc__>
with a program in a bram
<azonenberg>
That would use enough of the fpga (i was thinking xc3s50a) that you wouldnt have much left to store ELF content in
<azonenberg>
you only have three brams total
<azonenberg>
you'd have to do fairly extensive bitstream RE to make that work
<digshadow>
azonenberg: is the xilinx bitstream magic always the same
<azonenberg>
But xc3s50a is my next target after i finish
<azonenberg>
define magic
<digshadow>
could you put multiple bitstreams in one file
<digshadow>
the sync word
<azonenberg>
Almost
<azonenberg>
it's aa995566 for everything but s3a which is aa99
<azonenberg>
i.e. 16 bits onnly
<davidc__>
azonenberg: IIRC there's some kind of row/col addr
<davidc__>
right?
<digshadow>
actually maybe it wouldn't matter
<digshadow>
since it might ignore wrong target
<azonenberg>
it wont ignore, it'll fail to boot
<davidc__>
what if you put stuff at non-existant addresses
<azonenberg>
i.e. the idcode write will fail
<azonenberg>
davidc__: thaaaat would be interesting
<rqou>
wait there's a potential s3a RE?
<azonenberg>
i dont actually know
<azonenberg>
rqou: yes, that is my next target after xc2c and gp4
<azonenberg>
probably in parallel with gp5
<davidc__>
azonenberg: or, just rewrite the same col over and over
<digshadow>
didn't wolfspraul re s3
<rqou>
why not artix-7?
<azonenberg>
rqou: Because s3 is expendable and simple
<azonenberg>
and similar enough to modern stuff that i should be able to translate a lot of what i learn
<rqou>
or porting ice40 to vpr just to see if that works?
<azonenberg>
i'll likely skip s6
<azonenberg>
go from s3 to 7
<azonenberg>
since s6 is kinda the winME of xilinx
<rqou>
I would go straight to 7
<azonenberg>
and no wolfspraul looked at s6 and i think a bit of a7
<azonenberg>
a7 has a lot of complex hard ip etc
<rqou>
can't you just ignore those initially?
<azonenberg>
yes but
<azonenberg>
s3 is easy to completely (100%) support
<azonenberg>
That would be valuable
<azonenberg>
basically you have iobs, slice logic, bram, mults, and dcms
<azonenberg>
thats it
<rqou>
in parallel I would like to see ice40 vpr support
<digshadow>
azonenberg: someone did
<digshadow>
debit
<azonenberg>
ok i'll look at that
<digshadow>
not sure how complete it is
<azonenberg>
But i wasn't super interested in s3 for the sake of s3
<rqou>
iirc arachne-pnr can't be scaled to larger devices?
<azonenberg>
i would likely redo it from scratch anyway for my own education
<rqou>
iirc debit is s6
<azonenberg>
before attempting a larger device
<rqou>
wasn't debit sb0's project?
<digshadow>
rqou: it has at least v2
<azonenberg>
And s3 is simple enough it'd be a good training subject
<digshadow>
and I think s3 as well
<digshadow>
rqou: don't think so
<azonenberg>
aaanyway, let's get xc2c and gp4 to mostly-finished/finished state
<azonenberg>
then try and at least kick gp5 in the right direction
<azonenberg>
my gp4 stuff is on hold for a few weeks until i get al lthe boards i need for timing analysis, so i'm working on the cr2 emulator
<digshadow>
bah google code is dead
<rqou>
azonenberg we need to sort out how to make necessary changes to xbpar (FFI or not)
<azonenberg>
rqou: Now is not the time, i'm about to get to sleep
<azonenberg>
I want to refactor a bunch of stuff on xbpar anyway, i also have some yaks to shave in yosys
<rqou>
oh huh almost 1am
<azonenberg>
as far as preserving names through synthesis better
<azonenberg>
and not having $auto$abc$ blah
<azonenberg>
:p
<azonenberg>
i think it should be possible to go to a more xilinx-y naming scheme
<azonenberg>
something like Mxor_foo_bar_ or something
<azonenberg>
that at least gives hints as to what's going into that primitive
<rqou>
anyways, the worst part of the FFI right now is the fact that there's std:: vector in a bunch of methods
<rqou>
maybe that can get refactored a bit
<azonenberg>
Well, i was never intending xbpar to be used by anything but native C++ :p
<azonenberg>
And i still stand by my original statement that having half the project in another language is a recipe for disaster
<rqou>
the "sea of pointers" is bad for rust but probably ok for other languages
<rqou>
meh, I feel your c++ has a ton of boilerplate to e.g. parse json
<azonenberg>
A lot of that could probably get fixed by refactorign
<rqou>
i guess mine has a ton of boilerplate to use the correct indices :P
<azonenberg>
this was my first time using this json lib
<azonenberg>
lol
<rqou>
this was also my first time using serde-json
<rqou>
except serde-json is magic, and json-c isn't magic :P