Re: ANY(ONE can code

We had that trouble with Cambridge graduates. They knew their stuff, but if you didn't ask the question using exactly the right jargon, they didn't know what you meant. If you beat around the bush for a bit you could mostly get them talking, but some of them were addicted to their specialist jargon, and wouldn't condescend to talk to people who didn't use it.

You have a compulsive need to insult. It's obviously driven by a deep feeling of inadequacy.

The electron-beam tester I put together at Cambridge

That's awfully complex. Sounds expensive. What was the minimum delay? What was the jitter?

Minimum delay and low jitter are both selling points in a DDG. So is cost.

Our first output edge from trigger rips through our board with just prop delay. We get connector-to-connector minimum delays down to around 20 ns.

That part is expensive and awful. It's not accurate and has gobs of jitter and temperature drift.

Fortunately, the 10EP195 is obsolete.

ECL is a pain. We use some of the GigaComm parts when there is a payoff, which is rare.

That was a factual observation. You obviously didn't like it, but it isn't actually insulting. The only feelings of inadequacy involved seem to be yours - you seem to think that you had done an adequate job, and resent the observation that you hadn't.

It was.

It was that too. To get down to 5psec granularity at at the time I had to use Gigabit Logics GaAs synchronous counters, and they weren't cheap. They got loaded onto 6-layer triple extended eurocards, with the two outer layers as isocyanate bonded teflon cloth. Each board cost 1500 UK pounds, bare, and carried about 1500 UK pounds worth of integrated circuits.

AS I said, 60psec - due to the crap 800MHz oscillator I ended up having to use. We knew how to get hold of something better, but since we were generating pulse widths that only got down to 500psec, reducing the jitter wasn't a problem that needed urgent attention.

Obviously. Performance also matters. The boss insisted that offering better than 10psec granularity was essential to let him sell the machine, which was nuts, but he was the boss.

That would have been nice, but we wanted our longer delays to be accurate. We locked our 800MHz oscillator to 10MHz referenced crystal, so the longer delays were accurate.

The data sheet claims about 1psec of clock jitter, which isn't "gobs".

It definitely suffers from temperature drift, and the machine was designed to autocalibrate every few minutes to cope with that - it would have taken a few milliseconds to run through every delay, setting up mark-to-space waveforms and digitising the average voltage to link the delays back to crystal clock period. I was a bit surprised by speed that seemed to be possible. Our tame programmer was happy with the scheme.

The ON-Semiconductor website labels the MC100EP195 part as "active".

It has the supreme virtue of not infesting the power rails with switching hash. People who do a lot of analog design like that. It's also fast, and was designed to drive terminated transmission lines.

One of my engineers made the same sort of observation around 1985, and when I said that it had always worked me, he responded, "but you are an analog engineer". I was also pretty good with digital devices, but some people are nervous about analog.

I'd prefer to be number 0x100000!

Cheers, Gerhard

Am 18.08.25 um 17:44 schrieb john larkin:

I have inherited a 8270 from a local ham and opened it only to get the 10811A xtal ocillator. There is also an additional start/stop osc board in case anybody is interested. I prefer my Stanford SR-620.

Cheers, Gerhard

Am 19.08.25 um 13:09 schrieb john larkin:

I do love ECL, ever since the 100K family appeared.

Fast, clean supplies, clean impedances, controlled rise/fall times... Not like that sh***y CMOS on steroids.

Around 1979, I built a real time signal averager that could keep up with a TRW 8 bit 20 MHSPS ADC. The ADC was bleeding edge; we got also a nekkid chip in an epoxy? cube, being a pilot customer.

It took 8 interleaved 74LS/S computation units to do the job; a few years later I migrated that to a dual ECL implementation while increasing ADC speed to 200 MHz.

When FPGAs became available we used them as the final solution because less power burnt meant more miles of oil/gas pipeline inspected with ultrasonics per run.

3rd picture from top, The blurred part in the background is the original 74(L)S version; the one board on top replaced the entire 19" crate with 10 times the speed. The 200 MHz control machine is still ECL.

Cheers, Gerhard

Am 18.08.25 um 17:47 schrieb john larkin:

You learn that when you write your 1st grammar parser using YACC or bison. :-)

Gerhard

Yes. That regular expressions / yacc / lex / awk stuff was really meant to generate hardware state machines in Weinberger arrays, a structure not unlike a PAL but not user programmable. The w in awk stands for Mr. Weinberger, the a for Mr. Aho, the k for Mr. Kernighan, known for the C language, The Unix group at Bell was a generation ahead, maybe two.

Gerhard

I used that chip (the 1038 iirc) a few years later. I recall being surprised by its crappy aperture uncertainty spec. Flash converters weren’t that good for that.

Cheers

Phil Hobbs

We use Keysight 53220s. They are OK but have a lot of jitter.

It would be fun to make a sub-ps jitter TIC, but I guess there's no market.

I see parts, logic and oscillators, with fs jitter specs. I suppose people use high-end oscilloscopes to measure them, or some indirect trick.

The advantage of thinking in state machines is that you are forced to deal with every system state. In a "modern" computer system you have multiple threads and tasks and semaphores and fifo's and IRQs and undocumented libraries and DLLs and interrupts all happening mostly asynchronously, with layers of abstraction to make it more fun. The number of states is more than photons in the universe and the number of possible bugs is a lot bigger.

Self-documenting of course. Comments are so last millenium.

What's interesting is when input states can change any time, including deep inside a clump of procedural state processing logic. That's a classic hardware state machine hazard too.

Am 22.08.25 um 16:39 schrieb john larkin:

What makes me really wonder with the SR-620: How can such a small transformer feed that tablet of ECL!

Somehow all counters end at 5ps resolution.

I think it is harder than it looks at first sight. pulse width / delay is relatively easy; it can be tested with 2 nearly synchronous oscillators with the second one sliding next to the other over a span of several hours, but watch the air conditioning. That is also ok for linearity versus phase.

For linearity vs. rise/fall times: I have no idea how to guarantee that. Or temperature changes.

A little birdie told me yesterday that our ISS SPAD experiment has seen first laser photons from the earth in the expected ps window. :-)

Gerhard

To make a sub ps time interval counter, the real challenge isn't architecture but the circuit design details. Temperature alone will be a jitter contributor.

Experiments like that are OK, but why have an ISS full of people along for the ride? For the cost of those people, a lot more science could be done. Thousands of cubesats, or maybe millions.

I see pictures of hurricanes and stuff taken from the ISS. I think we have better ways to take pictures.

That's what latches are for. Also set-up times, hold times and propagation delays. I know that there are people who ignore them - I've had to clean up after them - but anybody who even pretends to be a hardware engineer needs to do better.

I enjoyed seeing the photo of your lab at the very end. It reminded me of this article by Jim Williams:

If it can't be solved with a state machine or Laplace transform I'm out of ideas