mwk has quit [Read error: Connection reset by peer]
mwk has joined #glasgow
FFY00 has quit [Ping timeout: 240 seconds]
FFY00 has joined #glasgow
Sellerie has quit [Quit: Ping timeout (120 seconds)]
Sellerie has joined #glasgow
<d1b2>
<Attie> not sure if anyone can offer input here... i'm looking to increase the sample frequency for the frequency counter applet... using a PLL
<d1b2>
<Attie> but it's giving lots of zero values, which is unexpected
<_whitenotifier-f>
[glasgow] attie synchronize pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTU6D
<d1b2>
<Attie> see the last commit in #216
<d1b2>
<Attie> it seems that when running at >100MHz, things go wonky
<_whitenotifier-f>
[glasgow] attie synchronize pull request #216: applet.interface.freq_counter: implement a frequency and duty-cycle counter - https://git.io/JTU6D
<whitequark>
Attie: i'm increasingly unconvinced this should be a core aplet
<whitequark>
*applet
<d1b2>
<Attie> oh, mind me asking how come?
<whitequark>
it's complex and does many different things. that's not to say that makes it bad, it's more that it doesn't necessarily fit my idea of a core applet
<whitequark>
it's less "frequency counter" now and more "signal statistics", is it?
<d1b2>
<Attie> yeah, that's fair
<d1b2>
<Attie> my initial goal was frequency & duty cycle
<electronic_eel>
I'd call it "frequency counter with some signal validity checks"
<d1b2>
<Attie> this gives those, but also the min/max values over the sample period
<d1b2>
<Attie> which help with validation (FM, noise, glitches, etc...), but i'd accept aren't really the job of a frequency counter
<whitequark>
i think there's definitely value in having a basic frequency counter that's also very reliable
<whitequark>
i wonder if it should be using a ripple counter instead of more common kinds of logic
<whitequark>
this lets you do away with PLLs
<whitequark>
bsaically, what i'm thinking of is a ripple counter with async clear and enable resynchronized to the input signal
<whitequark>
(you only need to enable the 0th bit in a ripple counter)
<whitequark>
this way you only use the main FPGA clock as a frequency standard, not to actually count anything
<d1b2>
<Attie> so the input signal would go into the first flipflop, in the comb domain?
<whitequark>
what i don't like about the PLL plan is that in that case, the FPGA becomes the limiting factor
<whitequark>
this isn't inherently bad but we can do better than that, therefore we should
<electronic_eel>
don't the better freq counters have statistics modes too?
<whitequark>
sure, but that's on top of being a good frequency counter
<electronic_eel>
I'd say the question is what you want to use it for. do you want the most accurate frequency counting -> ripple counter. or is there some unknown signal and you want to characterize it -> high/low statistics like attie did it
<whitequark>
the applet is called "frequency counter"
<whitequark>
and a frequency counter is something i'd like to have as a baseline
<d1b2>
<Attie> i'm back... just catching up
<d1b2>
<Attie> " we can do better than that, therefore we should " - i'm game for this... perhaps moving what I've currently got into a basic "signal analysis" role
<whitequark>
doing a ripple counter will be a bit tricky
<d1b2>
<Attie> heh, oh no
<whitequark>
first you'll need to set up some indirection
<whitequark>
add glasgow.gateware.ripple (see gateware.pll for an example), then a new method in platform.ice40
<whitequark>
the actual counter should use SB_* primitives
<d1b2>
<Attie> indirection to behave somewhat like an "un-clocked" FFSync?
<whitequark>
yes, same kind of deal
<whitequark>
each of the stages is a TFF, so a DFF plus INV in a LUT; you'll need to use a LUT with a 0101010101010101 table
<whitequark>
using one of the inputs leads to better timings, i don't recall if it's I0 or I3
<d1b2>
<Attie> i'll need to go away and look into TFF / DVV
<whitequark>
TFF is just a "toggle flip flop"
<d1b2>
<Attie> ah okay
<d1b2>
<Attie> *s/DVV/DFF/
<whitequark>
it's an uncommon term in FPGAs, I worked with CPLDs a bit
<d1b2>
<Attie> " using one of the inputs leads to better timings " - interesting - is that measured/reversed, or documented?
<whitequark>
it's something you can glean from the official toolchain
<whitequark>
but also, think of how a LUT works
<whitequark>
it's 4 muxes in a row
<whitequark>
well, a 4-deep tree of muxes
<whitequark>
naturally if you drive the mux nearmost to the output, you will have the best timings
<d1b2>
<Attie> I'm willing to have a go at a more vanila frequency counter, but it feels like you have ideas of what it should look like, and I might get it wrong / go off track
<d1b2>
<Attie> are you okay for me to continue?
<whitequark>
sure
<whitequark>
you can start with submitting a PR for a ripple counter alone
<whitequark>
the way i described
<d1b2>
<Attie> ok
<whitequark>
i'll walk you through if you get something wrong, so don't worry there
<d1b2>
<Attie> thanks
<d1b2>
<Attie> i'll relocate the current PR to applet/analysis/basic or similar?
<d1b2>
<Attie> and put this new in applet/analysis/frequency ?
<whitequark>
i'd prefer to merge a ripple based frequency counter before thinking about this PR at all
<whitequark>
it's possible we can compute statistics with ripple counters too