*.xdc file upload (Zynq 7000 EPP, 7Z020 CLG 484-1, Revision D)

[Zed_Guy]

I own an Digilent Avnet Zedboard (Zynq 7000 EPP, 7Z020 CLG 484-1, Revision D). This is an older version of the zedboard.    Can anyone upload the master *.XDC file for this specific board? I looked at the master *.XDC files available at this website and I believe that it is incompatible with my specific development kit.   Is Silica Avnet, Xilinx, or Digilent, supposed to make this file available to the public.   I checked the website, GitHub, however, it appears that the file is missing.

The correct file should match, (or be very similar to),  the file made reference to on page 34 of the Silica Avnet Vivado tutorial that I have attached.

GRIFFIN ZEDBOARD.pdf

[Bianca]

Hi @Zed_Guy,

The ZedBoard XDC file is available on out GitHub here: https://github.com/Digilent/digilent-xdc/

I looked in your document and I saw that they changed the name of the ports in the XDC to match with their projects. You can either use in the project, the names used in the XDC or change in the XDC the names according to your project. By the fact that they are using "my_constraints.xdc" implies that they created a XDC file specific for the project in the guide, and probably used just what they needed. 

Normally, where you found the project and the guide, you should've been able to find the that XDC because it is not a generic Rev D XDC.

The pins marked in the document with red, are linked to the first 4 pins in the JA pmod connector. You can find them in the official XDC. 

 

You have two choices. Contact Avnet  and ask for that project specific XDC, or take the XDC from us and change it according to your project. 

 

Best regards,

Bianca

[Zed_Guy]

Hi,  Bianca;

     My apologies for a belated reply.   Since no one replied to my original post for a long time, I forgot about the post.   I found this post again by accident.   

     I need to get a copy of the old *.XDC file for Vivado 2013.4.  

     There is a significant change from the Vivado versions from year to year.   Program that will work in Vivado 2013.4 will not work in Vivado 2014.4.

      The changes from year to year are not trivial.   It appears that management at Xilinx corp. did not make efforts to make Vivado packages compatible.   

     If you could obtain a copy of the original *.XDC file that was installed with the 2013.4 release that would be greatly appreciated.  In fact, I will paypal you a small reward if you can do this for me.      Let me know if you warm up to this idea and, again, I would like to thank you for replying to this post.  

[JColvin]

Hi @Zed_Guy,

XDC files do not change between different versions of Vivado, though the IP blocks that are supported in a particular version are sometimes incompatible between versions. XDC files inform Vivado how to associate a physical pin to a "pin" (not the official name) in an HDL project. As Bianca noted, if you are looking for an XDC for a particular project designed by Avnet, you will need to contact Avnet for the XDC for that project.

Let me know if you have any questions about this.

Thanks,
JColvin

[Zed_Guy]

Dear Mr. Colvin;

        I would like to thank you for your reply.   

       When someone purchases a new product they expect the product to work out of the box.     When I made my purchase of my zedboard, the person whom I corresponded with on the installation and set up of a working Vivado & SDK system did not stress the importance of the *.XDC file.     When I attended college I was trained on a different Xilinx system, therefore, Vivado and *.XDC was new to me.     I completed some introductory labs but I later discovered that the *.XDC file is critical to getting some labs to work.    For example, I downloaded and installed Vivado 2013.4.     When I tried to complete labs that were taught using Vivado 2014.4 they would not work even though the *.XDC file was given by the instructor to the student.    I discovered after the port names used by Vivado 2013.4 were not the same as the port names used by Vivado 2014.4.     I believe that this is what you meant to when you wrote:

"the IP blocks that are supported in a particular version are sometimes incompatible between versions..."

        I looked at the most recent *.XDC master file and realized that using this *.XDC file is not going to be a solution at all.

        For the sake of having a stable reference point from which I can make reasonable determinations, I would like to obtain the original *.XDC file that should have shipped with my kit or have been emailed to me.      The person whom I was corresponding with over the telephone was not helpful at all and, in retrospect, most likely, knew nothing about how the product worked.    It was only through many experiments that I realized how critical the *.XDC file was.   

         When a fpga board developer make a hardware change, a revision, this will most likely affect the *.XDC file.   This represents a variable.   As you try to complete labs that may use a different version of Vivado and these labs may not reference the exact board information (the term "zedboard" has many variants).     Even if you look at the board as pictured in the tutorial - although they may look the same - there may be hardware revisions and this may affect the *.XDC file.      Therefore, in many cases, you have, at least, 2 variables to consider when you discover that your lab isn't working.     What I am trying to do is cut down on the uncertainty.   

         After reading your post, I am under the impression that if someone is unable to contact the hardware designer ("Avnet" in this case) (note that the uniformed customer does not know exactly who to contact because it would be plausible for the customer to believe that he must contact Digilent corp. - while others may believe that you should contact Xilinx corp.. - this becomes a real "round robin" situation) , in any case, in the circumstance that the engineer cannot contact the hardware designer with regard to a *.XDC issue is the solution to the *.XDC problem to look at the schematic diagram for GPIO related issues  (I am not even considering *.XDC issues related to clocking)?    Is this what everyone, who does not have technical support, has to do?

          I realize that looking at the Vivado floor planning view (or some other view) may be helpful but the copper traces on your PCB don't move around.    Maybe, you can link me to a "hands on" tutorial that has approached this issue or show me another method (maybe, I am overlooked something and another method exists).

         Again, I would like to thank you for your reply.

        

       

[Cristian.Fatu]

Hello,

I try to bring my opinion here to convince you that the xdc file that Digilent provides on its github (the one that @Bianca linked in her post) is good for you.

The xdc file links two major pieces of information for each signal:

1. FPGA pin (physical pin where a specific signal is attached to FPGA). This was decided when the board was designed, was physically implemented when the board was manufactured, and will never change.
2. A name attached to this line. You can see this as a label. This must match the name that signal is identified in user's project. Therefore, as @Bianca pointed, users have two options:
   • Use the default names for each signal in which case xdc remains unchanged.
   • Put own (suggestive) name for signals in which case they modify these names in the xdc file to match their names.

So finally none of these bits of information depends on the Xilinx version. You can read more in the Xilinx Using Constraints User Guide.

Although is does not apply in this matter, the project dependency on the Vivado version is an important (dramatic) matter that should be handled with care. As @JColvin pointed it affects the used IP cores.

 

[Zed_Guy]

Dear Mr. Fatu;

        I would like to thank you for your thoughtful post.     You defined the problem and I will try to re-define the problem in a manner that can be easily understood by someone who has no prior experience with Xilinx FPGA software products.  

         The hardware board designer (either, Avnet or Digilent, corp.) has the problem that with each annual change in the Xilinx Vivado version, new IP blocks inserted.    This means that every year since the IP block port names usually change,  this will correspond to a change that has to be made in the *.XDC file that is issued with the evaluation board.    The new user must make this change in the *.XDC file at his, or her, peril.     

         That is what Mr. Fatu meant when he wrote: "the project dependency on the Vivado version is an important (dramatic) matter that should be handled with care."

         Again, Mr. Fatu, I would like to thank you for your thoughtful reply and I would like to also thank Mr. Colvin and Bianca for their replies.    

            

[Cristian.Fatu]

You are welcome, thank you for your kind words.

No, this is not what I meant when I mentioned project dependency on the Vivado version. The IPs are not mentioned in the xdc file.

I quoted @JColvin and  I meant what he wrote: when Vivado version changes, some IPs versions may become obsolete, IPs should be upgraded to newer versions, IPs could be inconsistent with older versions so they will issue errors. But this has nothing to do with the xdc file.  

[Zed_Guy]

Dear Mr. Fatu:

       Thank you for your reply.     

       I do not know exactly what you meant when you wrote:  "IP are not mentioned in the xdc file".

       Everyone knows that when you create a design, an external port will most likely be created, therefore, the connection between the  IP and the xdc file has to be made.    

       When one refers to a Vivado version changing and  "upgrading IP" this usually corresponds to a cost to the user (if you know of a "free" way to upgrade my IP, I am all ears).      The upgrade cost that I am aware of is "steep."    I avoided this cost and managed to get a newer tutorial working on an older version of Vivado  by changing the *.xdc file (I worked through the error messages and got the project to work).     I would like to have the luxury of downloading the latest and greatest Vivado packages, however, companies and people are limited by the cost of the upgrade.      In other words, if your company is running a 32 bit Windows operating system, and if the latest versions of Vivado may require a 64 bit operating system, therefore, upgrading to the latest and greatest Vivado version may require purchasing a brand new PC.      This is just an example of how remedies to some problems are limited by cost.

        Again, I would like to thank you for your reply.     

[Cristian.Fatu]

Hello,

By 

Quote

"IPs are not mentioned in the xdc file".

I meant that if you open the xdc file you will never find something related to any IP.

Finally the answer is that we do not have any other xdc file than the one that we pointed, for the reasons explained in the previous posts.