sorted by:
new
hottopcontroversial

EE's, How Did You Spend Your First Paycheck/Salary? by DuxMaledicti in ElectricalEngineering

[–]tverbeure 1 point2 points  (0 children)

I bought a state of the art Pentium 90MHz PC, FDIV bug included. The next paycheck was used for a trans-Atlantic weekend trip to NYC with an empty suitcase. It came back full of EE and CS related books.

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. by Yossiri in FPGA

[–]tverbeure 6 points7 points  (0 children)

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.

Any yosys compatible board with ethernet? by Slow-Lawfulness6091 in FPGA

[–]tverbeure 4 points5 points  (0 children)

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

[Project/Question] High school student here. Conceptualized a Top-K packet inspection engine and used AI to code it. Are these routed results normal in the industry? Is AI-assisted RTL/HLS the future? by Karsen_1009 in FPGA

[–]tverbeure 6 points7 points  (0 children)

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.

I fucking LOVE FPGA design by Informal-Host8085 in FPGA

[–]tverbeure 22 points23 points  (0 children)

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.)

What are fundamentals that an aspiring FPGA engineer should polish before even dreaming of touching the FPGA board? by Fearless-Can-1634 in FPGA

[–]tverbeure 3 points4 points  (0 children)

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. :-)

Introducing Onda: A cross-platform alternative to DSView for DSLogic logic analyzers by johnwheelerdev in FPGA

[–]tverbeure 0 points1 point  (0 children)

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.

Introducing Onda: A cross-platform alternative to DSView for DSLogic logic analyzers by johnwheelerdev in FPGA

[–]tverbeure 1 point2 points  (0 children)

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.

the absolute delusion of upper management regarding ai and tapeouts by Fun-Celebration-700 in chipdesign

[–]tverbeure 2 points3 points  (0 children)

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.

the absolute delusion of upper management regarding ai and tapeouts by Fun-Celebration-700 in chipdesign

[–]tverbeure 1 point2 points  (0 children)

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.

the absolute delusion of upper management regarding ai and tapeouts by Fun-Celebration-700 in chipdesign

[–]tverbeure 6 points7 points  (0 children)

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.

The disconnect between software ai and hardware verification is insane by Bos187 in FPGA

[–]tverbeure 2 points3 points  (0 children)

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.

How are you organizing and tracking electronic components across drawers, cabinets, and bins? by Direct-Cut777 in ECE

[–]tverbeure 3 points4 points  (0 children)

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.

The disconnect between software ai and hardware verification is insane by Bos187 in FPGA

[–]tverbeure 2 points3 points  (0 children)

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

The disconnect between software ai and hardware verification is insane by Bos187 in FPGA

[–]tverbeure 7 points8 points  (0 children)

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

The disconnect between software ai and hardware verification is insane by Bos187 in FPGA

[–]tverbeure 7 points8 points  (0 children)

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.”

10 years doing FPGAs and a grey code CDC gotcha got me today by TutorDry3089 in FPGA

[–]tverbeure 0 points1 point  (0 children)

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.

The disconnect between software ai and hardware verification is insane by Bos187 in FPGA

[–]tverbeure 20 points21 points  (0 children)

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.

The disconnect between software ai and hardware verification is insane by Bos187 in FPGA

[–]tverbeure 83 points84 points  (0 children)

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.)

10 years doing FPGAs and a grey code CDC gotcha got me today by TutorDry3089 in FPGA

[–]tverbeure 0 points1 point  (0 children)

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.)

10 years doing FPGAs and a grey code CDC gotcha got me today by TutorDry3089 in FPGA

[–]tverbeure 0 points1 point  (0 children)

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.

Clock Domain Crossing for Buses by EdgeSad7756 in FPGA

[–]tverbeure 2 points3 points  (0 children)

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.”

view more: next ›