Jump to content
  • 0

Cmod A7 Vivado 2021.1 Place 30-574 error


BYTEMAN

Question

Dear Sir,

I've installed the latest Vivado 2021.1 suite and try to compile an old blinky design in VHDL, here below the source code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx leaf cells in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity blinky is
--  Port ( );
port (
        sysclk : in std_logic;
        led : buffer std_logic_vector (1 downto 0)
    );
end blinky;

architecture Behavioral of blinky is
    constant max_count : natural := 48000000;
    signal Rst : std_logic;
begin
Rst <= '0';
 
    -- 0 to max_count counter
    ctr_led : process(sysclk, Rst)
        variable count : natural range 0 to max_count;
    begin
        if Rst = '1' then
            count := 0;
            led(0) <= '1';
        elsif rising_edge(sysclk) then
            if count < max_count/2 then
                count := count + 1;
                led(0) <= '1';
            elsif count < max_count then
                led(0) <= '0';
                count := count + 1;
            else
                led(0) <= '1';
                count := 0;
            end if;
        end if;
    end process ctr_led; 

end Behavioral;

on the Digilent Cmod-A7-Master.xdc file I've uncommented following lines (clock and led):

## This file is a general .xdc for the CmodA7 rev. B
## To use it in a project:
## - uncomment the lines corresponding to used pins
## - rename the used ports (in each line, after get_ports) according to the top level signal names in the project

## 12 MHz Clock Signal
set_property -dict { PACKAGE_PIN L17   IOSTANDARD LVCMOS33 } [get_ports { sysclk }]; #IO_L12P_T1_MRCC_14 Sch=gclk
create_clock -add -name sys_clk_pin -period 83.33 -waveform {0 41.66} [get_ports {sysclk}];

## LEDs
set_property -dict { PACKAGE_PIN A17   IOSTANDARD LVCMOS33 } [get_ports { led[0] }]; #IO_L12N_T1_MRCC_16 Sch=led[1]
set_property -dict { PACKAGE_PIN C16   IOSTANDARD LVCMOS33 } [get_ports { led[1] }]; #IO_L13P_T2_MRCC_16 Sch=led[2]

## RGB LED
#set_property -dict { PACKAGE_PIN B17   IOSTANDARD LVCMOS33 } [get_ports { led0_b }]; #IO_L14N_T2_SRCC_16 Sch=led0_b
#set_property -dict { PACKAGE_PIN B16   IOSTANDARD LVCMOS33 } [get_ports { led0_g }]; #IO_L13N_T2_MRCC_16 Sch=led0_g
#set_property -dict { PACKAGE_PIN C17   IOSTANDARD LVCMOS33 } [get_ports { led0_r }]; #IO_L14P_T2_SRCC_16 Sch=led0_r

Synthesis give no errors but Implementation show 3 errors:

[Place 30-574] Poor placement for routing between an IO pin and BUFG. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
	< set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets sysclk_IBUF] >

	sysclk_IBUF_inst (IBUF.O) is locked to IOB_X0Y102
	 and sysclk_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y18
[Place 30-99] Placer failed with error: 'IO Clock Placer failed'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.
[Common 17-69] Command failed: Placer could not place all instances

Looking through the forum I've found this solution:

set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets clk_IBUF]

but why this was not shown with older Vivado release? There are some way to avoid such constraints and select anothr pin on the Cmod A7 board or is an hardware trouble and then the only workaround is to update the constraints file with the above directive?

Thanks and best regards.

Edited by BYTEMAN
Link to comment
Share on other sites

7 answers to this question

Recommended Posts

  • 0

Not much you can do other than edit the constraints file as Vivado is basically saying the pin you’ve selected that the LED is connected to is in a bad place for routing of the clock and could be optimised by using a more suitably placed pin on the FPGA. Unfortunately as it’s a dev board the LEDs and what not are connected to the pins chosen by digilent and you can’t change that, just add the line of text to your constraints file or chose a different LED that may be connected to somewhere Vivado prefers.

 

Also, the solution was given to you by Vivado, there was no need to search the forum to find it ?

Edited by Mario875
Link to comment
Share on other sites

  • 0

The assertion that a newer version of Vivado has a different idea of which pins for a particular device are appropriate for clock inputs than earlier ones is a makes for a valid question.

@BYTEMANare you sure that you have selected the correct device, including package, in the Vivado device settings for both versions of the tools correctly when generating a bitstream from the sources?

I haven't tied to replicate your observation but suspect that something other than a tool bug is going on.

[edit] While sometimes vendors lay out PCBs with inappropriate routing of external clock inputs, this is not the case with the CMOD-A7.  As you can see in the master constraints file: "#IO_L12P_T1_MRCC_14 Sch=gclk" gclk is on an MRCC pin which is perfectly valid. Always refer to the schematic for location constraints.

I just looked at a project from last year for the CMOD-A735T built with Vivado 2019.1 and didn't run into this error message.

[edit2] When confronted with unexpected error messages from synthesis, implementation or bitgen you can often find clues to the root of the problem in the vast list of warnings. Start with the synthesis warnings first. Sometimes, constraints are ignored; sometimes due to changes in syntax incorporated in newer versions of the tools. Again, reading the warnings will help.

Edited by zygot
Link to comment
Share on other sites

  • 0

Hi all,

I've checked the Project Summary report, here attached the project part is the Cmod A7-35t (xc7a35tcpg236-1) and the Messages tab content.

Looking at the Messages sound strange the following one:

"[Board 49-67] The board_part definition was not found for digilentinc.com:cmod_a7-35t:part0:1.1. This can happen sometimes when you use custom board part. You can resolve this issue by setting 'board.repoPaths' parameter, pointing to the location of custom board files. Valid board_part values can be retrieved with the 'get_board_parts' Tcl command."

Looking at the path:

C:\Users\<myuser>\AppData\Roaming\Xilinx\Vivado\2021.1\xhub\board_store\xilinx_board_store\XilinxBoardStore\Vivado\2021.1\boards\Digilent\cmod_a7-35t\B.0\1.1

I can see the boards file that I think was downloaded and installed by Vivado.

After that on the forum I've see another procedure detailed at this link:

https://www.xilinx.com/support/answers/72033.html

looking at the GitHub repo I can see that the boards version is the same but I noticed a difference, into the GitHub the path at the board file is:

XilinxBoardStore/boards/Digilent/cmod_a7-35t/B.0/

inside the B.0 folder there are the board files, but into the PC folder I've instead a 1.1 folder and then inside this one the board files.

Is correct? Sound strange the difference between the repository file and the one that was download and installed through the Vivado suite...

LANGUAGE DEFINITION

There is another point about the language definition. Why even I've set the language as VHDL, into the Project summary there is always listed Verilog instead?

Thanks and best regards.

Thanks

 

projectsummary.jpg

Messages.jpg

Edited by BYTEMAN
Link to comment
Share on other sites

  • 0

Hi all,

I've an update.

II've recognized one error into the added constraint condition about the clock.

This is the correct command to use:

set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets sysclk];

In my previous test the error Common 17-55 was due to the incorrected row:

set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets sysclk_IBUF];

hence I've written sysclk_IBUF instead simply sysclk.

After this correction all the synthesis and Implementation run nicely without any error or warning (image attached).

Anyway trhe question is why into the previous VIVADO release this message was not show and then I've no need to add this constraint specification.

Thanks and best regards.

 

projectsummary-corrected.jpg

Link to comment
Share on other sites

  • 0

Newer versions of FPGA tools usually come with support for the newest devices and package in production. Sometimes, they add valuable features such as support for newer HDL standard features. Always, they come with a raft of new bugs.

It's been my experience that the 202x.x Vivado tools have some pretty dumb and annoying bugs. One weird one seems to be providing error or warning messages that suggest a workaround that, if followed explicitly, results in either a new error complaining about the syntax just offered. I've gotten messages from the tools referring to "<signal_name>_IBUF" instead of <signal_name> from the recent Vivado tools that I never saw in earlier versions. I've also had the newer tools offer syntax for constraints that are then rejected by the same tool.

There are a number of strategies to deal with tool bugs.

  1. Don't use the latest version of the tools unless you have to:
    • you are using a part that isn't supported by previous versions
    • you need to use an HDL feature that isn't supported by previous versions
    • you need a supporting feature in a particular tool version. Node-locked device licenses are generally honored in tool versions prior to the one that you got the license for
    • Every tool release mentions a host OS version that is supposed to support it. In general older FPGA tools can be installed on newer OS releases, though sometimes this takes some extra effort. Tool version-host OS version pairings can get messy, especially for Linux hosts.
  2. Always check the post-route pin location assignments against the schematic and current master constraints file manually.

In general, as far as tool version go, it's better to stick with the 'devil that you know' rather than the 'devil that you don't know'. Sometimes, the newer tool versions are just too much bother to deal with so I frequently use one that I've gotten used to.

As to the CLOCK_DEDICATED_ROUTE FALSE constraint; you shouldn't be needing it in reference to the external global clock input pin for your FPGA board as this is a valid clock capable pin. Of course if the HDL name doesn't match exactly the constraint name then that's a problem.  If you are using an MMCM or PLL between the clock input pin and your logic, it's not uncommon to get a warning about competing timing constraints. This is because the tool IP often creates its own timing constraints.

When confronted with unexpected or weird build results you either have to track down the exact cause of the problem or just use a tool version that doesn't give you more headaches than you are prepared to deal with.

 

Edited by zygot
Link to comment
Share on other sites

  • 0

Hi @BYTEMAN,

I'm not certain why you got these errors. I created a new RTL project in Vivado 2021.1, selecting the Cmod A7 35 (using the same set of board files that I used in Vivado 2020.1), selected VHDL as the target language when the GUI pop up asked me to add sources and the .xdc file (I copied pasted the materials you posted initially in this thread) and was able to generate a bitstream with no errors.

image.png

I'm not sure which particular board files Xilinx pulls from their Github (or how they source it), but the ones I used are from Digilent's Github here: https://github.com/Digilent/vivado-boards/tree/master/new/board_files; I had to manually create a board_files folder in the Vivado installation path for Vivado 2021.1, but it's otherwise worked fine for me. The one warning from implementation is Vivado telling me that we didn't specify the configuration bank voltage select or configuration voltage, which would be added by adding these lines to the .xdc file (I confirmed this removed the single warning):

set_property CFGBVS VCCO [current_design]
set_property CONFIG_VOLTAGE 3.3 [current_design]

Unfortunately, this means aside from manually adding Digilent's board files, I don't have a lot of other suggestions for you to try as your design as is ran without issues on my machine.

Let me know how it goes.

Thanks,
JColvin

Link to comment
Share on other sites

  • 0
On 8/3/2021 at 12:41 AM, JColvin said:

I had to manually create a board_files folder in the Vivado installation path for Vivado 2021.1

Dear JColvin,

sorry for long time, I'm back on this question.

I've did some checking, actually Into the Project settings at the Tool Settings -> Vivado Sore -> Board Repositiry there is a window where to insert the list of the board repository paths, my environment point to this one and the execution of the command get_boards_parts give the following answer:

immagine.png.f6443a386b6c80045426acf325cd5132.png

so I think that the board is properly identified, but I can not understand why I got 2 critical warning at the Implementation stage:

immagine.png.7b7d71990319343abfc4e7239f2c580e.png

immagine.png.b0b9167deb3516bdd639ba5642c91c80.png

if the boards is properly identified why I got these warning?

Thanks for your help.

Best Regards.

EDIT

May be I've solved, I've just checked at the repository path, I think there is somethings wrong where the board files definition was put (in bold what to me seems an extra path):

C:\Users\STE\AppData\Roaming\Xilinx\Vivado\2021.1\xhub\board_store\xilinx_board_store\XilinxBoardStore\Vivado\2021.1\boards\Digilent\cmod_a7-35t

then I've do a copy of only the cmod_a7-35t folder to the path listed into the project settings:

C:\Users\STE\AppData\Roaming\Xilinx\Vivado\2021.1\xhub\board_store\xilinx_board_store

after running again the implement process this one was able to end without any error or warning

immagine.png.553d94e41e79b5d069dc5ee56f243497.png

Actually my repository folder looks as reported below:

immagine.png.984e0f7ca04aef64998a28eb12e7f033.png

and now seems able to work properly.

May be only a issue originated when the Vivado save the boards file from the searching tool when a new design is created?

Just as a side question, is possible to change the board definition for a already created design?

Thanks!

immagine.png

Edited by BYTEMAN
UPDATE
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...