PMOD DA4

[Gill]

Hello,

I am trying to use the pmod DA4 with my Arty S750 board. I'm aware that Digilent does not offer an IP for interacting with the Pmod, so I took it upon myself to design one.

Anyways, things seemed to be going well until I actually tested the DA4. I know that the DA4 uses SPI to communicate, so I programmed the IP to communicate that way, and it does (outputs from the pmod connector correctly seen on an oscilloscope), but every time I connect it to the DAC I can't get much of anything to come out of the channels.

I've read through the AD5628 reference manual, but a few things were ambiguous to me. First the commands on table 9. I don't really understand the difference between writing to the register (command 0) and writing to the DAC channel (command 3), and which I should be using for my project. And second, I plan on using an internal voltage, and it says that setting up the internal voltage is the first step. As I have it now, it's the first thing my program does and I'm afraid that the DAC is unable to read this input (maybe I should add a brief delay? I saw a brief delay in the "simon says" code).

I know it's been a long post, but any answers or insights on the DA4 or any other part of my post is much appreciated.

Thanks,

Gill

[JColvin]

HI @Gill,

The command 0 (write to Input Register n) just provides the initial data to an internal register, but from my understanding does not actually update the output pins to reflect what was provided. Command 3 on the other hand loads all of the data you provided and then also puts that data into the output registers so you can see the results in a single command sequence, rather than doing command 0 and then (I believe) command 6 (Load LDAC register).

A small delay was added in the Simon Says code because on page 23 of the datasheet in the serial interface section, it mentions that the SYNC line (essentially chip select) needs to be brought high for a minimum of 15 ns for new commands to be processed; the simon says code isn't that tight timing wise, so I suspect it delays for 1 millisecond. There is also an output voltage settling time that can last up to 7 uS, though the typical value is quoted to be 2.5 uS in Table 3 of the datasheet, so if you are updating data really fast, you may not see the proper output. The other thing I would check is to see what clock speed your SPI clock is running at, since I believe the maximum frequency is 50 MHz.

Let me know if you have any questions about this.

Thanks,
JColvin

[Gill]

 @JColvin

Thanks for the quick reply.

I suspected that was the case for the command, so for my project I'll just stick with command 3.

My sclk is at 20 MHz right now (generated in the clock wizard of my block design), so it shouldn't be much of a problem. But I read more into the SPI specs and I saw something about clock polarity and phase. I note that in "Simon Says" that the SPI mode is 0 (clock polarity = 0, clock phase = 0), and I was wondering if that was my issue, that the data is being captured and sent at the wrong edge of my clock. I will post a simulation timing diagram along with this post, and maybe we could draw something from it.

cs - chip select (pin1)

data_out - mosi (pin2)

sclk - serial clock (pin4)

d_clk - 20 MHz input clock (even though it's 100 MHz in the picture)

Thanks,

Gill

[JColvin]

Hi @Gill,

Your captured screenshot looks good in terms of clock edges and data sent to set up the internal reference; the 100 MHz capture is disconcerting since that looks like an oscilloscope capture, but I'll take your word for it that it is actually at 20 MHz. To a certain extent, it won't hurt to cut your clock rate by 10 fold to confirm there isn't something weird since the part won't complain.

Are you sending out any data to update the DAC registers afterwards? By default I don't think there is any data in them so there won't be any output unless you provide the part data.

Thanks,
JColvin

[Gill]

Hey @JColvin,

The screenshot captured above was from Vivado's simulation.

I've revised my test bench to now have a 20 MHz clock and to also span over a longer duration, so we can see both the reference voltage command and data output commands. I'll post the screenshot below. The lowest clock frequency my project allows is 4 MHz, and I've tested at that frequency with the same results as before.

Also, I was able to get captures from my oscilloscope (I'll post these below). These captures are directly from my Arty's pmod JA port. I'm able to pass data through these ports using Vivado's SDK. I know this because when I run my application in SDK, I see pulses on the oscilloscope for where the data is on the wave form (the 12 bits directly after address bits). So I think everything is taken care of on the FPGA side of it, but the DAC is still not responding.

I also had an Arduino laying around that I thought I could use as another test for the DAC. I went ahead and stripped some of the code out of the "Simon Says" project and uploaded it , but once again I don't get a response from the DAC.

Thanks,

Gill

Yellow - Chip Select

Blue - Data Out

Yellow - Chip Select

Blue - Serial Clock

[JColvin]

Hi @Gill,

I apologize for the delay. Which channel are you attempting to read out of from the Pmod DA4? It seems you are looking to produce approximately 35 mV out of VoutA on the Pmod DA4, correct? I tried out the code that it looks like you are attempting to use and was successfully able to get the desired value within a couple of millivolts.

Thanks,
JColvin

[Gill]

Hey @JColvin,

So my buddy was able to get the DA4 working on our Arduino Uno. So the chip works well and appropriately.

I'm beginning to think the problem is with the output signals of the Arty's Pmod ports. When looking on an oscilloscope, the Arduino Uno has better pulse shapes compared to the Pmod signals (rise and fall times on the Pmod signal are not that good). I guess for now, the goal is to find out why, and either fix it or work with it. Any insights or leads on the Pmod ports, other than that what is in the reference manual, would be much appreciated.

If my partner and I do find a fix to our problem, we'll be sure to post back with the solution.

Thanks, 

Gill