[ADC/DAC higher than 2 MSPs and >= 12 bits (No FMC)?]

@herve

As far as a board with ADC and DAC devices meeting your sampling and bandwidth requirements look at Terasic ( they are Intel FPGA based ).

As to actual ADC and DAC devices meeting your delay requirements this is tricky ( you'll have to run through the data sheets for the devices on the Terasic boards if they look promising ). I don't know of any converter boards that I feel comfortable recommending that you can easily ( or with some difficulty ) connect to your FPGA platform. The ADC spec. game is challenging even for seasoned engineers. You probably want to look at flash or pipeline architecture ADCs. The current output DACs tend to have the least delay. Once you've figured out what components you want to use there's the analog end to consider. Usually ADCs need a good driver amplifier to get performance and if you use a current output DAC you will probably have to use an OP AMP to get a voltage of the desired span. These all will have a deleterious effect on delay on both ends. There is no easy answer for your question.

[edit] If you need to do any processing such as frequency filtering on the ADC or DAC sides this will also of course affect both data and group delay but you will have some control over this.

 

[Cmod A7-35T Demo Project]

After mulling over my previous post here I thought that it might be good to post a few remarks about the IP in this project.

There's nothing specific to the CMOD-A735T in the code that makes up the IP, just that the dcp file was synthesized, placed and routed for that part. As my first offering of a project using Vivado I wanted to experiment with creating Vivado IP for distribution of functionality as opposed to source. I've since submitted a number of other projects to the Vault using the same IP but "compiled" for a different part. The basic functionality is part of a lot of my projects for internal use.

Having an HDL component ( really multiple components ) that converts std_logic_vectors to ascii hex and the other around is a very useful thing to have in your toolbox. Hopefully, you've looked though UART implementations in HDL ( even better taken the time to understand UART fundamentals and written your own UART ). If you have done that, you understand what a nifty thing it is to have is a UART based widget that allows for interacting with and debugging your FPGA design internals. Allowing a user to interact with this interface using a simple keyboard is, as I hope this demo shows, a very nice format for a number of reasons. 

There are a lot of ways to solve design problems. Usually the most obvious is also the most complicated and the least elegant. The most elegant solution usually requires some insight that often requires quite a bit of experience. That's my segue into commenting on the std_logic_vector <--> ascii problem.

There's a number of ways to address this. A simple lookup table ROM is the most obvious; and happens to be the way the the IP in this demo does it. I also use a generate statement to create an array of processes to do this. I did it this way because I really had never tried using a generate process approach before, not because it was necessary or even efficient. ( For me being able to experiment with new approaches makes FPGA development interesting and fun ). Having said that, you should know that the user interface is totally customizable with respect to the size of the std_logic_vector and the approach that I took supported this easily.

If I was going to rewrite this portion of the IP again I likely would have taken a different approach. I also would have taken a different approach than use lookup tables. Can you think of alternatives?

The std_logic_vector <--> ascii portion of the IP is by no means the bulk of the design but perhaps the trickiest, especially for custom IP that uses generics to support any size std_logic_vector ( or, perhaps,  unsigned ). There's nothing magical or innovative there. In fact, that's why I encourage whomever is reading this to work out their own solution. You don't need hardware... just ModelSim or Vivado simulator. That, to me,  makes it an ideal problem for newbie HDL artists to solve.

I do want to end by mentioning that your can use the same IP provided in this demo in your own Artix 35T designs by studying how I use it here.

[Cmod A7-35T Demo Project]

Hi  @abd,

Part of the CMODA35T demo was indeed integrated into an IP form. The source for that code is not currently in a release form. The objective of the demo is to provide an alternate, quick and painless way for individuals new to the Xilinx toolset to create a bitstream and see their new CMOD-A35T working. Please understand that there aren't many people getting paid to provide code or assistance around here; so there's that pesky trade-off of providing something for free and providing something intended to better the "community".

The more important purpose of the demo is to encourage users to try developing their VHDL skills; so providing a bit of motivation to have them design their own functionality isn't a bad thing from my perspective. There is plenty of HDL source available in the Digilent Project Vault to assist in this process. Of course, there are also a number of people willing to help with specific questions on this forum as well.

I realise that developing you own code base ( IP if you will ) is a daunting task for those getting started and using the development methods that Xilinx and Digilent prefer appear to be an easier short cut to working designs. I'm encouraging the longer, more difficult, path because I believe that the destination is a much better place to operate in. There are other forums within the Digilent ecosystem that offer a discussion of ideas and might be interesting or even perhaps useful.

I do thank you for mentioning that you tried out the demo. I have been encouraged to submit new projects to the Vault and always try to allow users to expand on the project's limited objectives by re-using source. 

[Cmod A7-35T Demo Project]

@stempelo,

It took a while to find out if anyone has tried out any of my posted projects... but thanks for the feedback. The project is as unambitious as one can get but does demonstrate an alternate to the standard Digilent demo and a lot easier to modify... plus it's relatively immune to Vivado versions. 

This was one of the first projects that I did and it had specific goals. You might find the S3 Starter Board Programmer project interesting as well as it features the CMOD-A7-35T in a different role and has more HDL example code.

[Cmod A7-35T Demo Project]

JColvin,

Sure, please do that. Tomorrow I'll be posting an esoteric but much more interesting project.

[Cmod A7-35T Demo Project]

CmodA735tDemo is a Vivado project that requires very little resources and is an easy way to try out the board's resources.

Requires Vivado 2015.2 or later and a Cmod A7-35T board. There is a Python program to run the demo that also requires Python 2.7 and pyserial 2.7 but any terminal emulation program such as Putty will also work, though with a bit more effort.

CmodA735tDemoR1.zip

NOTE: Vivado 2019.2 and later breaks the Vivado IP created in earlier versions. To build this project in Vivado 2019.2 just follow the README file except instead of adding the clk_wiz_0.xci file as IP you need to create an MMCM using the Vivado 2019.2 clock Wizard (use the default name) . The only thing that needs to be changed from the default settings is the input clock rate which is 12 MHz. I use the archive above from here to build the project just today using Vivado 2019.2 on WIN10.