Nicolette

All right, so we like to jump right in. So, we’re going to ask you a couple questions first.

Let’s start with you, Craig. For anyone who may not know BittWare well, can you tell us a little bit about the company and what really makes you different, you know, especially we’re talking about RF when it comes to RF?

Craig Lund

Well, BittWare is a roll-up of several companies that were acquired by Molex, specifically BittWare, Nallatech, and Innovative Integrations.

And all three companies have a history of RF products. And Innovative was focused exclusively on RF products.

We’re talking here about new stuff. And all the new stuff in the RF space from us is based on the AMD/Xilinx direct RF chip. The RF “SoC” is what people tend to call it.

Our particular niche—you’ll find there’s a lot of cards out there in the world with RFSoCs on them with various different features and capabilities—our niche is commercial form factors at commercial price points, with high-quality characterization data and support.

We obviously want to sell to everybody. But it’s worth pointing out that our RFSoC products today are most popular in Satcom base stations, as well as test and measurement equipment—particularly analog recorders. I think we can explore more as the questions come up.

Bryan

So Shep, what about Atomic Rules? How do you fit into the RF ecosystem and your relationship with BittWare?

Shep Siegel

Sure. So, thanks for having me on today. I love to talk about this stuff. Atomic Rules has historically been a services and IP core provider—things like our Arkville-brand DMA engine, UDP offload for IPv4 and IPv6. IP cores that help create the systems that we’ll be talking about today.

But I think the reason I’m most excited to be here today is for the past couple of years, in addition to our IP cores (RTL cores) that require expert competencies in order to deploy, we’ve also been selling a product—a turnkey solution—called TK242.

It’s like a bring-your-own-hardware approach where, with a COTS board from BittWare and our software and IP, you’re able to swallow the data coming from or going to these RF devices and play them back at a later date.

So, having a capability that easily and relatively inexpensively allows you to capture and play back that data provides an added value to the overall discussion that we’re having today.

Nicolette

Darrell, what’s different about taking a direct RF approach versus a traditional discrete RF solution?

Darrell Epperson

Yeah, that’s a good question Nicolette. The older approach has been what we call the super heterodyne mixing down to an IF approach…where it takes a signal at RF frequency—let’s call it above one gigahertz—mixes down to some lower frequency and does the detection say at 100 megahertz. That takes a lot of extra space, costs, power. And it limits you on the bandwidth possible without retuning the local oscillator.

In the case of direct RF, with say a five giga-sample ADC or 10 giga-sample DAC, we’re able to modulate the signal directly at the RF frequency above one gigahertz, save all the mixing cycles up and down, and you have much wider bandwidth…on the order of two gigahertz or greater bandwidth (instantaneous bandwidth) for the user. So has a lot of benefits.

And in the case of the RFSoC has additional benefits of integration of the analog converters together with the FPGA processing engine for ease of use and communication.

Bryan

So where are you seeing the direct RF architectures make the biggest impact right now? Like what type of applications are driving it?

Darrell

Well, I see that largely in  our Satcom business. There is a cost efficiency that’s being had these days with the cost of deploying constellations of satellites, and we see a lot more people doing so, a lot more companies getting into the market (competition with the likes of Starlink and others).

And so, to do that means more user interface on the ground and to procure that equipment you need a good cost point that BittWare offers. And the RFSoC together with our product…it seems to be a good fit for that market (in the Satcom market)—high performance and appropriate cost as opposed to what traditionally had been a military/aerospace-linked market that was a cost point at least double or greater of where we are today.

Nicolette

So where would you really say that BittWare fits into the whole RF solutions market today, if we had to look at it like that?

Darrell

Well, I think you would see, as Craig mentioned starting out, we have a larger footprint in the commercial space than in say aerospace and defense (not to say we are not in that market—we are and have facilities for aerospace and defense).

But we see a growing market share in commercial where we have, we think, a good fit between cost of equipment and performance metric as well as the user interface for our products…is more convenient for a server application, for instance, with our PCIe interfaces and also Ethernet.

So, I think we have most of our exposure to date in commercial and largely Satcom, but also some other location finding, direction finding, and other markets.

It’s a growing market for us. We think it’s one of our greatest opportunities within BittWare.

Craig Lund

One of the things that we haven’t really mentioned to date is…one of the differentials over the way we’re doing things and the way other people are…is that we do have amplification on the card. [Darrell] Mmm-hmm. [Craig] If you look at your typical…well, focusing on Satcom here in this discussion as opposed to test and measurement…but in terms of Satcom, you’ve got your antenna. The antenna has some kind of a low-noise amplifier on it. Then after that, you tend to go through a down converter (or up converter, depending what direction you’re going), some filtering, some amplification, and then you convert your analog data to digital packets.

The RFSoC is really there just to do that last step—to convert the analog data to and from digital packets, as well as do some first-level processing like FFTs or something. But we also pull onto our card the filtering and amplification step. And in the future, we hope to pull more on. So, you don’t have to buy the filtering and amplification stuff from us, but we find that some of our best opportunities (in terms of people buying in volume) are. Because again, it just reduces the cost of the overall solution through integration, improves the performance (you don’t have so many connectors and cables in the way), reduces the cost, all that kind of stuff.

Bryan

Can you give us a little more background on BittWare’s experience in RF, I know we talked about a little bit? And how did you get to where you guys are today.

Craig

Well, as I said, all three companies that were sort of acquired and rolled together—the BittWare brand was used for all three (BittWare is just one of the companies) have an RF history, all of them built RF products. Normally, though, when we talk about the history, we focus on Innovative Integration because their business was RF and you can still buy historical…there are still people buying a lot of legacy or historical (however you want to call it) Innovative Integration products. And that goes back a very, very long time. So, I mean, we collectively have been in the RF business for a while and it’s mostly (if you really look at the Innovative Integration side of things)… it’s mostly been about moving analog data on and off a server through a PCI bus.

Our launch products, which, you know, the 8440s (which Mouser is kindly selling many of) focus differently. There’s a bit of a mismatch in bandwidth. If you look at the bandwidth of all the analog data that can come into an RFSoC, and you look at the bandwidth of all the data that can go out. You have to do a lot of decimation and various computing to fit through that much narrower funnel outside the chip into the digital domain. And you can get an awful lot more bandwidth if you focus exclusively on the Ethernet side.

And particularly if you’re like at a base station in a remote location, it’s all you want anyways. So, our initial product didn’t use PCI, and therefore kind of was a complete disconnect from the past. We have since added a PCI-oriented product. And PCI is really about tying your digital data into some kind of an application running on the server.

But…this is a question about history…I’m not sure…I guess I’ll end it there.

Nicolette

Well, I was going to ask why BittWare chose PCIe cards for direct RF solutions instead of moving to a more ruggedized and, you know, exotic form factor…

Craig

Well, our initial launch product of this family, the [RFX-]8440 (soon to be…sort of…supplemented by the [RFX] 880)…it  does not need to be in PCIe form factor—I mean, it literally does not need a PCI slot. It can sit…and we have this thing called the WaveBox that just basically has power supplies and a chassis controller. There’s no motherboard. There’s nothing for the PCI to go into. And so, PCI is just convenient for us as a commercial form factor.

When you get into the PCI oriented cards, of course, it has to be PCI. Well, I guess it could be compact PCI, but standard PCI is where we’re going. We, as a collective company, do build things in the defense space. We’re finding the gap in the market was on the commercial side—there’s a lot of people on the defense side.

But particularly with the exploding opportunities in Satcom (and a lot of associated opportunities in test and measurement) there was a gap that we could fill there. And so commercial form factor PCI…all worked out.

Bryan

Well, so with the PCIe cards is there some cost savings that happens?

Craig

It depends on what you’re talking about in conjunction, right? If you’re talking about defense VPX, 3U VPX, conduction cooled form factor, there’s massive cost savings.

If you’re talking about a commercial PCI card versus building just a proprietary commercial card or a compact PCI card there’s probably not a lot of savings. I mean, the commercial price point is the commercial price point. We choose to use PCI because it’s what we’re familiar with. There is a few small advantages to it. But…it’s really…it’s not a defense form factor.

But we’re also not building something super cheap, meaning there are folks out there, (I’m not talking about RFSoC specifically) but there are folks out there that that put chips on a card…build a bunch of them as cheap as they can. In the case of RFSoC, they might not have any characterization data. They might not have any support.

We’re definitely not in that category so we’re not…we’re never…BittWare products are never the cheapest you’ll find in the commercial world. They’re the best value, meaning you get a lot of support both in terms of information and question answering, opposed to some other vendors in the commercial space.

Nicolette

So where are you guys seeing the most traction right now with these direct RF products?

Craig

Well, as I started with the launch product in this space, the [RFX-]8440, is very popular in…Satcom base station applications—both commercial folks and kind-of intelligence/defense-y kind of folks… as long as it’s [in] a room—you don’t want to put our cards in a Humvee right? and drive them along. That’s what you want through 3U VPX for.

[Bryan] Gotcha [Craig] But, if it’s sitting in a room and not going anywhere…commercial or defense doesn’t matter….and that’s where we’ve had the most success.

As we’ve started selling a PCI oriented product…we’re selling some to the historical Innovative Integration customers and we’re finding new customers in test and measurement. When I say test and measurement, it could be a whole bunch of things, but almost everybody ends up with an analog recorder in that space as well, and that’s why Shep’s on the call, though he hasn’t really talked yet.

Bryan

(laughs) Oh Shep will [Nicolette] Once Shep gets started, you can’t stop him, so don’t worry. [Bryan] So, okay, speaking about analog, let’s talk about the analog slide a little bit. When you integrate amplification and filtering right onto the card, how’s the analog performance? [Craig] Darrell…

Darrell

Okay, yeah, I’ll take that one. We have had good comparison against the more discreet—and by that, I don’t mean the earlier discussion of…way back—but the discrete approach where folks buy a converter and connect it to an FPGA and have an external mixer, filtering, amplification…

We integrate that on our card in the way of LTCC-based filters (which are quite good in performance versus size). We daisy chain a couple of those with an amplifier (or two) of stage amplifiers. [Bryan] Mm-hmm.

[Darrell] These are low noise, high performance, high-linearity amplifiers. And then follow that with our RFSoC, which is an AMD product that, of course, has comparable performance to anything in the market for A to D and the sub-five gigahertz range.

So, we don’t see a real compromise in performance. We simply use techniques that are more suited for, say, some of the small electronics markets that are finding their way into these type of applications such as the cellular phone market that’s learned a few things about integration into small form factor. We have techniques for shielding that are quite cost effective and small size to provide a full enclosure for the RF chain. And we have a multi-layer high quality printed circuit board that allows us to do internal routing. So, we have quite good (80 dB+) isolation between channels. We have great intercept points for the linearity of the amplifier-mixer chain in front…

And we have good selectivity—and we’ll speak a bit more about that—as to select between first Nyquist, second Nyquist, and third Nyquist zones. And we think that’s a unique opportunity we offer the market in that we allow users to decide which of the Nyquist zones they prefer on the different receive channels and we can populate based on that bandwidth requirement, and then also combined back in the FGPA fabric, the packets as they arrive.

So, a combination of first Nyquist, second Nyquist, and third, and achieve a lower-cost wide-band application, if you will: two gigahertz in each of those Nyquist zones.

Nicolette

All right, it looks like we have a user question (just give me a sec). We have a question here, “Does BittWare have DIFI capability?” and they want to know if you could discuss this at all?

Craig

Yeah, I can discuss that. So, the Ethernet-oriented…well all of our RFSoC products come with a reference bitstream which is very close to an application, but we do expect customers will need to reach in and do some tweaks to it to make their application work.

The reference bitstream that comes with the Ethernet-oriented card supports DIFI with an asterisk. The DIFI generally requires USB…(not USB, oh my lord!)…UDP as a transport…and UDP transports cost money and we give the reference bitstream for free.

So, what we’re doing is we’re doing the DIFI VITA 49.2 packets—we’re wrapping them in an Ethernet frame, and we’re finding that most of the customers that we’re dealing with in the Satcom world actually are perfectly happy… (they’re not trying to route their packets to Tokyo) they’re trying to route their packets around the building or the little outhouse at the bottom of the satellite dish, and they’re perfectly happy with that.

But, we do have customers that want the UDP, and they…generally acquire that from Shep, who’s sitting right there in that window. We have built a build of our reference bitstream that we can’t distribute because it cost us money. But we’ve built a build of it that has UDP and has…Shep has TimeServo [IP] and that’s actually important as well for that. That’s the other thing is our time servo in the default thing is just a counter… a nanosecond counter.

Bryan

So, Shep, do you have anything to add to that? I started shaking your head while…

Shep

No, no, no—I was nodding yes. Thank you. Thank you for that, Craig, thanks, Brian. Sure, I’ll jump in here.

So, I think for the audience here (because it’s kind of a menu of different items here)…we’ve touched a little bit on Atomic Rules’s UDP Core which is useful for getting UDP IPv4 or IPv6 compliance (separate cores for v4 and v6 because layer 3 is entirely different).

And as an engineer—maybe not speaking entirely for Atomic Rules—but as an engineer, I completely agree with Craig’s assessment that a great many uses of shuttling around digital IF don’t require UDP. Maybe it’s not going to Tokyo, but there is the layer-two flat-Earth problem (even in a big outhouse) where you may want to have that other level.

And, of course, DIFI (am I saying that right is it [diff-e] or [di-fi]? …doesn’t matter), eCPRI, VITA 49—the litany of standards that came to…normatively define how digital IF would be shuttled around. Often the spec writers—their pinky comes down and they say, “You need to have UDP,” and they’re not really maybe thinking about the cost and the power of the added layer and overhead of having that routability.

Look, Atomic Rules sells the [UDP] Core (we’re happy to provide it) but agree completely that a great many applications—certainly in a prototype environment—you have to scratch your head as to why do you want that extra layer and complexity because it’s going to cost you some gates, some power, and some latency. It really won’t impact your throughput at all (unless it’s done wrong).

So, that’s my point on the core. Brian, can I keep going? Because I really want to jump in and talk about TK242. I think the reason I’m here today, which is Atomic Rules’s capability to swallow up these digital IF packets, be they layer two Ethernet or layer three UDP, put them on a disk and get them back at a later time. Is it a good time to jump in or am I being a showboat here?

[Bryan and Nicolette]

Sure, sure. Yeah, no, no.

Nicolette

No, yeah, you can continue. We have a couple of user questions coming in, but we should talk about this. Go ahead, Shep.

Shep

Good, good.

We kind of saw this coming some time ago—we’ve been working to make a turnkey solution. By turnkey, we mean no FPGA programming, no software programming required. We essentially engineer a bitstream and software, you buy the appropriate FPGA card, our software is an overlay on that, you plug it in, and the end result (right out of the gate with bringing your own hardware: that FPGA board, the disks, the computer) is you have a packet recorder and player—a really high performance one at that.

And this has been successful far beyond our initial ideas, because when we came into this market some years ago RF wasn’t foremost in our mind—it was really the packet recorder market (the…finance and just…Ethernet: gobbling up data and storing it). The marquee feature of our TK242 recorder is that it works with all Ethernet, so your own proprietary layer 2 format—not a problem. If it’s Ethernet, we can record it and play it back.

And we convert all of the Ethernet frames into the industry-standard PCAP file in the FPGA. So, the FPGA in hardware is doing a byte-true conversion from Ethernet frames into PCAP and back the other way.

As Craig alluded to moments ago, we have this TimeServo. We have essentially a…we have an IEEE 1588 PTP device that gets us nanosecond-resolution timestamps on all the packets going in and out. And those data are turned into PCAP files in the FPGA. Those byte streams are moved by our software to a disk array on the disks that you provide, and we can play them back with the same fidelity, with the nanosecond pacing.

In other words, you can hook a DAC up on the other side and get that RF back at a later date. With certain limitations, we can even do it at the same time.

So, this was great because we were looking at this COTS solution. And what I mean by that is the hardware that this runs on are standard off-the-shelf boards from BittWare, the IA-420f, [IA-]440[i], and [IA-]780i—they’re all off-the-shelf from Mouser right now (that was an unintentional plug, sorry—but they are!)…you can click right now, buy that board, have that board on your bench tomorrow, and bring up TK242. And that’s kind of organically how we’ve gotten our TK242 RF customers.

Wrapping this up so this is more of a dialogue instead of a Shep monologue everyone’s been fearing…as we’ve done the dance with our growing RF customers—who are doing this digital recording of digitized, packetized analog data—we’ve listened… “What else could we add to the story to make it valuable?”

Of course, we have an FPGA that we could do perhaps anything inside the FPGA. Instead, what we’ve done is we’ve provided a API for users who want to basically look at all the packet data as it’s being moved to disk. So for example, in the RF space, you could, for example detect a saturation condition. If you have a 12- or a 14-bit converter you could look for the case where you’ve hit the positive or maximum extrema, and while you’re recording, have runtime notification, for example, that your gain’s too high.

Maybe the BittWare cards have features like this built in on the front end already, but my point is that users could add these bespoke capabilities to TK242 in their own software if they want and exploit the fact that they are streaming all the bytes of their data to disk and all the data back. So that’s why we’re here to basically do a lossless capture and replay of some integer number of hundred gig streams coming out of these RF devices.

Bryan

Okay, so we do have a few user questions that have come in—I’m going to…but thank you, Shep, thank you for going into that in detail.

I’m going to ask the first one, “When you talked about Satcom applications, are you focused on reflector dishes? How does the system scale for phased arrays, which need multiple PCIe cards?”

Craig

So yes, the customers we’re currently dealing with mostly are not phased arrays. The RFSoC chip itself is excellent for this kind of synchronization of multiple cards. Then the question comes into, “Is our implementation optimized for phased arrays?”

The challenge here—and it’s the same challenge that pretty much any standard commercial form factor faces—is the number of coaxes you can stick off the front panel. For a phased array that’s affordable, you probably want to use an RFSoC that has a large number of A-to-Ds and D-to-As exposed on a single chip. The PCIe front panel pretty much limits us to eight coaxes for this kind of data, and it’s set for analog four ADCs, four DACs with the chip we’re using. Which means that you might really want six ADCs and two DACs, or you might want all eight ADCs. And with the RFSoC we’re using, that’s challenging.

We do have plans for that, but that’s something we’d have to talk about separately. Because, you know, they’re plans—they’re not off-the-shelf products.

So, we do care about phased arrays. We are seeing some customers in that space (particularly around direction finding at the moment) but it’s still phased array. But…we’re going to do something there, but not immediately.

Nicolette

So, Craig, I want to talk a little bit on the digital side. Can you maybe give us just…give us a quick overview of the different form factors and the solutions available, especially where the RFX-8440 and the 880 fit into the picture there.

Craig

Well, the -8440 and 880 are almost the same product. The products that begin with “7” are the ones that are PCIe focused. The products that begin with “8” are the ones that are Ethernet focused.

In terms of form factors, we as a company offer two. There’s the PCIe card we’ve talked about. We also have—and again, it’s not the kind of mainstream can be sold off-the-shelf kind of product—but we also have microelectronics where we take RFSoC die and stick them on tiny little cards to make really little, small things. But again, that’s not this discussion. [Bryan] Right.

Craig

In the marketplace, you’ll find, you know, effectively you’ll find three things, right? You’ll find a bunch of defense products that are usually in 3U VPX. And they tend to have, “Oh, here’s the RFSoC product and here’s a box of all the analog stuff we’ll do in front of it for your application. Just let us know—we’ll build it custom for you.”

Then there’s us with our PCIe-oriented cards (or form-factor cards) where we have a box in front of it too, except instead of saying we’ll build something custom just for you, we’ve already built this thing that has filtering and amplification.

And then the other thing you’ll find in the market is people that build what are effectively little boxes. As soon as you’re selling it as a box (versus a card), you can use any size or form factor you want. So, you’ll see people out there with little boxes that have a variety of different things coming off the front and a proprietary (if you’re selling a box, proprietary is not a bad thing), but a proprietary printed circuit card inside.

Our WaveBox—where we put just (not the 770 cards, WaveBox is just for the 880s—the Ethernet-oriented ones) is effectively a box, just like I said before. But since we sell the cards separately, we’re telling you the cards in there are in PCIe form factor. If we sold just WaveBoxes, we wouldn’t have that—we could make them anything we wanted. But again, we’re kind of a card-oriented company also selling these exciting little boxes, as opposed to a box-only company, which are out there. Does that [answer your question]?

Bryan

Yeah.

I have a question, let’s get into bandwidth, right? These cards can capture about 2 to 2.5 gigahertz of the spectrum, right? What happens if a customer needs broader capture capabilities?

Darrell

Yeah, that’s a good point, and there are applications these days where folks want more than two gigahertz of instantaneous bandwidth. And there’s a couple approaches in the market that are doing that.

The natural way is to keep increasing the clock rate of the converters, so that the Nyquist zone just keeps expanding. That takes a lot of extra power, heat, and so forth (and cost).

The other is what we are sharing earlier is that we do segment our channels. One option is to segment by Nyquist zone, and we have filtering capable of a five gigasample sample clock (the Nyquist will, of course, be two and a half gigahertz) but with filtering walls and roll-off, we have usable about two gigahertz of bandwidth per Nyquist zone.

But in the case of having all the channels combined back in the FPGA chip (which includes the converters) it’s a natural fit to sum, if you will, or combine all these various channels that may be operating in different frequency bands, say with Nyquist zone one and also Nyquist zone two for another channel—we can combine those two channels in the FPGA fabric in packet form so that instantaneously the user is seeing the combination of those two channels equivalent of four gigahertz.

All that’s needed is have two RF channels such as two feed horns at the same antenna, for instance, that would receive those segments of the band or the spectrum, identically, if you will, at the same time.

We also have phase coherence when we have all those channels in the same package where they are phase aligned and synchronized. We have a multi-tile synchronization capability where we can combine all the different channels and phase align and we can also phase align the cards with each other with external reference signals. So, we have a lot of capabilities.

I think the RFSoC brings that to the market and has a low-power high-performance interface capability between the FPGA fabric and the analog portion that we then extend to the antenna with our gain and dynamic range control along with filtering and, in the future, up and down convert to higher bands.

So, this is, I think, one of the natural benefits: the bandwidth combinations that are, in some cases, needed in the market.

Nicolette

We have another question here. How many channels can you support, and is it possible to synchronize them across multiple cards if you need to?

Darrell

Yeah, that’s what I referred to earlier. And Craig alluded to our current configuration of the AMD [RF]SoC that we use has four A-to-Ds and four DACs.

We have the opportunity to use other models of that same chip—other packages—that allow eight A-to-Ds plus eight DACs. And so, we would (in our current configuration) allow the user to select any combination of those DACs and ADCs as long as the total equals eight. So, we have eight RF connectors on the front panel—we can route all eight as ADCs (as receiver channels) and all eight as DACs or some combination thereof.

In terms of synchronization, of course, in the chip, they’re all synchronized with the same clocking (and also external clocking that would be needed if we up and down convert) will all be phase-synchronous.

In terms of combining the cards within our WaveBox—which is a rack mount panel, if you will, that combines multiple cards—there is synchronization in the way of external references that allow feeding the same reference clock to all of the cards and also a 1PPS kind of interface alignment signal that allows us to have synchronization between those cards.

So, yes, the answer is yes, we can phase align in the case of phased arrays or some other application.

Bryan

So is it safe to say…

Shep

Darrell, Brian, can I jump in for a second? Because I want to piggyback something that Darrell…

Thank you for that, but I think when I read the question, I was thinking, “Oh, this is about how it’s going to be recorded and played back!” Obviously, that’s an adjunct to actually capturing it and getting the data out.

These cards, as Craig and Darrell have explained, are Ethernet-centric, not PCI-centric. So, after that data has been synchronized and sampled and collected and possibly down converted, you possibly want to send it somewhere for processing and storage and ultimately replay.

Atomic Rules TK242 swallows that data. The ubiquity… in AMD’s RFSoC of 100-gig ethernet—there’s a hardened CMAC core, which makes it relatively inexpensive and low area on the FPGA to get this data out as whether it’s digital IF, DIFI, VITA 49, a bespoke…format for your application—that doesn’t matter as long as it’s Ethernet.

The TK242 recorder and player will capture that as some integer number of hundred gigabit pipes that are provisioned appropriately, record that to disk and play it back at a later date.

With an inverse story for allowing the DAC samples to line them up, sample-to-sample, on the way up.

Bryan

So Shep, how does it maintain the playback of at the waveform layer? How does it work? Can you talk a little bit more about that?

Shep

Sure. So, depending on the standard you’re using, VITA 49, digital IF, eCPRI, almost all of these digital formats, including bespoke ones that individuals make for their particular application, generally contain the complex IF (the sample data) as the basic payload, and generally so goes with information at a minimum, there’s a sequence number that essentially shows the ordering of the packets. There might be other decorations as well, such as timestamps when perhaps the notion timestamps tracing back to the A-to-D sampling or less important timestamps about when that packet was actually recorded or played back.

The recording process is pretty simple. Every packet that’s incident needs to be captured to disk, period, full stop, complete fail if anything is dropped on the floor. It’s once-in-a-lifetime data, you can’t go back in time.

Your question, Brian, is how do we get this to play back properly? And that can get complicated real quickly, especially if we flip over this multi-static or like a digital interferometer application where you have multiple recorders—multiple playback is difficult.

Let’s talk about a single playback for a moment. You simply (simply!) need to respect the isochrony of the data going out, meaning there’s continuous sample data going out, but your data stored is packetized. The simple short answer—which isn’t a lot of Shep hand-waving, cut to the chase, on our first-class tool for maintaining that without any packet gaps—is to support Ethernet pause frames.

So, IP that’s readily available in hardened or soft-hardened form on the RFSoC devices that Darrell and Craig are talking about support this relative to the CMAC. There’s a small FIFO buffer in the DAC path, and by making sure that the pause frames are emitted to slow down the over-provisioned playback capability, samples…that FIFO never underflows or overflows, and you’re guaranteed a continuous smooth stream of data on playback lined up to a particular time reference.

Bryan

Okay, so some radar systems use custom Ethernet Layer 2 formats, right? If someone has their own protocol, can they still use the TK242 to capture and replay?

Shep

Absolutely. So, as I mentioned earlier, as long as it’s Ethernet, it’s okay. At the beginning of this dialogue, Craig and I were kind of going back and forth talking about UDP.

No doubt about it, UDP, the RFC has been around for almost 30 years now is what so many protocols are built on top of.

However, pragmatism, particularly with regard to FPGA area and what you’re trying to do, doesn’t always require it. But if your spec says, “You will transport this on UDP,” then you have a discussion about IPv4 versus IPv6 (we’re happy to address that—and there certainly are values to it), but we’re being very clear engineer-to-engineer that that’s not always required. And when your first-class concern is swallow this big data and play it back out, anything that Ethernet Layer 2 is good to go.

Craig

Yeah, let me just be very clear. Most of those radar systems you’re talking about have an RDMA protocol—whether it’s the standard one or one they invented—but it’s an RDMA protocol wrapped in an Ethernet frame (what Shep was calling “Layer 2”). All his stuff works on Ethernet frames. So, he will capture the RDMA protocol along with the actual radar data, which is actually what you want for test and measurement.

If you want to actually participate displaying the radar, then you’re going to have to actually have to process the RDMA protocol. But, you know, the radar companies know that—they know how to do it, it’s their protocol.

Nicolette

You know, Craig, we have a couple of questions here. I just want to refer to one that you were typing. I want the audience to hear the question, “Will the new architecture allow direct sampling above L-band, S-band…will 5G 30 gigahertz be supported?”

Craig

The reality is, yes, we’ll be doing up-down conversion to 35 gigahertz with the current parts.

[Nicolette] Okay.

Craig

…the current RFSoC. So, the same, “Somewhere between two and two and a half gigahertz of instantaneous bandwidth up to 35 gigahertz,” as well as amplification up and down conversion.

Bryan

So we have another audience question. Can you please elaborate more on Atomic Rules’ time stamping: its resolution and methods?

Shep

That’s a quick, concise question. I’ll get into that and right out of it. So, we have standard IP cores for that. We have a product called TimeServo, and we have one called TimeServo PTP.

And we use a combination of both of them on TK242. So, users of our TK242 solution really can choose from three different ways to set up their time base. They can most accurately (if they really want to get to some nanoseconds deviations)—they can supply a reference into the card, the aforementioned BittWare cards, the TK242 runs on the [IA-]420, [IA-]440i, and [IA-]780i all have the (at least optional) capability of routing that reference clock in.

Sometimes that’s not feasible or perhaps you don’t need that much accuracy. The most common use—because many users are quite happy getting the tens-of-microsecond accuracy that the host that TK242 is running on (which might have its own PTP or even NTP)—is TK242 will default to using a software DPLL where the capture device DPLL locks to the host’s time. And then you’re essentially in lockstep with the with the Linux computer that’s running your capture and replay device.

And last but certainly not least, and what a lot of people…attention is drawn to (because it’s perhaps the most deterministic and sure) is all TK242 devices have a PTP 1588 ordinary slave on as well. So, if you have a grandmaster on your net and you connect one of TK242’s ports to that net, TK242 will derive its time there.

So, you have three different ways of getting this, an external reference from the host or from a PTP 1588 ordinary slave.

Byan

So how much FPGA expertise does a customer realistically need to deploy these solutions? Can someone with minimal FPGA skills get a system up and running?

Craig

I think that really depends on how close our reference bitstream is to what you need. [Bryan] Okay. [Craig] If it’s close, then yeah, I mean…if it’s far away, then yeah, you need to either do it yourself or find a consultant to help you. [Bryan] Gotcha.

Shep

And if I could chime in on that one, Brian, from the recorder/player point of view with TK242, zero, 0.0. It’s a turnkey…anyone remotely capable of maybe putting a Linux installation on a disk will bring up TK242 in the course of an hour. They plug in the card, they load the software. There’s no FPGA programming. There’s no C programming. There’s no Python programming (though for the latter two, you can add that bit on) and you’re up and running.

Craig

Yeah, and I’m not disagreeing with that at all. I’m just noting that somewhere along the line, you have to tell the RFSoC, you know, “A to D number one, sample at so many gigahertz at so many…you know…decimate,” all that stuff.

So, if you can tell it what you need, in our reference bitstream, then yeah, you can hook the reference bitstream up to Shep’s stuff and record it if that’s what you want to do.

Shep

Yeah, the RFSoC stuff is not for the faint…you need a Darrell somewhere in there I believe. It’s not the old days where you’re hitting a handful of registers. There are literally hundreds of registers that need to be set right for the RFSoC to do its stuff.

Competent FPGA and CS experts here at Atomic Rules who’ve jumped in to look at RFSoC were like, “Oh, we should probably ask a specialist about that.”

So, I do think anyone looking to jump in here, if you have the RF chops, there’s a decoder guide to get your RF chops onto the chip. But if you’re just trying to grab spectrum and you don’t know, you really need a Darrell (I think), or someone like him to guide the way, in my opinion.

Darrell

Well, one benefit is that we offer a GUI interface for at least prototyping our products. And so that’s a PC-compatible interface that sets all these registers, as was mentioned. It sets all your decimation and frequency of operation. And that’s available to all our customers, in soon-to-be-released format (it’s in beta phase now).

We also have compatibility with the RF Analyzer tool that’s a GUI, another GUI interface that AMD offers, at least for prototyping and characterizing the performance of our card.

Nicolette

All right, so we are coming to the top of the hour, but we were talking about something the other day with your team, and I think it’s timely because I think these days people are very interested in where things are being manufactured. So, I was wondering if you could just talk a little bit about sourcing and where these cards are actually designed and built.

Craig

Okay, our RFSoC products are…pretty much the all the IP inside the…all of our reference bitstreams and stuff are in California. The schematic capture and all of that kind of stuff is in New Hampshire. The manufacturing is in California. It’s in a (you know, if you care about these things), it’s in a facility that can do ITAR manufacturing.

We, as a company, have a big presence in Scotland. And some of our tests will definitely always happen in Scotland. But, you know, this is…a very American product. Now, that doesn’t mean that every single thing on the cards comes from America. That’s a…I think, impossible in the electronics industry today. [Nicolette] Appreciate that.

Bryan

So, did we miss anything? Is there anything else to…

Shep

I always like to say it’s a great time to be doing this stuff. I appreciate being able to be called on this. We have such amazing technical levers that we can pull on relative to where many of us were when we were younger. And because we have such great force multipliers, we can do great stuff in less time. And it’s exciting to me and the team at Atomic Rules that we can participate with BittWare in the ecosystem around the people on the call today in these solutions because they would be unheard of even a short while ago. And the technology today is—despite the challenges that we’re all up against—has enabled it.

Darrell

And one other thing, if a customer needs something different than what we’ve presented here today, something unique, we do entertain those opportunities.

And it’s, of course, volume dependent such as different form factors, the more ruggedized cases or whatever different frequency bands. We are exploring all options and would love to entertain that with anyone that’s interested.

Nicolette

Can we squeeze in one more question? We have a last-minute question. I know. All right.

[Bryan] Let’s do it. Let’s do it. Get it in there. [Nicolette] What OS does your API host software run?

Craig

The RF software? [Shep] Do you want to…I’ll get it out of the way, Craig. Atomic Rules stuff: all…

[Nicolette] What is?…look at everybody asking these last-minute questions! [Bryan] I know.

Shep

For all Atomic Rules, IP and TK242, any Linux system, period, we’ll stop. Go, Craig.

Craig

And the RF surfer (our GUI on our reference bitstream) is basically…effectively a web application so it will run wherever. And in terms of, “What OS does everything support?” we don’t support Windows generally. We do, in our FPGA products, have a Windows solution, but we’re not focused on that for the RF side. It’s all Linux if you’re talking about a driver.

But again, with the [RFX] 880, you don’t even need a motherboard, so you don’t need any OS.

Bryan

Well, we are closing out on our time. Thank you for joining us today for our live chat. And thank you to our sponsors, Mouser Electronics and BittWare and our amazing panelists.

[Nicolette] Yes, thank you guys. [Bryan] Everyone, yeah, thank you. Everyone have a great day.