Problems with Basys 3

[Ricardo Hernandez]

I'm trying to program a Basys 3 board in Vivado. Synthesis ok, Implementation ok, bitstream failed. I don't what I'm doing wrong. By the way, I'm new in Vivado, Ive been working with Nexys2, 3 and 4 in Xilinx ISE.

[zygot]

Can you share your bitgen error messages with us?

[Ricardo Hernandez]

The problem is that there are not error messages, just 

[zygot]

Yeah, somewhere there's a log file with an error message. Find the bitgen (don't remember if this has the same name in Vivado) log file.

[jpeyron]

Hi @Ricardo Hernandez,

Welcome to the Digilent forums!

Is there any error messages in the messages tab on the bottom of Vivado?

Here is the Basys 3 resource center.  Are you able to generate a bitstream doing the Basys 3 Programming Guide tutorial?

Does your computer name have extended asci letters in it? If so vivado will have issues as I discovered in this forum thread here.

best regards,

Jon 

[Ricardo Hernandez]

Hi 

I found the error message:

I´ve tried to follow the Basys 3 Programming Guide tutorial, but with my own project in VHDL, creating the source file, constraints file.

 
 

[zygot]

@Ricardo Hernandez

So you can see which ports are causing problems. Since I doubt that any signal names in the default constraints file for your board are named a,b, aob...etc I'd guess that your toplevel port has signal names that don't appear in your constraints file. There are other possibilities:

• toplevel port names must match exactly the signal names in the constraints file.
• if signals assigned to pins on an IO bank are specified with incompatible IOSTANDARD specifications as other signals for the same bank this will cause a bitgen error.
• if the tools don't find a valid pin location assignment it will assign signals to somewhere you don't want them. Always check the pin report to make sure that your signals are actually going to the pins where you want them before configuring a powered board.

Bitgen messages usually aren't too helpful so you need to read the place and route log file to look for any warnings related to the signal names that bitgen complains about. Expand all relevant messages and you might bet lucky enough to spot the exact cause of the problem.

Xilinx has some good literature to help you with writing constraints. Personally, I want to edit constraints files for myself but ISE and Vivado often takes issue with this so I usually edit constraints files without the tools running.

Both ISE and Vivado allow you to see and modify the pin constraints in the GUI ( if you can find the right view in %$&^ contextual GUI ) and update your constraints file appropriately. If I don't know the syntax for setting a constraint I might use this approach but then I write it down so that I can just edit the constraints file myself later.

There are 2 schools of thought on naming toplevel port signals. One is to uncomment the assignments it the vendor's default constraint file and use that name in your HDL. The other is to use a name that make sense to you in the HDL and change the names in a copy of the default constraints file ( with a different file name of course ), Depending on the signals, the design, and the names in the constraints file I've done both. Whichever way I do it I make sure to leave commentary in the code making it clear what pins go to what signals.

[Ricardo Hernandez]

Hi Zigot

Toplevel port names (in the source file) match exactly the signal names in the constraints file.

entity Compuertas is
    Port ( a, b : in STD_LOGIC;
           aob, ayb, axb, anob, anyb, anxb, noa : out STD_LOGIC
    );            
end Compuertas;

This project works well in Nexys 3 and Nexys4 with ISE. Both ucf files have differences in syntax. All I did was implement it in Vivado with Basys 3 using the ports shown in page 15 of the Basys 3™ FPGA Board Reference Manual. So, I think, these ports are well planned on the board to be compatible with constraints requirements. 

Writing constraint, in Implementation step, are similar (I think) to Plan Ahead. So what's going on with Vivado

I don't know if there is a special syntax in Vivado constraints file. I'll search Xilinx literature for writing constraints as you suggest.

Thanks

Regards

[zygot]

2 hours ago, Ricardo Hernandez said:

I don't know if there is a special syntax in Vivado constraints file. I'll search Xilinx literature for writing constraints as you suggest.

Somewhere in a log file Vivado is telling you that it didn't like your location constraints (usually syntax) and has ignored them. ISE and Vivado are like puppies. You say go do this. They run around, tongue wagging wildly, and come back telling you that they did as commanded. Only they didn't actually do anything that you wanted because they didn't understand the command.. or didn't know how to do what you asked given the parameters set forth. At least the tools spit out hundreds of log messages hinting at what might have done wrong. Good thing too because the tools aren't nearly as cute and lovable as a puppy.... anyway you have to skim through all synthesis, place and route, and bitgen warnings and messages looking for possible discrepancies between what you asked for and what you got in return. Getting a notification that a configuration file was successfully created is not the same thing as getting the configuration file that you want. There are so many warnings and messages that can be ignored that all of us tend to get lazy and bypass the reading step. It's a habit that can cause problems. You can, at some risk to your mental health, change the message and warning level settings though I suggest that you don't.

ISE ucf syntax is different than VIvado xdc syntax.

[jpeyron]

Hi @Ricardo Hernandez,

Here is an instructable that discusses how to convert an ucf file to an xdc file.

best regards,

Jon

[zygot]

I just posted a reply that was interrupted by the last one from Jon and mine somehow disappeared.... Don't really feel like rewriting it... but Jon's link might help. My comment had puppies which makes it better than Jon's

 

[Ricardo Hernandez]

The problem has been fixed. The xdc file has the following data:

set_property PACKAGE_PIN V17 [get_ports a]
set_property PACKAGE_PIN V16 [get_ports b]
set_property PACKAGE_PIN U16 [get_ports anob]
set_property PACKAGE_PIN U19 [get_ports anxb]
set_property PACKAGE_PIN V19 [get_ports anyb]
set_property PACKAGE_PIN W18 [get_ports aob]
set_property PACKAGE_PIN U15 [get_ports axb]
set_property PACKAGE_PIN U14 [get_ports ayb]
set_property PACKAGE_PIN V14 [get_ports noa]

It doesn't work. I modified it as follows:

set_property PACKAGE_PIN V17 [get_ports a]
set_property PACKAGE_PIN V16 [get_ports b]
set_property PACKAGE_PIN U16 [get_ports anob]
set_property PACKAGE_PIN U19 [get_ports anxb]
set_property PACKAGE_PIN V19 [get_ports anyb]
set_property PACKAGE_PIN W18 [get_ports aob]
set_property PACKAGE_PIN U15 [get_ports axb]
set_property PACKAGE_PIN U14 [get_ports ayb]
set_property PACKAGE_PIN V14 [get_ports noa]

set_property IOSTANDARD LVCMOS18 [all_inputs]
set_property IOSTANDARD LVCMOS18 [all_outputs]

And now it works

 

 

[zygot]

@Ricardo Hernandez

Thanks for reporting back.

There is a way to globally set the IOSTANDARD for a bank.

Now why did you decide on LVCMOS18 as the IOSTANDARD for your IO? Your inputs are coming from SW0 and SW1 which are on IO bank 14 according to the schematic. The switches are either at 3.3V or 0V depending on how they are positioned. Does this sound right to you?

The choice of IOSTANDARD depends on the actual voltage powering the IO Bank that your pins are connected to. For your board this is 3.3V according to the schematic. Before powering on an FPGA board and loading a configuration file that uses physical pins it's a good idea to make sure that your IOSTANDARD specifications are appropriate. This requires reading the schematic and being familiar with information in UG471 for Series 7 devices. The master ucf or xdc constraints file for your board should have appropriate IOSTANDARD setting already set properly.

I realize that checking all of this might seem like a lot of extra work but it is essential work if you are going to try out a design on real hardware.

[Ricardo Hernandez]

Zigot

Yes, you're right, by setting LVCMOS to 33 the problem has been fixed and the bit file was written successfully.

Thanks