1

I completed Anton Potočniks' introductory guide to the red pitaya board and I am now able to send commands from the linux machine running on the SoC to its FPGA logic.

I would like to further modify the project so that I can control the phase of the signal that is being transmitted via the red pitayas' DAC. Some pins (from 7 down to 1) of the first GPIO port were still unused so I started setting them from within the OS and used the red pitaya's LEDs to confirm that they were being set without interfering with the functionality of Anton Potočnik's "high bandwidth averager".

I then set the DDS_compilers' to Phase Offset Programmability to "streaming" mode so that it can be configured on the fly using the bits that are currently controling the red pitaya's LEDs. I used some slices to connect my signals to the AXI4-Stream Constant IP core, which in turn drives the DDS compiler.

my current setup

Unfortunately the DAC is just giving me a constant output of 500 mV.

I created a new project with a testbench for the DDS compiler, because synthesis takes a long time and doesn't give me much insight into what is happening.

simulation results from a testbench containing the DDS compiler

Unfortunately all the output signals of the DDS compiler are undefined.

My question:

What am I doing wrong and how can I proceed to control DACs' phase?

EDIT1; here is my test bench

The IP core is configured as follows, so many of the control signals that I provided should not be required:

IP core configurations

EDIT2; I changed declarations of the form m_axis_data_tready => '0' to m_axis_phase_tready => m_axis_phase_tready_signal. I also took a look at the wrapper file called dds_compiler_0.vhd and saw that it treats both m_axis_phase_tready and m_axis_data_tready as inputs.

My simulation results remained unchanged...

My new test bench can be found here.

EDIT3: Vivado was just giving me the old simulation results - creating a new testbench, deleting the file under <project_name>.sim/sim_1/behav/xsim/simulate.log and restarting vivado solved this problem.

I noticed that the wrapper file (dds_compiler_0.vhd) only has five ports:

  1. aclk (in)
  2. s_axis_phase_tvalid (in)
  3. s_axis_phase_tdata (in)
  4. m_axis_data_tvalid (out)
  5. and m_axis_data_tdata (out)

So I removed all the unnecessary control signals and got a new simulation result, but I am still not recieving any useful output from the dds_compiler: without control signals

The corresponding testbench can be found here.

I also don't get any valid output when I include the control signals. with control signals

The corresponding testbench can be found here.

Chandran Goodchild
  • 289
  • 3
  • 16

1 Answers1

1

Looks like m_axis_data_tready is not connected. No data will come out unless that's asserted.

Justin N
  • 780
  • 4
  • 7
  • Good point! My test bench now contains `m_axis_data_tready <= '1';` and `m_axis_phase_tready <= '1';`, but the simmulation results didn't change. I think there are some mor problems with my test bench, I will add the code to my question... – Chandran Goodchild Feb 17 '20 at 14:39
  • 1
    phase_tready should be an output from the DDS. Are you sure some of the U's didn't change to X when you added that code? – Justin N Feb 17 '20 at 14:56
  • Yes, all the outputs are still U's, but I noticed that I was connecting some ports to constants instead of signals (like `m_axis_phase_tready => '0'`). I am now mapping the ports of `dds_compiler_0` to their respective signals and I still have undefined outputs (see EDIT2). – Chandran Goodchild Feb 17 '20 at 16:07
  • 1
    I don't see any TB code that matches any of those waveforms, so it's hard to say. But in the simple setup without all the control signals, you should not be seeing the 'U' output. – Justin N Feb 18 '20 at 08:38
  • Sorry, I left out some testbenches because my question was getting very verbose. All the testbenches have now been attached as external links. The problem with the `U` at the `m_axis_..._tready` signals was resolved after renaming the testbench and restarting vivado. Maybe now the problem is with the content of my input? – Chandran Goodchild Feb 18 '20 at 10:02