RF converters

Many applications, wireless ones especially, connect to one or more RF data converters — ADC/DAC blocks such as the RFDC on an AMD/Xilinx RFSoC part. Waveflow provides a simple method for modelling and interfacing with such converters.

Rfdc is Waveflow’s emulation of the converters themselves. It is modelled to have an AXI-Stream interface identical to the AMD RF Data Converter IP, plus a simulation of the interface to the RF environment. The RF environment lets you run sources, sinks, nodes and channels directly in your simulation and observe how your logic behaves.

Rfdc exposes raw AXI streams for each data converter path, with intricate packing and back-pressure rules. You are free to build logic against those streams directly — for anything that processes samples as they arrive, a filter or a detector, that is the right answer. Waveflow also provides two hardware modules that sit on top and offer a simpler, asynchronous interface:

  • RfShotBuf — the finite family, for designs where nothing reads while something is writing: load a waveform, then play it; capture into a region, then transfer it. All of its memory is payload, and it is the only family that could give you pre-trigger history. Two classes: RfShotTx and RfShotRx.

  • RfStreamBuf — the continuous family, for designs where the reader and the writer overlap: load the next waveform while the current one plays, or drain a capture while still capturing. Unbounded in duration, at the cost of headroom and a reverse channel. Two classes: RfTxStream and RfSampBufRx.

Both names are families rather than classes — there is no RfShotBuf or RfStreamBuf to import.

See choosing a sample buffer for more detail on selecting between them — it turns the choice into one question you can check against your own design.

Table of contents

  • Rfdc - The converter itself: what Rfdc models, how to instantiate and wire it, its two sides — a block-rate sample channel on the RF domain and an ordinary AXI-Stream on the fabric — the block-sampling model underneath, and what that model cannot tell you.
  • RfShotBuf - The finite sample buffer: for designs where nothing reads the memory while something else is writing it. Two classes — RfShotTx plays a stored waveform, RfShotRx captures into a memory a reader drains behind it — both built on a lock over one true-dual-port BRAM, and both gated through real Verilog.
  • RfStreamBuf - The continuous sample buffer: for designs where the reader and the writer overlap. A family name covering RfTxStream on transmit and RfSampBufRx on receive; the transmitter is finished and RTL-gated, the receiver is the older BRAM design its replacement has not reached yet. Not yet written.
  • Choosing a sample buffer - Which sample buffer a design should use, decided by one checkable question: does anything read the buffer while something else is writing it? A no removes the feedback channel entirely — the whole memory is payload and there is nothing to size. A yes buys unbounded duration and changeable-mid-flight data, and costs headroom, a reverse channel, and every failure mode this section's rules exist to describe. Includes the classes each family name actually resolves to, what each cannot do, and the mistake of reaching for the continuous one because it sounds more capable.