mmicko has quit [Remote host closed the connection]
mmicko has joined ##openfpga
OmniMancer has joined ##openfpga
<omnitechnomancer>
whitequark: Can one add blackboxes in nmigen?
<omnitechnomancer>
And is there a guide somewhere on adding a new platform?
<whitequark>
blackboxes?
<whitequark>
do you mean Instances?
<omnitechnomancer>
probably
<whitequark>
as for a new platform, do you mean a new vendor (like Altera), or a new board (like DE0CV)?
<omnitechnomancer>
Things that neither yosys nor nmigen will know about
<omnitechnomancer>
for platform, both, I would like to target my Tang Primer which is Anlogic Eagle
Neuromod has joined ##openfpga
_whitelogger has joined ##openfpga
Neuromod has quit [Ping timeout: 268 seconds]
_whitelogger has joined ##openfpga
lopsided98 has quit [Quit: Disconnected]
lopsided98 has joined ##openfpga
etrig has joined ##openfpga
<omnitechnomancer>
wq ^^^
Bike has quit [Quit: Lost terminal]
<whitequark>
omnitechnomancer: yeah that's a bit complicated actually
<omnitechnomancer>
oh no :(
<whitequark>
you'll need to take a look at one of the nmigen/vendor/*.py files and do the same
<whitequark>
I think it might make sense to copy the Xilinx Ultrascale one, since it's one of the simplest currently
<whitequark>
or perhaps Intel one
<omnitechnomancer>
What are false paths btw?
<omnitechnomancer>
Ah I have found reading on the subject
<omnitechnomancer>
Is most of that file about the build system stuff?
<whitequark>
yep
<whitequark>
and a bunch of required primitives
emeb_mac has quit [Quit: Leaving.]
<omnitechnomancer>
can you avoid the build system thing by just making verilog?
<whitequark>
omnitechnomancer: nmigen emits verilog for all platforms with non-FOSS toolchains
<whitequark>
you can completely avoid any platform integration, sure, but the experience of actually using it will be much worse than for every other platform, since integration is there for a reason
<whitequark>
and if you don't override synchronizers properly then you shouldn't make any multiple clock domain design
<whitequark>
so it depends on your goals
<whitequark>
if you want anlogic to be supported as a tier 1 platform in nmigen, you have to do something similar to existing ones
<whitequark>
if you just want to hack together a bunch of code, absolutely do grab the verilog backend and go to town
Jybz has joined ##openfpga
<omnitechnomancer>
I see
<omnitechnomancer>
I'll have to look into that, I believe there is some synth ability in yosys for it but that still outputs Verilog for the vendor tools currently
<whitequark>
you don't need to look into anything
<whitequark>
you just use the nmigen verilog backend
<whitequark>
from nmigen.back.verilog import convert; print(convert(SomeElaboratable()))
<whitequark>
oh sorry, I misread
<whitequark>
in general nmigen always supports vendor toolchains (even for ice40), and if there's the FOSS toolchain, it supports that too
<whitequark>
so it's always worthwhile to add support for anlogic toolchain, regardless of what yosys does
<omnitechnomancer>
Indeed
<omnitechnomancer>
In the template stuff, which parts are template replacements and which parts are tcl in the ultrascale platform?
<whitequark>
{{}} and {%%} delimit jinja2 code
<omnitechnomancer>
So for ultrascale it is using the tcl api to insert the timing constraints or false paths on the synchonisers from attributes that are placed on the cells?
<whitequark>
correct
<whitequark>
i doubt anlogic supports anything like that
<whitequark>
do you have a link to some pdf describing their synthesis toolchain options?
<omnitechnomancer>
Is there some kind of common lineage among vendor tools or does everyone name everything the same for other reasons?
<whitequark>
hahaha nope
<whitequark>
even when there *is* common lineage (at least two neocad-derived tools, lots of stuff uses synplify) the options still pointlessly differ
<whitequark>
oh sorry i misread again, too sleep deprived for this conversation
<whitequark>
scratch what i said before. yes, lots of toolchains have some relation between each other. a lot of them use synplify on the frontend
<omnitechnomancer>
Um, I am not sure if I can find a PDF, I am not sure if there is any good documentation on the tcl side of things and if there is it likely is in chinese
<whitequark>
sure, give me a chinese pdf, i don't care
<omnitechnomancer>
Some of the tcl commands in the xilinx one look familiar though, but they are not the easiest thing to work out from the help stirngs
<whitequark>
it's not like the english ones are always very coherent, you have to guess what they mean a lot
<whitequark>
link me the toolchain too
<whitequark>
if this goes to nmigen upstream i'll need a copy locally
<omnitechnomancer>
You can get the toolchain to spit you out a tcl file for a project flow
<omnitechnomancer>
the actual synth commands are somewhat straightforward
<whitequark>
a lot of the time, instead of reading the documentation, i grep the toolchain folder for the command i want to understand
<whitequark>
is that um, their official download site
cr1901_modern has left ##openfpga [##openfpga]
<whitequark>
ok, it isn't, anlogic doesn't just distribute the toolchain to everyone
<omnitechnomancer>
That is not the anlogic official site, I believe Anlogic wants some kind of login to acquire anything
<omnitechnomancer>
even the documentation annoyingly
<whitequark>
how do you run the GUI?
<whitequark>
nvm, -gui
<whitequark>
hm
<whitequark>
did anlogic actually implement their own toolchain entirely from scratch (except for abc)?
<whitequark>
it's using Fehdl::Veri* and Fehdl::Vhdl* classes for the frontend for example, which have no google hits I can see
<whitequark>
and the consistency of naming for the rtl stuff seems to imply the same people (roughly speaking) did that too
cr1901_modern has joined ##openfpga
<omnitechnomancer>
I have not poked at any symbol names in the executable
Asu has joined ##openfpga
<omnitechnomancer>
I also haven no idea how much is from scratch, the gui feels familiar while not seeming exactly the same as other tools
<omnitechnomancer>
It definitely doesn't plaster synplify logos everywhere
<whitequark>
there's no synplify inside for sure
<whitequark>
or any other western proprietary IP
<whitequark>
it's just copying synplify commands
<whitequark>
they might not even be doing anything
<whitequark>
ok, so first you should get a basic flow working
<whitequark>
then figure out the right attributes once you know more about the arch
<omnitechnomancer>
The basic synth flow is pretty easy
<whitequark>
which family are you targeting btw?
<omnitechnomancer>
It does seem to like failing assertions in some cases (though this was me fiddling with post mapping slice blackboxes so connecting ports wrongly shouldnt be done)
<omnitechnomancer>
Eagle
<omnitechnomancer>
if you are using the tcl its the eagle_s20.db BG256 package on the board
<omnitechnomancer>
Let me just go grab the GUI name
<whitequark>
I just wanted to know which datasheet to look at
<whitequark>
i find the diagrams sufficient so far :)
<whitequark>
you should hook up the SDR and DDR primitives to nmigen
<whitequark>
in the vendor file
<omnitechnomancer>
yep
<whitequark>
seems... very similar to lattice fpgas
<omnitechnomancer>
If you want to look at the verilog modules for those they are in a file called eagle_macros.v
<omnitechnomancer>
it is quite similar to lattice fpgas
<omnitechnomancer>
well except it isnt turned 90 degress
<whitequark>
lol
<omnitechnomancer>
and y counts up from the bottom
<whitequark>
PCI clamp diode
<whitequark>
does anyone still use that? how old is this family?
<omnitechnomancer>
no idea
cr1901_modern has quit [Read error: Connection reset by peer]
<omnitechnomancer>
I believe that is what you use along with a current limiting resistor if you wnat 5v inputs
<whitequark>
2016. who the fuck still uses conventional PCI
<whitequark>
oh
<whitequark>
oh that makes sense
<omnitechnomancer>
It is used for the PCI mode on inputs though I believe but I have no idea who uses that :P
<gruetzkopf>
:D
<gruetzkopf>
me
<omnitechnomancer>
The slice diagrams are a bit annoying in that they leave out all the interesting useful parts
<omnitechnomancer>
and lie about signals
cr1901_modern has joined ##openfpga
<whitequark>
gruetzkopf: you still use relays, you're an outlier
<whitequark>
Relays Gruetzkopf is an outlier adn shouldn't have been counted
<omnitechnomancer>
Also I am reasonably certain that any LUT combining larger than 1 slice is not actually done by the toolchain and may in fact not work in the silicon
<daveshah>
I remember when looking at it before that Xilinx uses those muxes pretty rarely too
<daveshah>
But they do work and are used in some cases; the reason they don't is that they are comparatively slow
<whitequark>
why btw?
<gruetzkopf>
at least marshallh also uses conventional pci for some things, but we're talking to the same old stuff
<gruetzkopf>
some people here may have seen the silicon graphics onyx2 i brought to congress
<whitequark>
omnitechnomancer: ok, i skimmed their toolchain manual
<whitequark>
indeed you are supposed to use SDC constraints
<whitequark>
their timing analyzer is more advanced than i expected, actually
<whitequark>
i'm not entirely sure what's the best way to add constraints on synchronizers
<omnitechnomancer>
Yes SDC constraints, which is probably why the timing constraint commands look familiar
<whitequark>
it doesn't have set_max_delay like vivado does
<whitequark>
but iirc there was some more primitive method
<omnitechnomancer>
daveshah: the reason I am unsure of how working they are is that the slice sim models do not actually have any way to hook them up, but I am unsure what would actually output verilog with the slice models rather than the higher level blocks
<daveshah>
Do post pnr timing simulation netlists use the slice models?
<daveshah>
They do for ECP5
<omnitechnomancer>
Let me check, am unsure if you can convince it to produce a post PNR sim model
<omnitechnomancer>
It does produce a sim model that uses the slice models
<azonenberg>
So i'm reading more about the lecroy wavelink probes that they use for 13-25 GHz bandwidth. Pretty cool actually
<azonenberg>
The non-solder browser) tip uses a carbon composite pogo pin
<azonenberg>
it's simultaneously a probe tip and a terminating resistor for a transmission line probe architecture (there's active buffering further up the chain)
<whitequark>
azonenberg: question: is it possible/economical to make a tap for PCIe, or is my best bet just placing some transceivers in passthrough mode?
<whitequark>
replace PCIe with anything 8b10b at 2.5 or 5 G
<whitequark>
I'm thinking there could be a clock buffer and maybe a matching transformer per diffpair (?), but I don't know how to actually do it
<whitequark>
on the other hand using transceivers in passthrough mode is straightforward but it introduces latency and lots of other side effects
<azonenberg>
Honestly, i think you would get acceptable results by building a passive differential transmission line probe followed by a fast comparator to buffer the signal to a level strong enough for a transceiver to be able to read it
<azonenberg>
it might not pass pcie oob signaling right
<azonenberg>
but the actual 8b10b will go through just fine
<azonenberg>
you dont need a matching transformer
<azonenberg>
i'd use a couple of RF resistors on a solder-in probe tip then a HMC674 comparator on a reusable buffer module
<whitequark>
hang on
<whitequark>
i think this will work for 2.5 GT/s, but i'm not sure about 5 GT/s
<whitequark>
i've read that because of distortion and preemphasis, if you look at a 5 GT/s signal on a scope with a probe like that, you might not even see a closed eye
<whitequark>
and yet it receives just fine
<whitequark>
so... it seems like there would have to be a deemphasis circuit before the comparator?
<omnitechnomancer>
daveshah: oh the other reason is that it has AL_MAP_LUT<N> for N up to 6 but not further
<azonenberg>
There's a few options for that
<azonenberg>
let met find the one i was looking at
<azonenberg>
First off, i think the comparator is likely good enough. It has 9.3 GHz bandwidth, and can see ridiculously small differences between input signals
<azonenberg>
Like, a 7 series GTP needs a minimum 150 mV differential to reliably switch
<azonenberg>
The graphs for dispersion etc in the HMC674 datasheet go down to 10 mV overdrive
<whitequark>
actually, wait, you gave me an idea
<whitequark>
can I just use some sort of differential 1:2 buffer?
<whitequark>
do those exist?
<azonenberg>
Meaning you could attenuate the signal by 10:1 with a resistive probe, and still have a usably large eye
<azonenberg>
Oh, you're not trying to probe in circuit?
<azonenberg>
you're able to break the connection?
<whitequark>
I am making an interposer
<whitequark>
it's, well, PCIe
<whitequark>
connectors are involved.
<azonenberg>
That makes it vastly easier
<whitequark>
lol yeah should've mentioned that before you assumed I had the hard interesting problem :
<whitequark>
*:P
<azonenberg>
Something along the lines of an ADCLK905 is probably good. Look around on digikey under clock buffers and pick one that says it can also do data
<azonenberg>
sorry i meant ADCLK925
<whitequark>
oh sweet
<azonenberg>
Make sure the differential swing is correct, they come in different drive strength ranges too
<azonenberg>
that was just the first one i found in the search
<azonenberg>
Yeah see, what i had in mind was landing needles on a pcie trace
<azonenberg>
and reading TLPs off that way :p
<azonenberg>
Which is a much more fun problem
<whitequark>
hell no, I'm not paid enough to do that shit
<whitequark>
I'm just making a PHY/MAC
<azonenberg>
I think some of the probes i've been working on will be able to do that
<azonenberg>
This is a simulation of the probe trace, tip resistors, and sma connector match from a field solver model of the geometry. It's not perfect as the tip itself isn't included in the model
<azonenberg>
But we'll see how well reality matches simulation in a few weeks when i get probes back
<azonenberg>
at least, from 100 MHz out to around 3 GHz where my VNA tops out
<whitequark>
azonenberg: thanks for the tip re ADCLK925, there are examples in the datasheet with PCIe 2.5 and 5
<whitequark>
so it seems I can just use that one
<azonenberg>
Perfect
<azonenberg>
yeah being end of line is vastly easier than trying to probe midspan
<azonenberg>
because loading down the DUT is no longer a conecrn
<azonenberg>
you can fully terminate the line and redrive it
<whitequark>
yeah, I just didn't realize that data buffers exist... for some reason
<whitequark>
btw if you were making an interposer like that, how would you approach the test equipment side connector?
<azonenberg>
you can even get fancier ones that do preemphasis, equalization...
<azonenberg>
and even clock recovery and pll-based jitter cleaning
<whitequark>
my options are a bunch of SMAs or SFF-8087 or somesuch
<whitequark>
leaning towards the latter plus a board that breaks out SFF-8087 to SMAs for when I really want to probe it with a scope
<azonenberg>
How many lanes are you doing?
<whitequark>
two lanes will keep me occupied for next year
<azonenberg>
i like sata cables or similar for single diffpairs at higher speeds, because they're good out to 6+ Gbps and are well length matched
<whitequark>
but some day i'll do four
<whitequark>
hmmm
<azonenberg>
unlike SMA cables, which are individually cut to length and may have some variation unless you buy fancy delay-matched pairs of sma cables
<whitequark>
oh good point
<whitequark>
actually, there are sff-8087 to sata cables anyway
<azonenberg>
my suggestion would be to use some kind of twinax based cable to keep the length equal. One sata cable will do two 100 ohm diffpairs
<azonenberg>
but sas etc would work fine too
<azonenberg>
Then yes, make a fanout adapter to SMA if you need to do signal integrity work
<azonenberg>
If you just want an eye pattern, you may be able to integrate that pretty cheaply with some of the higher end redrivers
<whitequark>
I have a scope for that actually
<azonenberg>
They do BER based eye pattern monitoring like a lot of nice serdes do
<whitequark>
so SMAs work fine
<azonenberg>
basically take a sample of the signal offset in time or voltage from the actual rx sampling point
<whitequark>
oh
<azonenberg>
compare to the actual sample value
<whitequark>
yeah ECP5 SERDES can't do that
<whitequark>
it has no hardware features for it
<whitequark>
not even undocumented ones
<azonenberg>
yeah 7 series can, but you can get standalone buffers with this capability too
<azonenberg>
i was gonna use them on some of my backplanes possibly
<azonenberg>
Also you have a scope fast enough for pcie signal integrity?
<azonenberg>
is this via m-labs? last i checked you had a cheap rigol :p
<whitequark>
nope, not m-labs
<whitequark>
the scope can do 50G
<whitequark>
sampling of course
<whitequark>
not real-time
<azonenberg>
GHz or Gsps?
<whitequark>
although i only have heads up to 20G
<whitequark>
GHz
<azonenberg>
what model?
<whitequark>
tek 11801b
<azonenberg>
Makes my shiny new HDO9204 i have on the way look pretty weak lol. 2 GHz bw, 20 Gsps on 4ch / 40 Gsps interleaved
<azonenberg>
and 200 Gsps in equivalent time mode
<whitequark>
it does 200 ksps (not a typo) sampling rate
<whitequark>
what's worse, it is so heavy you actually can't ship it internationally
<whitequark>
massive CRT inside, and the rest isn't exactly lightweight either
<azonenberg>
i bet OOCL would beg to disagree
<whitequark>
OOCL?
<azonenberg>
orient overseas container line, HK based container ship company :p
<azonenberg>
(i think hk based at least)
<whitequark>
oh, i don't live in hk anymore
<whitequark>
the weather damn near killed me
<azonenberg>
Of course, if you need a full container to ship your scope... :p
<azonenberg>
back in .ru now or what?
<whitequark>
yeah
<whitequark>
for now at least
<whitequark>
one thing i want to play with that 11801b has is TDR head
<azonenberg>
ooh
<azonenberg>
Yeah i should be able to do some fun tdr-ing with my scopes and the 40ps risetime pulse gen i got
<whitequark>
they cost 2x as much as the scope tho
<azonenberg>
Lol
<whitequark>
like the head alone
<azonenberg>
Unsurprising
<azonenberg>
oh also, that reminds me of a new protocol decoder i wanted to add to scopehal
<azonenberg>
"current shunt"
<whitequark>
i actually disassembled one of my sampling only head
<whitequark>
and it has TDR LEDs mounted inside
<whitequark>
blindly into an aluminium wall
<azonenberg>
basically it transforms a voltage reading across a shunt resistor into a current reading
<whitequark>
i wonder if it's just a EEPROM change, cuz the PCB has no missing components
<whitequark>
seems like an extreme form of market segmentation though
<azonenberg>
The test equipment market routinely subsidizes expensive R&D by inflating prices of other stuff
<azonenberg>
So that doesnt surprise me in the slightest
<whitequark>
i almost want to RE the firmware and find out which bit to flip, but that seems like an incredible pain in the ass
<whitequark>
the scope fw lives on 11 (eleven) parallel EEPROM chips
<whitequark>
on three different MCU boards
<azonenberg>
lol
<azonenberg>
yeeeah no thanks
<whitequark>
and even disassembling that thing is a nightmare
<azonenberg>
i might consider hacking a modern windows baased lecroy, because i actually know how to RE that :p
<azonenberg>
But not something ancient like that
<whitequark>
the service manual tells you multiple times to not do something because it will tear the cables
<whitequark>
so i'm just not gonna do it
<omnitechnomancer>
the datasheets claim there are only 3 plls in this chip but the toolchain seems to think all 4 are usable
<whitequark>
azonenberg: oh, looks like sff-8643 actually has a standard (ish) pcie signal assignment even
<azonenberg>
Even better
<whitequark>
so i can be actually in compliance with intended use of that connector
<whitequark>
the (ish) is because a bunch of vendors decided to do exactly what i decided to do and they ended up all incompatible
<whitequark>
but it looks like that got sorted out
<azonenberg>
Perfect. So you can actually make a standards compliant test fixture then
<whitequark>
exactly
<whitequark>
and it wouldn't be as stupid as pcie 3.0 compliance baseboard
<whitequark>
which is just a zillion SMAs on a massive PCB that costs thousands of dollars
<azonenberg>
The only thing i'm not sure you might need is support for pcie oob signaling
<azonenberg>
i dont know if thats a must or only for power management type applications
<whitequark>
hmmm
<whitequark>
it is only for link power management
<whitequark>
if you mean low frequency signals on the diffpairs that is
<azonenberg>
well in particular i dont know if the buffer is gonna start spitting out nonsense if the input goes to differential idle
<whitequark>
oh right EIDLE, let me check that buffer
<azonenberg>
in the link-up state i have minimal concerns
mumptai has joined ##openfpga
<whitequark>
there's also the beacon thing
<azonenberg>
Somewhat related: if you need some basic field solver modeling stuff done for f/oss projects, i bought the basic edition of Sonnet recently
<azonenberg>
So if you need to do more detailed SI modeling of something that may help
<whitequark>
aha, thanks
<azonenberg>
obviously if it was for a paying project i'd expect some compensation, but for f/oss work as long as it wasn't too much of a time commitment i could do the modeling free
<whitequark>
hm yeah EIDLE could be an issue
<whitequark>
azonenberg: oh another Q. suppose I want to make a PCIe card that would have two SFF-8643 connectors on it (one towards DUT, one towards test equipment)
<whitequark>
and suppose sometimes I want to use it just as a PCIe to SFF-8643 adapter
<whitequark>
should I make two assembly variants, one with resistors instead of clock buffers or something? (if yes, how do I avoid having stubs that distort signals, etc?)
<azonenberg>
If it's buffered, you can safely float the unused output port
<whitequark>
or should I find a data fanout buffer with output enable?
<whitequark>
aha, I can just float it
<azonenberg>
you'll waste a little bit of power but not a big deal
<whitequark>
I wasn't sure about leaving it open
<whitequark>
wouldn't that radiate or something
<whitequark>
I could always make an SFF-8643 terminator but that is effort
<azonenberg>
you could always put optional solder in terminators on the pcb instead of the sff connector
<whitequark>
oooh good idea
<whitequark>
thanks!
<azonenberg>
in fact, you could reuse the pads of the ac coupling caps for the sff connector (assuming you ac couple the outputs)
<azonenberg>
an 0402 pad is symmetric 0.5mm square
<whitequark>
yep
<whitequark>
I discovered that pcbway assembly is pretty cheap so now I can just use normal sized components
<azonenberg>
so you can easily put a 1:2 hardware programmed mux in an ac coupled line
<azonenberg>
with no impact on SI
<azonenberg>
just have a 3-pad footprints and load one or the other orientation
<whitequark>
wouldn't that be more like one 4-pad footprint?
<azonenberg>
No, 3 pad. One pad on the transmission line going to the buffer, one going to the SFF, one going to ground
<azonenberg>
load either a cap from 1-2 or resistor from 2-3 as appropriate
<azonenberg>
from 1-3*
<whitequark>
oh, terminate to ground
<azonenberg>
or vcc
<azonenberg>
depends on the specific iostandard of the buffer
<whitequark>
not to another half of the pair
<whitequark>
I really need to read up on transmission line theory
<whitequark>
I don't understand diffpairs very well
<azonenberg>
you could also terminate between the pads if the transmission line is engineered with a 1mm trace gap
<azonenberg>
then an 0402 100R would seamlessly fit across them
<whitequark>
gotcha, thanks
<gruetzkopf>
what's the assignment of clocks, #perst and stuff to the sideband pins?
<whitequark>
gruetzkopf: do you want any specific one?
<whitequark>
ideally explain the spec to me in case i misunderstood it
<gruetzkopf>
i meant "is there a common assignment of these to the sff8643 sideband pins"
<whitequark>
oh, look at SFF-9402
<whitequark>
looks like REFCLKpn is C1D1 on root side, C2D2 on device side
<whitequark>
and PERST#/CPRSNT# is C2D2 on root side, C1D1 on device side
<gruetzkopf>
ah, good
<gruetzkopf>
i'm still looking for connectors to do the stupid thing on my laptop and steal 2*4 lanes off the CPU<->GPU link
<whitequark>
sff-8654 or sff-8643 seem equally valid
<whitequark>
sff-8643 seems way more common
<whitequark>
oh, sff-8087 and sff-8643 are basically the same thing
<whitequark>
just in 1 or 2 rows
<whitequark>
azonenberg: turns out there are COTS adapters I can get
<whitequark>
so all I need is to make a data buffer that is effectively a tee
<flow>
I am trying to figure out how much delay one of the 127 dynamic delay taps of the ECP5 DELAYF input blocks causes? The Technical Note "ECP5 and ECP5-5G High-Speed I/O Interface" gives a description of that block but does not state where to find the delay.
<daveshah>
From memory, some rough experiments found it is about 40ps
<flow>
Thank you so much :)
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
Jybz has quit [Client Quit]
Jybz has joined ##openfpga
emeb_mac has joined ##openfpga
<kbeckmann>
noopwafel: wonder if you could use that delay line for precise glitching? maybe combine with the dynamic phase configuration of the PLL. also i wonder if you can chain the two PLLs together to get even more resolution in the phase shift.
<noopwafel>
haha
<noopwafel>
so yes, you can, and it works :-)
<kbeckmann>
:D
<noopwafel>
our horrible ice40 hack uses a PLL delay to achieve fairly good resolution
<noopwafel>
I didn't port it properly to the ECP5 because I think I'd rather rewrite in nmigen (or in any case, rewrite)
<ktemkin>
I've done a similar thing with the ice40 fixed delay block, too
<noopwafel>
it's such a useful trick for improving glitch length in particular
<ktemkin>
also, if you use it to equivalently-time sample an internal signal, and then decimate the binary samples you get, it decimates to something that approximates the voltage-shape of the wave
<noopwafel>
ohh, that's also neat
<ktemkin>
(i.e. you use it to phase-offset the sample point, and then phase-step through the equivalent-time periods)
<noopwafel>
the idea of equivalently-time sampling internally using it
<ktemkin>
the best part is that while you'd normally worry about metastability when sampling with arbitrary clock skew, that actually helps you
<ktemkin>
since there's a correlation between the voltage at the sample point and the probability of the settling value after a metastability event
<noopwafel>
(glitch attempts are colored by response, y axis is voltage)
<kbeckmann>
oh that's neat
<noopwafel>
but one of (many) reasons why I'm so excited about these cheap fpga boards, even if you can do this basic stuff beautifully on the icebreaker.
<noopwafel>
erm, icestick. maybe the icebreaker, but the clock speed is difficult :)
<kbeckmann>
ecp5 should be able to run quite a bit faster than ice40 i think, so that'll be interesting to see what you can do with it. also you have the ddr blocks.
<ktemkin>
I really should port some of my old stuff to the ECP5
<kbeckmann>
also, would you benefit from a very accurate clock source? so the variance goes down between glitches, and also consecutive glitches?
<ktemkin>
considering I've recently been making a habit of making myself ECP5 boards
<noopwafel>
the iceglitch hack I dumped on github at CCC uses the PLL fixed delay, plus the DDR I/O
<noopwafel>
for the cheap-and-fun stuff I think is best for accessibility, it's kind of nice not to rely on anything external :)
<ktemkin>
kbeckmann: depends if you're looking to explore or to have things quickly reproducible, I'd think
<noopwafel>
and at some point you start fighting jitter a lot
<noopwafel>
and to do this 'nicely' you likely want a high-speed DAC, which kind of means you have to start taking clock source seriously..
<kbeckmann>
right. i just remember @stacksmashing mentioning that it was problematic (but not impossible) when you had to glitch multiple instructions after eachother. but you'd probably also need an accurate clock on the target for it to make sense as well.
<kbeckmann>
i guess having an accurate clock on the fpga can't be bad at least :)
<noopwafel>
right, it's super interesting to play with!
<ktemkin>
noopwafel: are you also pressuring Colin to switch over to using ECP5s?
<noopwafel>
as ktemkin said, for exploring the jitter can actually be kind of neat
<kbeckmann>
miek just helped me out with an sdr pmod where we use the si514 i2c controlled clock generator with a quite high accuracy and low jitter. might build a pmod with only that chip for easy access.
<kbeckmann>
ah i see. but i guess for reproducibility you don't want the jitter.
<noopwafel>
ktemkin: I have been occasionally mentioning, but I think others have been doing it more :-)
<noopwafel>
the open source toolchain just makes this stuff ridiculously easier to experiment with, rather than just having a bunch of verilog basically rotting away :/
<ktemkin>
I had to use the closed-source toolchain again when I was doing some hacking on the early phywhisperer stuff, and toolchain whiplash is real
<noopwafel>
kbeckmann: I approve of other people building things that I can have fun experimenting with, as you know :-)
<ktemkin>
going back to Vivado after doing all ECP5 stuff recently made me stop my hacking on it faster than I should have
<kbeckmann>
:) just let me know if you have more ideas and don't want to build the hardware yourself, i don't mind.
<noopwafel>
the last time I touched their toolchain it was back to ISE. it was not great.
<noopwafel>
kbeckmann: so I think it's a great idea to at least talk about these things with a larger group of people, but I think for me there's so much random stuff to experiment with before you know what works..
mkru has joined ##openfpga
<kbeckmann>
with the quick pcb services these days i think it's fine to experiment with building pcbs, breadboards tend to introduce too much setup/teardown overhead and errors (in my experience). also with larger groups there will be opinions and discussions, more fun to just build stuff and see if it works :). but of course what you're saying makes sense.
<noopwafel>
so we got surprisingly far with protoboarded PMODs too!