• 0

Question

Hi @jpeyron

Kindly see the attached picture.

I have the following clocking options:

MIG_7series/ui_clk :83 MHz

clk_wiz_0/clk_out_1 : 166 MHz

And I want to feed my Pmod DA3 with the desired clocking rate. But I don't know what to choose from these clocks?

So could you help me in choosing the right clock for the two pin of Pmod DA3 ?

Thanks .

PmodDA3.JPG

Share this post


Link to post
Share on other sites

Recommended Posts

  • 1

Hi @Ahmed Alfadhel,

Looking at the Datasheet for the AD5541A here.The AD5541A operates at clock rates of up to 50 MHz and is compatible with SPI, QSPI, MICROWIRE, and DSP interface standards.  I believe the highest frequency would be 50 MHZ for the ext_spi_clk.  Its my understanding that we use the MIG_7series/ui_clk :83 MHz clock due to issues relating to the MIG/DDR.  I would also suggest looking at the AXI Quad SPI v3.2 LogiCORE IP Product Guide.

thank you,

Jon

Share this post


Link to post
Share on other sites
  • 1
Posted (edited)

If you look in the PmodDA3_axi_quad_spi_0_0.xci you will see that it is using a sck_ratio of 16.

image.thumb.png.2ec5457a17b47823e58d36611ac030da.png

 

In the AXI Quad SPI reference manual you will find

image.png.a543c86671c3afa821dc2c25e45d2892.png

and

image.png.5cc2adf9f1048ea01829a564633287d3.png

 

With your 50 Mhz clock, 50 Mhz / 16 = 3.125 Mhz.

Edited by kwilber

Share this post


Link to post
Share on other sites
  • 1

Hi @Ahmed Alfadhel,

@kwilber is correct.

I heard back from our content team. My guess was incorrect. We are using AXI4 Lite so it's definitely not XIP mode, since there is a "MODELPARAM_VALUE.C_XIP_MODE" parameter in the XCI files that is set to 0. They are under the understanding that we are using Legacy Mode .

thank yo,u

Jon

 

 

Share this post


Link to post
Share on other sites
  • 1

After going through the code posted in this thread, I want to amend my explanation of the 40 bits from yesterday.

In the testperiph.c file, the DAC is being written at line 104.

DA3_WriteSpi(&myDevice,  0x3A, &Hops_reading, sizeof(Hops_reading));

Hops_reading is a 32 bit value, so sizeof(Hops_reading) = 4.

In PmodDA3.c, in the function DA3_WriteSpi(),  the 4 gets passed as nData. The function prepends a 1 byte control word with address and write information. The function ends up writing all 5 bytes using the Xilinx SPI driver. 5 bytes * 8 bits per byte = 40 bits which is what you observed on the wire.

 

void DA3_WriteSpi(PmodDA3 *InstancePtr, u8 reg, u16 *wData, int nData)
{
    // As requested by documentation, first byte contains:
    //    bit 7 = 0 because is a write operation
    //    bit 6 = 1 if more than one bytes is written, 0 if a single byte is written
    //     bits 5-0 - the address
    u16 bytearray[nData+1];
    bytearray[0] = ((nData>1) ? 0x40: 0) | (reg&0x3F);
    memcpy(&bytearray[1],wData, nData);//Copy write commands over to bytearray
    XSpi_Transfer(&InstancePtr->DA3Spi, &bytearray, 0, nData+1);

}

 

Share this post


Link to post
Share on other sites
  • 1

As far as the sizeof()... here is a snip from cppreference.com.

image.png.3556486bd3709299f58e73f650f3a5d5.png

 

As far as your attempt to print the sizeof... if you look at the definition for print(), the argument is a char *, so you would need to pass a string. You passed the value 4 so the print function would interpret that as a string at address 0x00000004 which is going to point to some system dependent binary data.

image.png.7c25e59345dd303fce486d92844f0cf2.png

You can get to the definition by right clicking on "print" in your code and select "Open Declaration". 

image.png.e8ec43db07ac9d772384ee2594a3ba09.png

Share this post


Link to post
Share on other sites
  • 1

It looks to me like DA3_WriteSpi() was adapted from code for a different device and has vestigial and incorrect code.

Reviewing the AD5541A datasheet, several things stand out

  • There is only a single register in the chip so there is no need for the u8 reg parameter.
  • There is no need for a"config byte" to be sent before the data.
  • The transfer is always 16 bits so there is no need to allow for arbitrary length data
  • quoting from the datasheet "Input data is framed by the chip select input, CS. After a high-to-low transition on CS, data is shifted synchronously and latched into the serial input register on the rising edge of the serial clock, SCLK. After 16 data bits have been loaded into the serial input register, a low-to-high transition on CS transfers the contents of the shift register to the DAC register if LDAC is held low". Reviewing the PmodDA3 schematic, the ~LDAC signal is softly pulled to ground with a 10K resistor. So there is no need to explicitly toggle ~LDAC.

What all this means is DA3_WriteSpi could be simplified to something like

void DA3_WriteSpi(PmodDA3 *InstancePtr, u16 wData)
{
    u8 bytearray[2];

    bytearray[0] = ((wData & 0xFF00) >> 8);
    bytearray[1] =  (wData & 0xFF);

    XSpi_Transfer(&InstancePtr->DA3Spi, bytearray, 0, sizeof(bytearray));
}

You would then call it passing in just the instance pointer and the value you want to write to the DAC.

u16 dacValue = 1234;
DA3_WriteSpi(&myDevice, dacValue);

I do not have a PmodDA3 on my bench so I cannot verify the function works, You can give it a try and let us know how it goes.

Share this post


Link to post
Share on other sites
  • 0

Hi @jpeyron,

In order to specify the required clock of each ext_spi_clk and s_axi_aclk , I need to know the SPI mode of Pmod DA3 IP core .

According to PG153 ( AXI Quad SPI v3.2 LogiCORE IP Product Guide) page 15 there are different modes of operations for SPI protocol.

Looking forward your reply.

Thanks in advance.

Pmod DA3 IP core.JPG

SPI_modes.JPG

Share this post


Link to post
Share on other sites
  • 0

Thanks @jpeyron, because you contacted your team for me. I am waiting to their response. 

By the way, you said :

6 minutes ago, jpeyron said:

since the interface is set to AXI4

there is no AXI4 in Pmod DA3 IP core ! As I can see it is AXI_Lite_SPI buses.

Thanks again.

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

Hi @jpeyron,

I connected each of ext_spi_clk and s_axi_aclk to 50 MHz clock . But when I visualized the SCLK signal on my oscilloscope, it was only 3.13 MHz ! Why ?

Kindly, see the attached pictures.

Thanks . 

photo_2019-03-12_16-55-34.jpg

 

photo_2019-03-12_17-01-15.jpg

Edited by Ahmed Alfadhel

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

Hi ,

At first, I want to say thank you guys @kwilber , @jpeyron for feeding me with such  valuable informations . 

In the first attached picture, I am visualizing ~CS (chip select) signal on CH1 and SCLK on CH2. According to Pmod DA3 reference manual (second attached picture) , it must be there 16 pulses only for each active low period of ~CS signal.

Now, I am trying to learn how to set the clock pulses to 16 clock pulses only in this Pmod (DA3) . As you can see in the third attached picture the total count of clock pulses is 39 pulses.

It seems the clock frequency (3.13 MHz) is right according your explanations . 

I think the ~CS signal period need to be fixed, but I don't know how?

Looking forward your ideas. I am grateful for you.

Note : the fouth attached picture is from the data sheet of DAC AD5541A IC

Thanks .

SCLK and CS.jpg

16 pulses.JPG

39 pulses.jpg

Timing diagram.JPG

Edited by Ahmed Alfadhel

Share this post


Link to post
Share on other sites
  • 0

The address bits being sent should not pose a problem since ~LDAC gets pulled low after the data bits have been sent and that will transfer the last 16 bits clocked into the serial register to the DAC.

Admittedly, since the chip doesn't use the address bits, it is wasted time.

That is one of the cons when using third party IP - generality usually costs either performance or resources.

If you run into performance limitations, you would then consider coming up with your own logic for talking to the chip. In this case, the protocol is fairly simple. 

Share this post


Link to post
Share on other sites
  • 0

Hi @Ahmed Alfadhel,

In the testperiph.c the DemoInitialize() needs to be at the top of main. You need to have a function prototype for DemoInitialize()  as well.  I would also suggest making your main.c easier to use.  Something similar to the attached pmodda3_main.c below. You will need to create the function DA3_WritePhysicalValue. Use the PmodDA1.c and PmodDA1.h as reference. 

thank you,

Jon

pmodda3_main.c

Share this post


Link to post
Share on other sites
  • 0
11 minutes ago, kwilber said:

If you run into performance limitations, you would then consider coming up with your own logic for talking to the chip. In this case, the protocol is fairly simple. 

Hi @kwilber,

Do you mean I have to build my own IP core for Pmod DA3 using Vivado IDE , like that of Hamester ?

Share this post


Link to post
Share on other sites
  • 0

Hi @jpeyron,

21 minutes ago, jpeyron said:

pmodda3_main.c

did you test this Pmod (DA3) with the above piece of code previously? Or I am going the first one to test it using the IP core you gave me ?

I want to know what is I am doing . Working with a validated third IP core or I am just testing some IP core that was built roughly ?

Thanks.

Share this post


Link to post
Share on other sites
  • 0
Posted (edited)

You may not have to build your own.

That becomes a design decision that only you can make based on the requirements/specifications your design must meet.

If the performance you are getting out of the Digilent IP meets your requirements, there is no reason to roll your own.

On the other hand, if you are not able to meet your requirements and you are running up against limitations of the IP, then either look for a more performant IP or consider designing purpose specific logic.

According to your measurements, it takes 40 bits sent at a rate of 3.125 Mhz for each update of the DAC. That is at least 12.8 microseconds per update. Take the inverse of that and you have a maximum update rate of 78,125 updates/second. Is that sufficient for your design?

Edited by kwilber

Share this post


Link to post
Share on other sites
  • 0

Hi @Ahmed Alfadhel,

We have not had the bandwidth to create an IP core for the PmodDA3 as mentioned when I posted the generic SPI IP core Named PmodDA3. This IP core facilitates the usage of the pmod ports along with constraints so as all you should have to do is alter the PmodDA3.c PmodDA3.h and create a main.c. The PmodDA3_main.c is not validated. It would be the first draft when starting to create the custom functions needed to send desired output. 

thank you,

Jon 

Share this post


Link to post
Share on other sites
  • 0

Hi @jpeyron,

I found in PmodDA3_axi_quad_spi_0_0.xci  the property C_NUM_TRANSFER_BITS ( Transaction Width) was set to 8 bits (the default value) on line 90 and 112. I think it must be set to 16 bits, since the Pmod DA3 its resolution is 16 bits. 

Looking forward your reply.

Thanks in advance.

Vivado_IDE_parameter.JPG

Transaction_Width2.JPG

Transaction_width.JPG

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.