Jump to content

Cmod A7-35T Demo Project


zygot

Recommended Posts

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.

Edited by zygot
Link to comment
Share on other sites

Very cool! I don't personally have a Cmod A7-35T to try it out for myself, but definitely looks very useful to try a number of features out without having to worry about any IP getting updated on you. The readme is also very detailed, which is nice.

Do you mind if I post this on the Cmod A7 Resource Center page as a community project (with a link back to this thread)?

Thanks,
JColvin

Link to comment
Share on other sites

  • 1 year later...
On 3/10/2016 at 6:39 PM, zygot said:

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

Thanks!! Very good project.

Vivado 2017.4

Windows 10

Perfect!!!

Link to comment
Share on other sites

@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.

Edited by zygot
Link to comment
Share on other sites

  • 5 months later...

@zygot

I am new to vivado tools . I am testing your demo code. It looks like you have created IP of the entire design to be specific to CMODA7. 

I don't find the VHDL files of the complete design. Could you please share them as well. 

Link to comment
Share on other sites

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. 

Edited by zygot
Link to comment
Share on other sites

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.

Edited by zygot
Link to comment
Share on other sites

  • 1 year later...

I am trying to program the CmodA7 Demo OOB. I have downloaded the .ZIP file (18.2) from the GIT site. Here are the problems I am encountering:

1) No .bit file.

2) No .xpr file.

3) The instructions reference files that do not exist in the ZIP.

Is there a way I can obtain the OOB bit file for the CmodA7?

Can the instructions be freshened to match the ZIP file structure?

Link to comment
Share on other sites

Couple of things are my fault:

1) I needed to go to the "release files" to find the correct ZIP; my bad.

2) I have Vivado 19.2 and the IP between 18.2 and 19.2 is incompatible.

3) There is NOT a bitstream file in the ZIP. 

My next steps are to recreate the design using 18.3 (18.2 no longer available). I attempted to read the NVM as is; it appears to be write protected.

Link to comment
Share on other sites

13 minutes ago, skywalker said:

2) I have Vivado 19.2 and the IP between 18.2 and 19.2 is incompatible

You are correct that Vivado 19.2 has broken IP from previous versions. I'll try and create a release for Vivado's latest. Meanwhile, though I haven't tried it yet , I expect that if you create your own MMCM using the Vivado 2019.2 IP Wizard you should be able to build the project using the other sources..

15 minutes ago, skywalker said:

3) There is NOT a bitstream file in the ZIP.

I prefer that users create their own bitstream.

19 minutes ago, skywalker said:

I attempted to read the NVM as is; it appears to be write protected.

NMV ???

Link to comment
Share on other sites

There are other posts dealing with using the NMV. Be careful as once you have something in your FLASH device that starts the configuration process you can find your module appearing as a bricked board.

Edited by zygot
Link to comment
Share on other sites

1 minute ago, skywalker said:

If I load a bad configuration into a board; I like to be able to return to a known OOP baseline to test the board and make sure I did not damage it.

I appreciate that argument. I try and avoid providing executable programs, text source using embedded scripts, and anything depending on tools having the letters JAVA in it for the same reasons. From my perspective, providing a constraints file that can be read and checked plus source HDL is the safest thing for everyone.

You should be in the practice of checking the post place and route pin assignments for all new project bitstreams regardless. Even if you think that you are using a constraints file with valid location and IOSTANDARD assignments things happen....

 

Link to comment
Share on other sites

I have built the CmodA7 using Vivado 18.3. The IP generator complained about the IP upgrades being incompatible, however, I was able to go through all 19 steps.

Errata/Notes in the GIT CmodA7 instructions:

1) Step #4 - I had to build the design, including the generation of the IP, before step #4 could be performed.

2) Step #8 - I referenced "user_1_wrapper_hw_platform_0" instead of "design_1_wrapper_hw_platform_0".

3) Step #18 - Make sure you select: "Cmod-A7-35T-OOB" instead of "Cmod-A7-35T-OOB_bsp" to perform the "Run As" operation. My bad.

4) Step #19 - Typo. It is imbedded into step #18.

5) Step #16 - I used PuTTY and had to go into the Windows Device Manger to find the correct COM port to use. Just saying.

6) Things fall apart for Vivado 19.2 at Step #5. Previous discussion have indicated that a 19.2 steps will be investigated.

Result.jpg

Link to comment
Share on other sites

require

7 minutes ago, skywalker said:

I have built the CmodA7 using Vivado 18.3

Well, I'm happy for you but what you built wasn't this project. I don't use Microblaze.

You might want to go to the top of this thread and download the zip file and try out my project as an alternative. I just downloaded the archive file from the Digilent Project Vault to my WIN10 box and built it using Vivado 2019.2. I just had to create the MMCM component in Vivado 2019.2.

 

Link to comment
Share on other sites

I knew that there was some confusion when I saw OOB... just didn't get the specifics correct. This project is referenced as a Community Project with link in the CMOD A7 Resource Center. The OOBs from Digilent typically use the MicroBlaze board design flow. I don't unless the target is a ZYNQ based board. My project isn't in the Digilent GIT.

Download CmodA735tDemoR1.zip from the top of this thread and try it out. I have a nice Python script to interact with it and reasonable documentation.

Read the README.txt in my project to see what it does. Compare the flow for both projects and compare the resource usage for both projects. My project wasn't Vivado version dependent until Vivado 2019.2 came along but as mentioned on the first page of this thread still works albeit with a little extra effort.

I'm not sure how you conflated Digilent's project with mine; but that doesn't really matter... I still think that mine's more useful. You can use the dcp as a source in your own project using this one as a guide.

If I'm a bit shocked by anything, it's that the latest verison of Vivado still works with a dcp created in Vivado 2015.

Edited by zygot
Link to comment
Share on other sites

It took me less than 10 minutes to download the archive from this thread to my Win10 box and create a bitstream. At least try it out and let me know what you think. 

After 2019 all of my Python 2.x code will become depreciated so it may be awhile before I do a rewrite.

Link to comment
Share on other sites

Hi @skywalker,

Which Digilent blog post were you looking at which linked to this forum thread? I know the Cmod A7 Resource Center in the Example Projects section links to this forum thread (after I got permission from zygot to do so), but I would like to make sure that our blog posts link to the correct information.

Additionally, the reason you had to regenerate the bitstream for step 4 for the Cmod A7 OOB demo was because you were using Vivado 2018.3 when the release was designed for Vivado 2018.2.

Thanks,
JColvin

Link to comment
Share on other sites

  • 1 year later...

Hello Zygot,

Thanks for posting this example, it is great - and the unique complete resource available for this board.

I just got a Cmod A7 board and tried to create a similar project (with some extra components specific to my application), I've designed with Virtex 7 and the Arty a7 board before so I thought I'd get it straight, however I have a problem with the uartlite, it gets stuck transmitting after the 6th or 7th character output. The TX Full flag is never released so it gets stuck there.

So I decided to use your project as base and work from there.

Following the instructions you provided it all works flawlessly (executing your app as is). Next I repeat the process but this time I have Vivado update the project and IP since I'm using 2019.1. In this case the only problem I had is that SDK by default generates a linker that places all sections in the external ram instead of the local BRM. This generates an error when programming the board. I just re-generate the linker script changing the sections to be placed in local BRM and then it works ok. Then I move some of my own project's code to yours and... it all works! Still, then I add my IPs and stuff to your project, and it all works.

However, it frustrates me that, as mentioned earlier, when I build everything from scratch the uartlite doesn't work properly. I compare my own project with yours and they seem so similar, the only difference are my extra IPs (which have nothing to do with the uart) and in your project there's an axi_mem_intercon connected to the external ram.

- Can you explain the reason behind adding the axi_mem_intercon?

- When you created your project did you have any problems with the uartlite? did you have to adjust anything in particular for your project of just followed the regular workflow?

Best regards and thanks again!

Edited by edge30
Link to comment
Share on other sites

8 hours ago, edge30 said:

in your project there's an axi_mem_intercon connected to the external ram.

Nope, no AXI-anything. I don't use MicroBlaze so there's no need for overly complex bus structures. I never envisioned anyone wanting to use the CmodA735T_test.dcp netlist with a soft processor as the demo, in part, was meant as a MicroBlaze-centric alternative.

The netlist has a state machine for writing and reading code. It's pretty simple. The main feature of the demo though is the UartAccess code. I use this in almost all of my projects for every platform, at least during development. It even works with the Intel platforms, though not typically at anywhere near 921600 baud. I think that this is due to the way that Quartus implements the VHDL and possibly the Cyclone logic architecture.

Being able to read/write std_logic_vector elements just as they appear in the logic, regardless of HOST endiandness is a remarkably useful tool to have. Using a UART lets me do debug, or just a user interface, using only 2 spare pins and a TTL USB UART cable or breakout board. 

I'm curious about what caused you to think that the demo had any AXI IP in it.

One of these days, I plan on getting around to posting a refresh for the RegAccess core....

Edited by zygot
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...