Problems Getting started with Nexys 4 DDR

[jcchong]

I recently got a Nexys 4 DDR and I'm trying to get started with a simple switch/blink-LED program. I'm using ISE Design Suite 14.5 (nt64) and I'm getting warning messages that's preventing the design from completely compiling. This is what I tried:

• Created a very simple design (in schematic mode) using three switch inputs, an LED output, and basic logic (AND & NAND)
  • Added 3 ibuf, one for each input and an obuf for the output
  • Assigned each ibuf/obuf pin numbers from reference manual (e.g. LOC = J15)
  • Added I/O markers, labeled A, B, C (inputs), and F (output)
• Get the following warning messages during compile (Implement Design > Map)
  • WARNING:LIT:701 - PAD symbol "A" has an undefined IOSTANDARD.
  • WARNING:LIT:702 - PAD symbol "A" is not constrained (LOC) to a specific location
• Thus, I'm unable to generate a Programming File (bit file?)

What am I doing wrong? Am I missing a step? This was pretty much the same procedure I followed when I worked with the first-gen Basys board, using an older version of ISE (9.2), and I was able to do much more complex designs with no problems. From what I understand, I would create a design in ISE 14.5, compile it using Synthesize-XST, Implement Design, and Generate Programming File (bit file?). Then I would send the bit file to the Nexys 4 DDR using Digilent Adept? 

 

Should I start using the Vivado Design Suite? I heard it's like $2000+ for a license. I also heard there's a device-limited license? 

[hamster]

These errors usually indicate that the project's devices settings are incorrect. Can you check that your project's device settings are as follows?

 

Family: Artix 7

Device:  XC7A100T

Package CSG324

Speed    -1

 

 

These were based on the Nexys 4 web page, which indicates it is using an XC7A100T-1CSG324C

 

A quick way to do this in ISE is to look at the top level in the "Design" window.

 

Mike

[hamster]

Awesome write-up - I'm sure it will save quite a few people quite a bit of head-scratching! 

[hamster]

I wonder if it is somewhat related to the reason I eschew using any Coregen IP unless I really have too. Any generated files are © Xilinx, and should not be redistrbuted, except for the XCO file in the ipcore_dir (which is yours to keep). The other files have lots of comments like:

--------------------------------------------------------------------------------
--    This file is owned and controlled by Xilinx and must be used solely     --
--    for design, simulation, implementation and creation of design files     --
--    limited to Xilinx devices or technologies. Use with non-Xilinx          --
--    devices or technologies is expressly prohibited and immediately         --
--    terminates your license.                                                --
--                                                                            --

--------------------------------------------------------------------------------
...

--    (c) Copyright 1995-2015 Xilinx, Inc.                                    --
--    All rights reserved.                                                    --

 

If the file has this header in it they should not be given to anybody who hasn't agreed to Xilinx's licensing terms.

 

It gets really, really annoying really quickly if you want to share your work but still act within the terms of the license.

[JColvin]

Hi Paul,

 

Are you seeing the "all rights reserved" in the vivado.txt file that is available as a .zip download on the DDR user demo page?

 

If so, I believe that phrase strictly applies to Vivado itself, not the IP block (at least in this case). Otherwise, all of the information that you see on our wiki page is licensed under the CC Attribution-Noncommercial-Share Alike 3.0 Unported, unless otherwise noted as per the bottom of each wiki page  

 

Let me know if you have any more questions.

 

Thanks,

JColvin 

[gardners]

Hello all,

 

Thanks for the very helpful tips.  It turns out that I had messed up a couple of signal names in the UCF file, causing bitgen to fail, so I was running the old design file on the new board.  In other words, as suspected I did something royally stupid.

 

I now have it working, and I can read and write the DDR2 RAM.

 

The next step is to implement a read cache, since the DDR2 RAM has such horrible latency, even compared with the cellular RAM on the original Nexys4 board. Of course, it does have much, much higher bandwidth once it gets going.

 

Paul.

[hamster]

Paul, 

 

I just checked your your lines for the button and switch above, and they agree with the schematics (which are usually authoritative in these matters) and the UCF file (which is a little more open to errors), and they all agree.

 

So I think the issues is the UCF being ignored - the Pinout Report will tell you for sure.

 

Mike

[jcchong]

Another thing to note before running Synthesize and Implement Design is to make sure that the UCF file is on the top level. Otherwise it will give you the same warning about I/O Standard, which prevents you from finishing the compilation.

[hamster]

Have a look at the pinout report. It will confirm that the tools are giving you what you asked for - look for the pin name, the signal name and if is 'located' by an active constraint.

Sometimes ISE can somehow ignore constraints files. When this happens I remove them from the project and add them back in. It usually happens when you change the top level of a design.

If it is using the hardened memory controller the signal locations for the DDR might be constrained by the physical connections that the FPGA supports, so it might still work without the appropriate constraints.... (A bit of a long shot though!)

Most likely is that to support the DDR using the MCB the pin assignments had to change....

[gardners]

Hello again,

 

After having updated my UCF file to use the pin assignments for the new board, I now have my design synthesising on the Nexys4DDR.

 

The switch assignments are all messed up.  Is the schematic for the DDR board correct for the Revision C, or has it been changed since?

 

For example, toggling sw<15> causes my design to think that the down button is being pressed.  That is, toggling switch 15 toggle pin P18.

 

What is really curious is that pin V10 was the down button on the original Nexys4 board, suggesting that some part of the build process is using stale pin assignments, perhaps by reading an old UCF file. However, if that were the case, it shouldn't be able to synthesise, because the pin names for the DDR interface would be undefined.    Also, I have grepped through every .UCF file on the build machine, and the only reference to pin V10 is for sw<15>, which is the correct assignment for the DDR version of the board.  But the most convincing evidence that there is no caching going is that the .PAD file for my design shows that the down button is correctly assigned to pin P18, and sw<15> to V10:

 

...

P18|btn<1>|IOB33|IO_L9N_T1_DQS_D13_14|INPUT|LVCMOS33|14||||NONE||LOCATED|NO|NONE|

...

V10|sw<15>|IOB33|IO_L21P_T3_DQS_14|INPUT|LVCMOS33|14||||NONE||LOCATED|NO|NONE|

...

 

 

It is just as likely that it will turn out that I have done something royally stupid, but if anyone has seen this problem and has some pointers, I would appreciate the leg-up.

 

Thanks,

Paul.

[gardners]

Hello,

 

Thanks.  I'll take a look.

 

Meanwhile, I am looking at the DDR controller implementation in the user demo application for the Nexys4DDR, and the copyright notice says "all rights reserved".  This would imply that we cannot use it and distribute it in our own designs.  Is there an additional more permissive license for this?

 

Thanks,

Paul.

 

gardners,

 

The Digilent Wiki can be found here: reference.digilentinc.com.  We (Digilent) are still working on getting it all put together, but you'll be able to see new updates on the various pages as we get them completed.

 

Thanks,

JColvin

[Alex]

Hi it is an clear and precise guide for the beginner

[JColvin]

gardners,

 

The Digilent Wiki can be found here: reference.digilentinc.com.  We (Digilent) are still working on getting it all put together, but you'll be able to see new updates on the various pages as we get them completed.

 

Thanks,

JColvin

[jcchong]

Hi Hamster,

 

The magic fix was what you mentioned, to have the following settings for a new project:

• Family: Artix 7
• Device: XC7A100T
• Package: CSG324
• Speed: -1

Here are the steps to get a simple design up and running.

• Download Master UCF file from Nexys 4 DDR product page and save it to a directory you can find it
• Create your design and assign I/O markers
• In the Design Heirarchy side-menu, right-click on the top-level (xc7a100t-1csg324), click Add Source, and select the Master UCF file that was downloaded from the product page
  • Double-click on the downloaded UCF file and uncomment the I/O ports you wish to use for your design
  • Change the net name of the I/O pin to the net name you assigned on the schematic
• Run Synthesize - XST, Implement Design, and Generate Program file (bit file)
• Run Digilent Adept, connect the USB cable to the N4-DDR, and power on the board
  • The N4-DDR should now be visible on Digilent Adept
  • In the Config tab, select the generated bit file (from ISE 14.5), and click Program
  • Test your design using the I/Os you specified in the UCF file

[gardners]

Sorry for the very basic question, but where is the digilent wiki?  I have tried searching for it, but cannot find it.

[hamster]

Just so anybody who encounters the same problem can also also solve it, What was the magic fix?

 

Even if it seems a silly oversight in retrospect, posting it may help somebody else save a few hours of frustration!

[jcchong]

Thanks a lot Alex and Hamster, I got it working. The initial configuration was a bit confusing, now I can move on to more complex designs. 

[jcchong]

Hi Alex, 

 

I removed the ibufs and obufs and added the downloaded UCF file (Nexys4DDR_Master.ucf). I uncommented the I/Os that I'm using (SW0, SW1, SW2 and LD0). I figured that the net name mapped to the pin would be whatever I named the net in the schematic, in this case, A, B, C, and F. For example, in the UCF file, it reads NET "A"  LOC=J15 | IOSTANDARD=LVCMOS33;

 

Going back to the processes, I'm able to Synthesize and Translate, but fails when it gets to Map and I get the following error messages:

 

ERROR:MapLib:30 - LOC constraint L16 on B is invalid: No such site on the

   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.

ERROR:MapLib:30 - LOC constraint M13 on C is invalid: No such site on the

   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.

ERROR:MapLib:30 - LOC constraint H17 on F is invalid: No such site on the

   device. To bypass this error set the environment variable 'XIL_MAP_LOCWARN'.

 

I also tried changing the net-names back to the default values (e.g. "sw<0>, sw<1>, etc"), but it didn't help.

[Alex]

Hi you can right click the top module and choose add source. Then you can select the download ucf file. In the ucf file, you only need to uncomment the io you want to use. By doing so, you don't need to map out anything. It is all taken care of. As this is a simple design, I don't know if you need to add any ibuf or obuf. Using the provided ucf should be enough.

[jcchong]

Hi Alex,

 

Thanks for pointing it out. What directory should I put the master UCF file in? I looked in the directory where all of my project files are stored and saw a UCF file (named after my schematic file). Should I replace that file with the Master file and rename it? 

 

Previously when I designed with the Basys (1st gen) board, I would map I/O pins using ibuf and obuf. If I wanted to map the input to Pin 15 on the board, I would say LOC = P15. In this case, is using ibuf and obuf the right way to map IO pins (e.g. LOC = J15 --> Pin J15)? If I wanted to map an input to Pin J15, would I say LOC = PJ15 or LOC = J15? What's the correct way of doing this?

[Alex]

Hi, have you defined the IO standard? It is like you don't have correct io standard in the ucf. Actually Digilent has provided the master ucf for all IO pins. You can use that instead of creating your own one. It can be found at the Nexys 4 DDR wiki page.