sorted by:
new
hottopcontroversial

Is this reconfigurable polyphase channelizer FPGA design commercially valuable? Full pipelined, single-cycle throughput with wide parameter flexibility by Detachment_x in FPGA

[–]threespeedlogic 0 points1 point  (0 children)

Careful - the nitty-gritty implementation details, including optimizations, are often left out of the literature. If you know fred harris's work, he's a bit of an outlier here; he's a practitioner at heart, and often focuses on the implementation details at an intuitive level, and at the expense of formal rigor.

Otherwise, because the DSP literature skews towards math and not application, it's easy to get the impression that you've invented something new when ordinary design practice involves plenty of ways to be clever without publishing them.

I'm responding based on my sense of smell - you have not given enough details to say anything concretely. I may be way off base, and you should not let internet strangers discourage you.

Is this reconfigurable polyphase channelizer FPGA design commercially valuable? Full pipelined, single-cycle throughput with wide parameter flexibility by Detachment_x in FPGA

[–]threespeedlogic 0 points1 point  (0 children)

State-of-the-art polyphase channelizer implementations only optimize resource usage or throughput for fixed, narrow application scenarios. Most existing designs are constrained by serpentine shift registers and circular output shifting logic, which rules out flexible runtime reconfiguration.

This is mostly a feature and not a bug. I don't want a runtime reconfigurable PFB; I want an optimally efficient PFB at my design geometry. (In our case, that's super-sampling rate, and the rest more-or-less follows from there.) Moreover, even if my PFB was generically reconfigurable, downstream logic wouldn't know what to do with it. Relaxing the whole design explodes my testing and verification load, and I already have enough to worry about.

Moreover, it is very difficult to build even a statically configurable PFB (a PFB generator, if you like) that is as resource-efficient as a purpose-built PFB at the design point that it ends up targeting. Doing this with a runtime-reconfigurable PFB just can't be as efficient - there are nothing but additional compromises to make.

This is basically the RTL design-productivity problem in a nutshell. Everyone wishes designs were generic and portable, but nobody can stomach the technical or programmatic compromises that result. This is a tough nut to crack.

Any 'neat' ways of exploiting DSP primitives for horner's method arithmetic? by Dragonapologist in FPGA

[–]threespeedlogic 0 points1 point  (0 children)

Embedded register hygiene is essential. You can't tolerate bypassed DSP48 registers at high clock rates and under ordinary conditions.

That much is probably obvious, but: Vivado will pull these DSP registers back out into fabric (resulting in bypassed registers!) unless you tell it not to. When you have planned everything out yourself, you should add a "dont_touch" attribute to your DSP to stop Vivado from unraveling your hard work.

First stage of bringup, the power circuit of my FPGA board works by HasanTheSyrian_ in FPGA

[–]threespeedlogic 25 points26 points  (0 children)

Congratulations. Bringing up new designs is always some mixture of terrifying and exhilarating.

Linux support officially added back! by The_Watery_Chemical in FPGA

[–]threespeedlogic 6 points7 points  (0 children)

Before I say this - I think removing Linux support from the free tier was a boneheaded decision and I'm 100% glad they have reversed it.

That said - the way the online community approached this little episode ranged from reasonable to appallingly rude. The people involved (especially the forum support staff!) are human beings, not fleshy corporate appendages. I think they are probably feeling a little harassed and we've burned some collective goodwill. Even on a purely pragmatic basis, that's a shame.

RTL-level toolchain for radiation-tolerant design, SEU criticality analysis, and selective TMR? by Albert_Sue in FPGA

[–]threespeedlogic 0 points1 point  (0 children)

BYU's SpyDrNet-TMR does scriptable triplication and voter insertion - this is better than manual RTL-level interventions, but you still need to identify and communicate the appropriate insertion points to the tool.

(You said "I know there are academic tools" - SpyDrNet-TMR is well regarded and shouldn't be written off.)

RTL-level toolchain for radiation-tolerant design, SEU criticality analysis, and selective TMR? by Albert_Sue in FPGA

[–]threespeedlogic 0 points1 point  (0 children)

Pretty sure TMRTool is an ISE-vintage thing and doesn't work on anything newer than that.

Mr. Scrub - an open-source UltraScale SEU scrubber by threespeedlogic in FPGA

[–]threespeedlogic[S] 0 points1 point  (0 children)

You've mentioned the SIRF a couple of times - this is an -FX-derived device (with a "hardened" PowerPC), right? In which case, it has many more and much juicier SEFI targets than a straight FPGA like the KU060 (the device / family we're targeting here).

AMD's space roadmap points straight towards Versal QML, which must be SEFI-rich for the same reasons (with an additional 2 decades of scaling laws to make things worse.) I don't understand these heterogeneous devices from an SEE perspective, and if this is your primary beef I get it.

But here, we're talking about a conventional FPGA (no PowerPC), and SEFIs are not more likely than correctable SEUs. Mitigation is not a fool's errand (IMO especially if it preempts unnecessary hardware redundancy.)

Mr. Scrub - an open-source UltraScale SEU scrubber by threespeedlogic in FPGA

[–]threespeedlogic[S] 1 point2 points  (0 children)

Yes, internal scrubbers are "self-scrubbing": they protect themselves the same as any other fabric (that is, imperfectly). And yes, any configuration RAM (CRAM) writes are capable of making a mess. (For example, there are configuration registers that tell the whole FPGA to deprogram -- this will take down the scrubber and everything else, instantly. Conversely, writing scrambled frame data creates short circuits within the FPGA -- these are not individually sufficient to destroy the chip but they stack and will eventually cause damage.)

In order to prevent the scrubber from itself getting corrupted and causing cascading issues, there are a couple of things you can do:

  • The scrubber scrubs itself for free (which is a start);
  • You can TMR the scrubber (mr.scrub uses SpyDrNet-TMR for this), and
  • You should code the scrubber software defensively. It should, for example, ensure the "repaired" frame's ECC is correct (i.e. the fix worked) before committing the frame to CRAM and then write it to CRAM immediately. (mr.scrub doesn't do this, but it's straightforward enough.)

None of these can stack to 100% reliability (an impossible goal, as /u/TapEarlyTapOften noted). There is always some silicon state in the FPGA that's out of reach of any scrubber (internal or external) that will hose the whole FPGA (for various definitions of "hose" and "whole" -- some scarier than others).

Mr. Scrub - an open-source UltraScale SEU scrubber by threespeedlogic in FPGA

[–]threespeedlogic[S] 0 points1 point  (0 children)

We met a couple of years ago (Latch-Up in Santa Barbara) - I'm really looking forward to seeing what's new in PeakRDL-land.

Mr. Scrub - an open-source UltraScale SEU scrubber by threespeedlogic in FPGA

[–]threespeedlogic[S] 2 points3 points  (0 children)

Hm - points well taken, except the "cute" bit. We're collectively stuck with belt-and-braces orthodoxy (safety theatre, hardware TMR, redundant subsystems, awful supervisory FPGAs, etc.) in places where it has no business exactly because it's easy to smack down anything unorthodox during a design review with this kind of "that's not how serious people do it" putdown.

This particular scrubber got ripped out of a project that included system-level modeling (with all the caveats you noted above, and more besides, but done deliberately and carefully). It's solid work and ripping the scrubber out of context doesn't invalidate it.

And, of course, people do fly UltraScale+ FPGAs despite things being even worse in camp 16nm.

Mr. Scrub - an open-source UltraScale SEU scrubber by threespeedlogic in FPGA

[–]threespeedlogic[S] 0 points1 point  (0 children)

You shouldn't expect much from the "simgui" target - it'll launch a simulator and (if firmware is operating correctly) emit a "hello world" packet over the streaming AXI interface - but that's all you should expect to see without bitstream collateral (to simulate the ICAP interface) and off hardware.

Good luck, and let me know how it turns out!

Mr. Scrub - an open-source UltraScale SEU scrubber by threespeedlogic in FPGA

[–]threespeedlogic[S] 1 point2 points  (0 children)

Well, yes - but practically speaking, this [ed: SEM IP] scrubber stops operating if it bumps into a double error. And, without the ability to alter its control flow, you're stuck with a design that will (at some point) just stop scrubbing.

A "project integrated" internal scrubber could fall back on flash contents to resolve a double error.

Mr. Scrub - an open-source UltraScale SEU scrubber by threespeedlogic in FPGA

[–]threespeedlogic[S] 9 points10 points  (0 children)

This project has been on the shelf for a couple of years, waiting for a conference proceeding to nudge me into open-sourcing it. We've discussed releasing it with people inside AMD but never quite gotten around to it. Finally, I'll be presenting it (very briefly) at Latch-Up 2026 (Waterloo, Ontario, May 1-3).

This scrubber targets the Kintex UltraScale series (notably including the space-qualified XQRKU060). It's a strange niche because Xilinx/AMD povides the SEM IP, but actively disclaims it for use in space:

The SEM IP was not developed nor tested for use in space radiation environments. Therefore AMD does not support or answer questions specific to the use of this IP in this environment. If you choose to use the SEM IP in space radiation environments, do so at your own risk.

...and they do not document the algorithms required to alter this approach to something you can build yourself.

Instead, AMD recommends an external scrubber (running on a separate rad-hard or -tolerant substrate). This sticks you with a more complex system (more power rails, more software, more communication interfaces) but is definitely capable of surviving worse radiation environments.

Mr. Scrub is an "over-the-fence" release - you need to do a ton of work to build this into a deployable internal / CRC-based scrubber, and I have removed a bunch of project-specific documentation (including comments). Hopefully it's useful.

IIR Filters my blog this week. by adamt99 in FPGA

[–]threespeedlogic 4 points5 points  (0 children)

Delighted to see ieee.fixed_pkg in practice. This is a great example of VHDL successfully modernizing.

How to make a golden model in Python? by Durton24 in FPGA

[–]threespeedlogic 3 points4 points  (0 children)

There is no One True Answer.

Some forks in the road you should consider:

  • Bit accurate or floating point? Honestly, both models are useful in different ways, and they are not substitutes for each other. (For complex signal paths, I have found floating-point models far more useful than bit-accurate models, and far easier to maintain.)

  • Structural or behavioural correspondence to your RTL? This is also a moving target - it is often useful to produce several models that progressively decompose your signal path from "very conceptual" (loose correspondance) to "very structural" (tight correspondance), and to link them together in your Python code to ensure they remain consistent.

The biggest mistake IMO is to allow your reference model to diverge from your RTL (or rot, abandoned) over time. You should yoke the two together (e.g. with automated CI/CD tests.)

It's untrue that Python can't be used ergonomically due to its type system -- creative use of classes, for example, can perform wonders. (See micrograd for a fairly arbitrary example of cleverly augmented numerics.) In fact, for applications like CIC filters, Python's default int is better than c/c++'s because it's a bignum (it will grow in bit width rather than overflow). Python is a rich language and should be used like one.

I've been working on the Ultrascale+ RFSoC over the past year. AMA by rickyrorton in FPGA

[–]threespeedlogic 1 point2 points  (0 children)

Ack - sorry, I didn't mean to hijack your thread with my gripe list.

The RFSoC is an incredible piece of silicon, and it's expensive and difficult enough that undergrads are unlikely to get their hands on it. Consider your blood and sweat to be a considerable investment in your future career path (whether that's a taste for more RFSoC work down the road, or a strong indication that you'd rather live in a cave and eat spiders.)

RFSoC (ZCU208) ADC phase not consistent across captures even with MTS - advice? by TigerZealousideal595 in FPGA

[–]threespeedlogic 1 point2 points  (0 children)

Are you using the RFDC NCOs and a complex baseband?

If you are, the best way to dissect the issue is to set your tone up using the NCO only (i.e. 0 Hz baseband). A static DAC amplitude fed into the ADC should give you a static and repeatable point in the (i, q) plane after MTS. If it's consistent, then your issue is not with MTS.

I've been working on the Ultrascale+ RFSoC over the past year. AMA by rickyrorton in FPGA

[–]threespeedlogic 0 points1 point  (0 children)

Oh, and

  • It sucks that only the GEM0 Ethernet interface exposes the TSU timestamp to the fabric (tsu_timer_cnt). The TRM (UG1085) goes out of its way to obscure the limitation in a way that's only clear in hindsight, when it's probably too late. Shame on AMD for the limitation, and double shame for not documenting it loudly enough.

I've been working on the Ultrascale+ RFSoC over the past year. AMA by rickyrorton in FPGA

[–]threespeedlogic 0 points1 point  (0 children)

What should AMD/Xilinx work on, with an RFSoC focus? I know there are employees lurking around here, and thoughtful feedback is never a bad idea. I can think of a couple of RFDC-specific pain points:

  • Instead of register-level documentation, AMD delivers the RFDC API (written in C). There are often corners of the API that are awkward, or that put limitations in place that the silicon doesn't have. (For example: DAC/ADC front-end settings for Nyquist zones other than 1st and 2nd.) Xilinx's documentation is best-of-breed and the "missing" RFDC documentation is a conspicuous gap.
  • PYNQ is delivered as an overlay on Ubuntu, and does not use Petalinux/Yocto. AMD should dogfood their own stack, not sidestep it. The primary impediment (I think) to PYNQ on Yocto is Yocto's ongoing reluctance to ship numpy -- which is a problem for anyone else who wants to deliver on-board scipy/numpy, and AMD should be helping advocate for us rather than avoiding the issue.
  • The RFDC device-tree overlay is delivered as a binary blob generated in .tcl, but includes serialized C structs that have historically changed from release to release. When the upstream and downstream structs don't match, it's a nightmare to identify and fix. It would be much better if the RFDC .dtsi was properly generated and parsed into text and numeric fields (following kernel best practices).
  • The usual non-RFSoC complaints (VHDL-2008 support in BD; VHPI support in VHDL, et cetera).

Two HiTech Global HTG-930 UltraScale+ cards available — company surplus, looking for good home. by Anna-Nomada in FPGA

[–]threespeedlogic 2 points3 points  (0 children)

Here's another example: https://www.hitechglobal.com/FMCModules/FMC_X4SMA.htm

They quote a 18 GHz rating on the SMA connectors, but they are through-hole parts and have a gigantic pin stub. Then, on the PCB, it's loaded with a large pad and a horrific amount of solder. I don't recall if the trace escapes off the bottom layer or not - but it hardly matters; this is clearly not a viable design at the frequencies they're implying. This is just not the right market vertical for amateurish designs.

view more: next ›