Signal generation via HDL Coder

Applications, development tools, FPGA, C, WEB
rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Signal generation via HDL Coder

Post by rothmart » Wed Oct 19, 2016 2:33 pm

Dear Forum!
Using the „Blinking LED Project” (http://redpitaya.com/examples-new/fpga- ... -tutorial/) in Vivado 2013.3, I wish to use the RedPitaya first as a sine wave generator and later on as transceiver. Therefore, I generated Verilog Code with help of Matlab’s HDL Coder (sine wave block properties appended). This Verilog Code was integrated into my project, as you can see in the schematic appended.
In Vivado I connected the output of the sine wave block with the input of the DAC using a wire (image appended).
Unfortunately, the analog output of the RedPitaya does not show a sine wave of desired quality: Actually, the output signal looks fine, but in periodical distances, the output is crap. There is also an image appended.
Can you imagine a reason for this behavior?
Regards.
You do not have the required permissions to view the files attached to this post.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: Signal generation via HDL Coder

Post by Nils Roos » Fri Oct 21, 2016 1:26 pm

This could be a synchronisation issue. It is not clear from the pictures where you connected the clock to your HDL coder module.

The DAC is in the adc_clk clock domain (synchronous to the ADC clock input), but the housekeeping module is in the sys_clk clock domain (synchronous to an internal fpga clock). To funnel signals from one into the other you need to employ measures for clock domain crossing.
All in a day's work for Bicycle Repair Man

rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Re: Signal generation via HDL Coder

Post by rothmart » Fri Oct 21, 2016 3:29 pm

Yes you are right, the clock has to be adc_clk. Now it works fine and the signal has a good quality.

Thanks for your help!

rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Re: Signal generation via HDL Coder

Post by rothmart » Wed Oct 26, 2016 11:19 am

Although the redpitaya seems to work corect i have some further questions. I tried out different HDL codes (for example: signal-generation and FIR filter) and initiated the Sinus-module

Code: Select all

module Sinus
          (
           clk,
           reset,
           clk_enable,
           ce_out,
           Out1
          );
in this way:

Code: Select all

Sinus Sinus_Generator
          (
           .clk(adc_clk),
           .reset(reset),
           .clk_enable(1'b1),
           .ce_out(ce_out),
           .Out1(data_dac_a)     //connected to   .dac_dat_a_i        (  data_dac_a       ),
          );
I think this connection luckily works (unknown variables still conect to ground), but i want to know what exactly should be inserted. Which connection has to be chosen for .reset( x ) / .clk_enable( x ) / .ce_out(ce_out) ?
Please keep in mind that i aim to use the Verilog code by Matlab HDL Coder directly in an easy way, so this ports are very important to know.

Regards!

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: Signal generation via HDL Coder

Post by Nils Roos » Wed Oct 26, 2016 8:05 pm

The reset signal that is tied to the adc_clk domain is adc_rstn. It's active low, so you'd use ".reset(~adc_rstn)". 'clk_enable' and 'ce_out' have no predefined counterpart in the Red Pitaya logic.

If you'd wanted to pause the generator, you could do that by setting 'clk_enable' to 0. I suppose 'ce_out' is an output that mirrors 'clk_enable'. For normal, uninterrupted operation, ".clk_enable(1'b1)" and ".ce_out()" - ie unconnected - are ok.
All in a day's work for Bicycle Repair Man

rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Re: Signal generation via HDL Coder

Post by rothmart » Fri Oct 28, 2016 10:10 am

Okay, i also agree to that and it works fine with the sine signal. In addition i want to ensure the HDL Coder process by implementing a FIR Filter between IN1 and OUT1.

So therefor the initialisation was:

Code: Select all

BandpassModel (
 .clk (adc_clk),
 .reset(~adc_rstn),
 .clk_enable( 1'b1),
 .In1( adc_a),
 .ce_out( ),
 .Out1(data_dac_a)
);
The configuration in HDL Coder you can see in the appendix. The Quantization was set to signed fixed-point at 14-bit input and 14-bit output. So well, but the signal output doesn't fit at all. For example there is a high noise without any input. If i choose a higher precision the utilization of xc7z010clg400-1 isn't sufficient anymore.

With the use of Xilinx FIR IP Core the filter works fine and outputs a high signal quality.

Can you guess what is important for the use of HDL Coder? Maybe the data type and the precision should be adapt? Or is there any specification by implementing the verilog code directly?
You do not have the required permissions to view the files attached to this post.

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: Signal generation via HDL Coder

Post by Nils Roos » Fri Oct 28, 2016 9:43 pm

14 bit signed fixed point should be compatible with the Red Pitaya channels, but it may be worth looking into if that's really true.

What was the result of the implementation run? Were there a lot of timing violations (they show up as critical warnings but a bitstream is produced regardless)?
All in a day's work for Bicycle Repair Man

rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Re: Signal generation via HDL Coder

Post by rothmart » Mon Oct 31, 2016 4:27 pm

I tried to check the data type and found in red_pitaya_analog.v

Code: Select all

 *                 /------------\      
 *   ADC DAT ----> | RAW -> 2's | ----> ADC DATA TO USER
 *                 \------------/
 *                       ^
 *                       |
 *                    /-----\
 *   ADC CLK -------> | PLL |
 *                    \-----/
 *                       |
 *                       ˇ
 *                 /------------\
 *   DAC DAT <---- | RAW <- 2's | <---- DAC DATA FROM USER
 *                 \------------/
 *                       |
 *                       ˇ
 *                   /-------\
 *   DAC PWM <------ |  PWM  | <------- SLOW DAC DATA FROM USER
 *                   \-------/
So from this schematic it should be a signed input and a signed output.

On the other hand i was a little bit confused by the contrary coments in

line 138:

Code: Select all

assign adc_dat_a_o = {adc_dat_a[14-1], ~adc_dat_a[14-2:0]}; // transform into 2's complement (negative slope)
and line 224:

Code: Select all

// output registers + signed to unsigned (also to negative slope)
always @(posedge dac_clk) begin
   dac_dat_a <= {dac_dat_a_i[14-1], ~dac_dat_a_i[14-2:0]};
   dac_dat_b <= {dac_dat_b_i[14-1], ~dac_dat_b_i[14-2:0]};
   dac_rst   <= !dac_locked;
end
So which data type should now be inserted in this case? Or is that an internal conversion?

Nils Roos
Posts: 1441
Joined: Sat Jun 07, 2014 12:49 pm
Location: Königswinter

Re: Signal generation via HDL Coder

Post by Nils Roos » Mon Oct 31, 2016 9:51 pm

These transformations are there to convert the output format of the ADC to 14bit signed values in 2's complement format and vice versa for the the input format of the DAC. In their default configuration, the ADC and DAC ICs use a different format, which is converted into a common signed type for convenience. All internal signal paths are of that type.
All in a day's work for Bicycle Repair Man

rothmart
Posts: 14
Joined: Fri Nov 13, 2015 3:10 pm

Re: Signal generation via HDL Coder

Post by rothmart » Fri Nov 04, 2016 12:15 pm

Okay, i verified the data format with a logic analyser and it should be a 14bit signed adc output. So i retried the implementation with Matlab Filter Designer and choose a 14bit signed input/output quantization for the filter. Although i set up the input on idle, the output signal is very high and incorrect. So what else could cause this?

There are no critical warnings in generating the bitstream. The timing reports seems to be okay 'All user specified timing constraints are met'.

But there is a high utilization noticeable:
FF: 5%
LUT: 49%
I/O: 81%
DSP48: 100%
BUFG: 44%
PLL: 50%

Could that cause any run time errors?
You do not have the required permissions to view the files attached to this post.

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: No registered users and 2 guests