<hackerfoo>
I think the next thing I'd get is a microscope. I can do without a preheater by preheating the board with hot air.
<eddyb>
does anyone have a demo of a "ring oscillator being sampled by the main clock" RNG example for iCE40? do the tools support that kind of circuit?
<eddyb>
I've being told that it should work
<Sprite_tm>
Ring oscillator works, at least on the ICE40. I;m using one as the main osc as I didn't realize the thing doesn't have an internal oscillator :/
<azonenberg>
usb 2.0 B on one side, 2.0 A on the other, then two SMAs connecting to the signals with integrated 20:1 probes
<eddyb>
Sprite_tm: does timing analysis work w/ a ring oscillator as the main clock?
<Sprite_tm>
Oooh, soo gold-plated
<azonenberg>
I'm building one of these test fixtures for every protocol i write a decoder for that has standard connectors
<azonenberg>
I won't be doing usb3 any time soon as my scope doesnt have the bandwidth
<azonenberg>
but i'll be able to read usb 1.x / 2.0 off the wire
<Sprite_tm>
eddyb: If you assume that the ring osc isn't all of a sudden going faster than whatever freq you set the main clock to be for the timing analysis, there's no issue.
<Sprite_tm>
It won't figure out what that's going to be by itself, the ring osc more-or-less is an opaque black blox to the software.
<Sprite_tm>
azonenberg: And here's me looking at the professional devboard which I use to validate the USB MAC and write the ROM-code for an upcoming chip... and the 2.54mm headers and the dupont wires to the LA...
<Sprite_tm>
It's usb low/full-speed only, so it should be fine :P
<azonenberg>
well i'm trying to make these test fixtures good enough to do compliance testing with
<azonenberg>
not just signal recovery
<Sprite_tm>
Ah, you do need something fancy'er for that indeed.
<Sprite_tm>
I think we handed compliance testing of the phy off to an external lab; the devboard I have has an external phy instead so it doesn't need to be tested.
<azonenberg>
this is the kind of stuff my software can do on SGMII / 1000base-X
<azonenberg>
i plan to have at least this level of USB decoding integrated as well
<azonenberg>
then the ability to export pcaps for more extensive analysis in wireshark
<Sprite_tm>
Oooh, does that tool also support Rigol MSO5Ks?
<eddyb>
Sprite_tm: aww. but you can use the same timing rules the software is using, to figure out the frequency?
<azonenberg>
As of now there is a well developed lecroy VICP back end, an experimental lecroy/siglent raw SCPI back end, and that's it
<azonenberg>
eddyb: you could find min/max
<azonenberg>
Sprite_tm: Rigol scope support is planned, but i don't have a (working) rigol to test on
<Sprite_tm>
I do :) but iirc it also talks SCPI, so it may be a quick adoptation.
<azonenberg>
well SCPI commands for scopes arent super well standardized
<azonenberg>
e.g. the waveform download binary format is totally vendor specific
<eddyb>
would be neat to plug in a clock duration instead of a frequency, in the timimg analysis, to avoid computing a rounded 1/t
<Sprite_tm>
Mmm, wanna build a LA pod for my scope first... kinda got set back because the LVDS comparators I ordered... well... most generous reading is that they accidentally forgot to put the silicon in them.
<azonenberg>
You need to create a new driver class for each protocol, although you could certainly plug in bits and pieces
<eddyb>
you can round up, I guess
<azonenberg>
the lecroy driver is a good reference implementation for several kinds of instrument
<azonenberg>
scopehal/Oscilloscope.h has all of the functions you have to override
<Sprite_tm>
Mmm, sounds like something to look into, when I have time.
<azonenberg>
If you are seriously interested in adding a rigol backend i'll gladly work with you to make it happen
<azonenberg>
I just dont have the time or hardware to do it myself right now
<Sprite_tm>
Heh, I have the hw, but the time bit is kinda a thing :)
<tnt>
azonenberg: is that using network to get samples btw ? Might be my code, but retrieving traces off my agilent 3000-x takes ages. (like ... a couple seconds).
<azonenberg>
tnt: most scopes are very slow for waveform download in my experience
<azonenberg>
I get ~10 FPS for short (50k point) waveforms off my waverunner 8104, down to 1-2 FPS for deep (1M point)
<azonenberg>
the wavesurfer 3034 is significantly slower, 1-2 FPS for the shortest waveforms
<azonenberg>
The lecroy backend is ethernet based, but you could totally support usb direct connections as well
<azonenberg>
if a scope supports both i would prefer the driver to support both
<azonenberg>
or at least separate the command/API layer from the transport layer
<azonenberg>
like i did with the lecroy driver
<azonenberg>
i doubt usb would be faster than lan though
<azonenberg>
in general, my experience is that typical scopes are simply not optimized for remote operation
<tnt>
yeah, I'm guess internally the gneeral purpose cpu only has a slow channel to go read the ASIC memory.
<azonenberg>
Which is one of the reasons that a longer term plan is to build custom f/oss acquisition hardware intended to hit thousands of WFM/s over ethernet
<azonenberg>
tnt: i cant speak to the low-end lecroys or other vendors
<azonenberg>
but the high-end lecroys are a pcie acquisition card plugged into what's basically a bog-standard atx motherboard
<azonenberg>
my waverunner runs windows 7 embedded edition and has an i5 with 8GB of RAM
<azonenberg>
My planned high-end scope is going to be a completely different architecture
<azonenberg>
The plan is a 3U Eurocard chassis with 1/10G serial links (TBD ethernet or custom protocol) on the backplane, plus a 10 MHz OCXO refclk distributed to each channel card
<azonenberg>
then an I/O card with a 1G (for "legacy" baseT gear) and 10G or 40G SFP+/QSFP+ as the primary connection to the host
<azonenberg>
then each channel card will have one or more SMA/BNC signal inputs
<tnt>
10 MHz only ?
<azonenberg>
10 MHz seems to be the standard refclk for test equipment
<azonenberg>
every function generator i've seen uses it
<azonenberg>
my waverunner has 10 MHz input and output
<azonenberg>
so you can sync multiple scopes' PLLs to the same refclk and have phase aligned capture
<tnt>
higher end one are moving to 100 MHz to improve the sync between them.
<azonenberg>
i might support several frequencies then
<azonenberg>
Internally, whatever refclk i have will go into a (tentatively) LMK04806
<azonenberg>
on each line card
<azonenberg>
then multiply up to drive the actual ADC acquisition clock
<azonenberg>
The advantage of 10 is that you can feed it from a GPSDO
<azonenberg>
But the PLL has a pretty wide input range so i can make it flexible
<azonenberg>
The I/O card will have SMA refclk in/out as well as the ethernet ports on the front, and pretty much be the brain of the whole operation
<futarisIRCcloud>
10 MHz is the same input for most hacker SDRs too, e.g. HackRF.
<azonenberg>
the backplane will be entirely passive
<azonenberg>
Line cards can have one or more ADCs on them with arbitrary configuration, so you could for example have a card with two ADCs and two inputs and selectable interleaving
<azonenberg>
you'll be able to mix them arbitrarily and they'll remain phase aligned
<azonenberg>
so for example you could hypothetically have one card configured with interleaving, one 20 Gsps input
<azonenberg>
another identical card non-interleaved as two 10 Gsps inputs
<azonenberg>
and then another one be 500 Msps 12-bit
<azonenberg>
With a switchable 18 GHz sample-and-hold in front of it
<azonenberg>
(these are not arbitrary numbers, they're actual tentatively planned designs)
<azonenberg>
This is one of the reasons glscopeclient shows the channel depth, sample rate, etc in the channel label and not in the status bar
<azonenberg>
Because it doesn't assume channels have identical sample rates
<azonenberg>
Some math functions are naive and assume the inputs are the same rate, but many of the more sophisticated protocol decodes are already multi-rate aware
<azonenberg>
and will check timestamps of each sample and handle e.g. clock and data sampled at different rates
<azonenberg>
Anyway, that hardware is a long ways out and i have several massive projects to do between now and then :)
sensille_ is now known as sensille
<Sprite_tm>
Possibly already useful if you want to use e.g. a cheapie scope and a cheapie LA together tho'.
<Sprite_tm>
Use two backends, mangle the data together in the frontend.
<Sprite_tm>
Just sync up the trigger and you're gtg.
<azonenberg>
Yes, in fact i have that working in tests already between my 10/20 and 2/4 Gsps lecroy scopes
<azonenberg>
another planned use case is DSO + ILA
<azonenberg>
It's multi-source capable from the start and will continue to be that way
<azonenberg>
although the trigger handling in the UI still needs some work to make it usable
<whitequark>
mithro: yes. T12 is a cartridge type. there are lots of controllers. I have one similar to your 1st link
<whitequark>
I don't know anything about TS100, never held one in my hand
<whitequark>
could be good, could be not
m4ssi has joined ##openfpga
emeb_mac has quit [Ping timeout: 255 seconds]
Asu has joined ##openfpga
Asu` has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
rohitksingh_work has joined ##openfpga
Asu` has quit [Remote host closed the connection]
duck227 is now known as duck2
vup2_ has quit [Quit: vup2_]
vup2 has joined ##openfpga
gsi__ is now known as gsi_
<SolraBizna>
I'm looking at I²C RTCs, and every datasheet I've looked at so far completely lacks information on registers, etc.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
ondrej3 has joined ##openfpga
m_t has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 244 seconds]
_whitelogger has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
X-Scale has quit [Ping timeout: 245 seconds]
genii has joined ##openfpga
Asu has joined ##openfpga
carl0s has joined ##openfpga
catplant has quit [Ping timeout: 252 seconds]
mumptai has joined ##openfpga
X-Scale has joined ##openfpga
Laksen has joined ##openfpga
emeb has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
mumptai has quit [Quit: Verlassend]
jevinskie has joined ##openfpga
jevinskie has quit [Client Quit]
<SolraBizna>
how evil am I if I rely exclusively on CRESET as a way to reset my core?
<whitequark>
CRESET?
<tnt>
I'm assuming just the fpga POR.
<tnt>
I'd advise against it ...
<whitequark>
it's fine if you do something for BRAMs
<whitequark>
on ice40 it does not win you much
<SolraBizna>
resets the whole FPGA and makes it do configuration over again
<whitequark>
since you have the global reset lines that can go everywhere
<tnt>
but then for instance you can't use PLLs.
<SolraBizna>
I can't?
<tnt>
well no ... the clock wouldn't be stable ... your logic might get in weird state.
<tnt>
all logic clocked by a PLL should be held in reset until such a time as the LOCKED is asserted.
<SolraBizna>
oh, right... having a real reset line would actually be a really easy way to do that
<tnt>
for the ice40 just make sure to use async reset.
<whitequark>
async reset with sync release.
<tnt>
yes
vup2 is now known as vup
pie__ has joined ##openfpga
pie___ has quit [Remote host closed the connection]
vup has quit [Quit: vup]
vup has joined ##openfpga
<tnt>
Huh, I managed to make a design that has nextpnr looping forever in the routing phase.
<tnt>
(well for one particular seed at least
<daveshah>
It's actually surprising this doesn't happen more often given how the router algorithm works
<tnt>
daveshah: do you think there is timing improvement to be had in the router or is this placer only ?
<daveshah>
There's definitely significant room for timing improvement in the router
<daveshah>
Particularly in terms of how it chooses nets to rip up
<daveshah>
Also looking at rerouting nets with negative slack at the end
<tnt>
does it route them in order of "criticality" ?
<daveshah>
Budget currently
<daveshah>
Which should be the same ordering if there is a single clock domain
m_t has quit [Read error: Connection reset by peer]
<SolraBizna>
last stupid question of the day involves MOSFETs as switches
<SolraBizna>
I have an LED that I want to power when a control signal is at a logic low, so I want a p-type enhancement MOSFET, right?
<tnt>
yes, that'd work.
<SolraBizna>
(good, I was pretty confident about that half)
<whitequark>
depletion mode MOSFETs aren't really used anymore
<SolraBizna>
the other half is that I want to have a switch that "enables" one of two CS# lines
<SolraBizna>
p-type enhancement MOSFET for one, n-type enhancement MOSFET for the other?
<SolraBizna>
I saw a table that made me think I'd need an n-type depletion MOSFET, and my brain turned to Jell-O when I tried to look into it further myself
<tnt>
nope
<tnt>
you can't use a p-type to pull something to ground
<SolraBizna>
can't I use it to "drain out" a line that is pulled high?
<tnt>
a p-type depletion mode and a n-type enhancement mode might work.
<tnt>
SolraBizna: no, because as you "drain it out", you reduce Vgs ...
<tnt>
so you could only lower it down to Vth
<SolraBizna>
ah
<SolraBizna>
is there a simulator I can use to quadruple-check my circuit before blowing my one shot at getting it manufactured?