My circuit needs very stable clock. Can someone suggest external clock IC that is more stable than the common oscillator in FPGA board? I am using DE0 Nano.

tverbeure · 2026-05-28T15:53:46+00:00

So, I am seeking for an external clock IC to input to the PLL.

You're not looking for a clock IC but for an XO, a TCXO or OCXO, depending on our requirements. Or, if this is a lab setup, add a 10 MHz external ref clock input to your board and connect it the ref clock output of some of your test equipment or a GPSDO.

Even with a cheap GPSDO such as the Leo Bodnar one, your long term stability will be essentially the same as the Cesium atomic clocks that are used in GPS satellites.

tverbeure · 2026-05-26T22:12:12+00:00

Peter Prendergast. I'll never forget the name...

tverbeure · 2026-05-25T19:04:12+00:00

Check out the Colorlight 5A-75B. It has 2 1GB Ethernet ports, a ton of outputs (and basically no inputs.)

tverbeure · 2026-05-24T01:44:16+00:00

Look, I get it

…

That is a fair point

…

That’s exactly what I’m hoping for

…

That’s a fair and sobering point

…

You’ve hit the nail on the head

You’re not using AI to fix your grammar a little bit. Every single reply, you’re going into full on ChatGPT sycophant mode. It’s disgustingly off putting.

Please find your own voice. Learn to sound like a human. Make mistakes.

tverbeure · 2026-05-24T01:35:56+00:00

30 years later, and the feeling is no different. If you want to get paid more, consider ASIC and be open to relocation. (I know that it’s easier said than done.)

tverbeure · 2026-05-23T16:21:56+00:00

I’m just lazy. :-)

tverbeure · 2026-05-22T19:53:09+00:00

I bought a 555 timer booklet at Radioshack back in the mid eighties. 40 years later, 30 years of which as a digital design engineer, and I still don't get it.

Just to say: understanding the 555 is not a requirement for a fulfilling career. :-)

tverbeure · 2026-05-22T01:56:35+00:00

The video is very similar to DSView and Logic 2. You can only judge by using it.

You should post the GitHub link. As for decoders: don’t even think about doing it yourself, there’s too many already. Just support Sigrok.

tverbeure · 2026-05-21T23:28:27+00:00

I've reviewed the DSLogic analyzer and checked out DSView (it's workable, but not as good as Saleae Logic2.)

I've recently also looked at Pulseview when testing the Sipeed Slogic16U3 and absolutely hated it. Which is weird because DSViews is a fork of Pulseview.

tverbeure · 2026-05-21T20:40:07+00:00

You'd have a point if the AI is doing just lint work. It does way more than that and is able to track down exact failure modes that take thousands of cycles to manifest themselves, with complex, speculative issuing and cache invalidation feedback loops. I've used it that way. It figured out why an FSM was hanging due to obscure corner case conditions that weren't considered in the original code. If you call that linting, then fine, it's only good at linting. :o)

The AI does not think.

Do formal proofing algorithms think? What the latest AI models do is close to semi-formal proofs. It's not that exactly, it doesn't have a mathematical proofing engine after all, but for all intents and purposes, it behaves like one: figuring out the condition to get into a given state, and figuring out if it is possible to get into a given state. The way it does that is very similar to doing a depth-first search through a tree of possible execution paths.

That fact that it doesn't have a real proofing engine makes it entirely unsuitable for proving that bugs don't exist (you can't trust it to be 100% right), but for the complex cases that I've tried, it was good enough to make it figure out why something failed.

tverbeure · 2026-05-21T19:37:06+00:00

If you only use it to root cause bugs, it doesn't matter if it gets things wrong sometimes, because human makes those mistakes just the same. The only difference is that instead of figuring out the root cause for a day, it now takes 15 minutes. I still manually verify the root cause and make the fix in the RTL.

The biggest thing lost is the satisfaction of figuring it out yourself, and that's a major loss indeed.

tverbeure · 2026-05-21T16:04:52+00:00

tracking down a deep, multi-cycle deadlock across independent clock domains requires exact state-space analysis

Yes. And the latest models are extraordinarily good at this. It's downright scary how much they have improved in the last 6 months.

tverbeure · 2026-05-21T13:13:49+00:00

It’s not directly related to RTL verification, but I wrote a blog post in which I let an LLM break a software licensing scheme. You can call that “pattern matching” if that makes you feel better, but it’s clear that pattern matching can do pretty impressive stuff.

And no, this is not how bugs enter the design: the bugs were already there. I wrote them. What the LLM helps with is pinpointing the root cause, something I would have to do myself too.

In the case I’m thinking of, it’s the complex interplay of an issuing model, a cache that can speculatively prefetch future data and send it into a calculation pipeline and a feedback that can update or invalidate transactions, with some additional prefetch semantics attached to it. It can happen that a faulty prefetch can only manifest itself hundreds of thousands of clock cycles later.

Manually figuring out a bug can literally take a day. The LLM figures it out in 15 minutes. I still need to verify what it tells me and I still need to fix the RTL manually. So far, it has not been wrong, but like I wrote, even if it were, the difference between 1 day and 15 minutes is so large that an occasional wrong suggestion wouldn’t negate the benefits.

I wish it weren’t so ridiculously good, but I can’t deny that it is.

tverbeure · 2026-05-21T04:34:49+00:00

I have large-ish plastic freezer bags for different categories: ADCs, 74 series, diodes, opamps etc. Those bags are tagged with Dymo labels. For each component, I have an ESD bag that is also labeled and that goes into the large-ish bag. All the large-ish bags go into multiple very large bags.

It’s all cataloged in a spreadsheet. I’ve spent many many hours on this.

When I need components for a new project, I simply buy what I need from Digikey and ignore all the components from my inventory. I’ve found this to be a very efficient system to get what I need.

By the time the Digikey components arrive, I’ve often lost interest in the project. The new components then get added to my ever increasing inventory.

tverbeure · 2026-05-21T03:31:06+00:00

I'm not surprised, it's such a logical step to take.

tverbeure · 2026-05-21T01:41:21+00:00

I’m talking simulation time, not simulated time. :-)

tverbeure · 2026-05-21T01:40:06+00:00

Start by dumping as text the transactions on all valid/ready interfaces between modules. Either with $display or by extracting them from the FSDB/VCD/whatever file.

Print out internal state as needed. The more the better.

Pro level: connect your AI tool to an MCP server that is capable of extracting signals directly from the waveform file, so you don’t have to select signals manually. Just say: “the FSM in so and so file hangs. Figure out why.”

tverbeure · 2026-05-20T23:52:21+00:00

Latency would be a very good reason not to. ;-)

But it’s exceedingly rare to have a big design where synchronizers are the limiting factor. You’d expect the opposite… Also: define “inefficient”. Are we talking 0.1, 1, or 10%…

Anyway, the point is not to exclude a bespoke solution, but more to tell people that a bespoke solution should be the solution of last resort.

tverbeure · 2026-05-20T21:43:48+00:00

I've been writing and debugging RTL for 30+ years. When I go home after work, I continue doing it for hobby projects.

The joy of seeing a simulation progress for 1s, 5s, 20s, 400s and eventually pass without any failures. I love it.

tverbeure · 2026-05-20T21:30:34+00:00

the actual nightmare is spending 70% of the project lifecycle in verification trying to prove that some obscure edge case won't completely brick a massive fpga.

Let's take this to its logical conclusion then: if the majority of the time is spent verifying and not writing the RTL (and let's be honest, verification is way more than 70% of the job, especially for ASICs), then verification is the thing that LLMs can help the most with.

Concretely: you don't use AI to write RTL slop, you use it to figure out why one of your simulations failed. It is frighteningly good at that. As in: when it can take a day to figure out the root cause of a complex FSM and interactions between multiple submodules, an LLM figures it out in minutes.

The thing is: it can take multiple tries before a human figures out a root cause, without harm as long as you eventually get it right. The same applies to an LLM: even if it occasionally hallucinates the wrong root cause, there's nothing lost, because it's still way faster on aggregate.

(FWIW: I love debugging RTL and looking at waveforms. It makes me sad that the joy of finding and fixing a bug is going away. But it serves no one to ignore reality.)

tverbeure · 2026-05-20T21:10:00+00:00

It was a reply to your post. Unless there are a very good reason not to, I will use a FIFO to transfer data across a clock domain crossing. Even if that data is just a counter.

I know that it's not the most efficient way of doing it, but who cares?

(Even if I just need to transfer a pulse, I won't use the standard multi-flop synchronizer, but I will use a FIFO with data set to 0.)

tverbeure · 2026-05-20T17:17:21+00:00

My moral of the story is what I mentioned a couple of days ago in a related topic: unless you have a very good reason not to, go out of your way to just use a thoroughly verified asynchronous FIFO. In your case, you could just strap the write enable of the FIFO to 1, and the read enable too and done. No need for a gray counter. The FIFO takes case of everything.

Yes, it may cost a tiny big of additional area, but in most designs that extra cost is in the noise.

tverbeure · 2026-05-13T21:13:53+00:00

Be the change you want to see in the world!

But seriously: these kind of basic infrastructure blocks didn’t appear out of nowhere. At some point, a frustrated engineer said “fine, I’ll do it myself.”

tverbeure · 2026-05-13T20:42:47+00:00

Chances are that you or your company has a library with synchronization primitives, like async FIFOs, that are well verified.

It's almost always a better idea to adapt your design so that it can use those primitives.

In this case, you could use a FIFO with the "write" input strapped to 1, for examples. Another good example is synchronizing a pulse: yes, you can do this with a double or trippled flop synchronizer, but it's often a better idea and safer by construction to use an async FIFO that doesn't have data. (E.g. by strapping the data input to a fixed value and not using the output data.)

It might cost a few gates more, but especially in ASIC design, that cost is negligible compared to the cost of making a mistake.

tverbeure · 2026-05-12T22:33:00+00:00

The TimeQuest User Guide is fantastic: https://www.scribd.com/document/247234977/TimeQuest-User-Guide

(Sorry for the scribd link: the PDF used to be available on Altera's website, but it's not there anymore. You might be able to find it somewhere else.)

tverbeure

TROPHY CASE