Jump to content
  • 0

Vivado Wrapper Error on Digilent USB104A7 Board


rmccormack1

Question

So I am trying to program a counter on the Digilent USB104A7 board. I want to first do it to the LEDs so I know that it is working and them move on to the ZMOD port. Here is my code that I have for the counter:

module counter(input sys_clock, reset, output[3:0] led
);
reg [3:0] counter_up;

always @(posedge sys_clock or posedge reset)
begin
if(reset)
counter_up <= 4'd0;
else
counter_up <= counter_up + 4'd1;
end
assign led = counter_up;
endmodule

 

Now I am having a problem with the wrapper. I am able to get through the synthesis and implication steps. I keep getting this error when I generate the bitstream with the wrapper:

[DRC NSTD-1] Unspecified I/O Standard: 3 out of 7 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks NSTD-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: diff_clock_rtl_clk_n, diff_clock_rtl_clk_p, and reset_rtl.

These errors are in the wrapper and not the code itself. I do not have these ports in my file so I dont know why I am getting this error I will need to export this file later to vitis. Any help would be appreciated. 

block design.png

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

  • 0

I've not used the USB104A7 nor do I use soft processors.  I do use wrappers when targeting a ZYNQ device and using the board design flow to develop a basic ZYNQ system.

After verifying and generating the board design I have Vivado create a wrapper file in VHDL or Verilog for the system. I make sure to uncheck the default setting when doing this and tell Vivado that I, not Vivado, will be managing the wrapper HDL.

My top level entity instantiates the system wrapper as a module/component along with all of the other modules/components in the design. For ZYNQ designs the toplevel entity is ignorant of PS signals like external memory DDR. For MicroBlaze, I assume that, all external signals and pins have to be handled in the toplevel entity. Either way we need to provide location constraints at a minimum for programmable logic external signals.

You may not think that diff_clock_rtl_clk_n, diff_clock_rtl_clk_p, and reset_rtl exist as external pins in your design but Vivado synthesis certainly does. So, you have to figure out why this is the case.

Do these signals appear on the HDL wrapper for your system design?

Since you are wanting to write your own Verilog code you should consider abandoning the MicroBlaze and board design altogether. Take control of your project. If you just have to burden you design with a soft processor you don't need to start there. Just create you own toplevel module and add IO features as you progress. When using wrappers to instantiate board design flow systems you become responsible for managing constraints.

Hint: Almost every design that I do has a free-running 32-bit counter connected to each clock with one bit connected to an LED as a heartbeat indicator. It's an easy way to see that the design is running.

Connecting a small counter that is clocked by sys_clock and has its output connected directly to LEDs isn't going to be terribly informative. For a 100 MHz sys_clk bit 26 is a better signal to drive an LED indicator.

Edited by zygot
Link to comment
Share on other sites

  • 0
15 hours ago, zygot said:

I've not used the USB104A7 nor do I use soft processors.  I do use wrappers when targeting a ZYNQ device and using the board design flow to develop a basic ZYNQ system.

After verifying and generating the board design I have Vivado create a wrapper file in VHDL or Verilog for the system. I make sure to uncheck the default setting when doing this and tell Vivado that I, not Vivado, will be managing the wrapper HDL.

My top level entity instantiates the system wrapper as a module/component along with all of the other modules/components in the design. For ZYNQ designs the toplevel entity is ignorant of PS signals like external memory DDR. For MicroBlaze, I assume that, all external signals and pins have to be handled in the toplevel entity. Either way we need to provide location constraints at a minimum for programmable logic external signals.

You may not think that diff_clock_rtl_clk_n, diff_clock_rtl_clk_p, and reset_rtl exist as external pins in your design but Vivado synthesis certainly does. So, you have to figure out why this is the case.

Do these signals appear on the HDL wrapper for your system design?

Since you are wanting to write your own Verilog code you should consider abandoning the MicroBlaze and board design altogether. Take control of your project. If you just have to burden you design with a soft processor you don't need to start there. Just create you own toplevel module and add IO features as you progress. When using wrappers to instantiate board design flow systems you become responsible for managing constraints.

Hint: Almost every design that I do has a free-running 32-bit counter connected to each clock with one bit connected to an LED as a heartbeat indicator. It's an easy way to see that the design is running.

Connecting a small counter that is clocked by sys_clock and has its output connected directly to LEDs isn't going to be terribly informative. For a 100 MHz sys_clk bit 26 is a better signal to drive an LED indicator.

I will try this and will see if it works. Those signals you are talking about appear on the HDL wrapper. I also have to export this file to vitis so I cannot leave the design file empty.

 

Edited by rmccormack1
Link to comment
Share on other sites

  • 0
33 minutes ago, rmccormack1 said:

Those signals you are talking about appear on the HDL wrapper. I also have to export this file to vitis so I cannot leave the design file empty.

Better yet, to get started, ditch the MicroBlaze and board design system altogether. Everything will be simpler. No mysterious signals added to your intended design. No hardware to export to the software development tools. No software co-design co-debugging.

A good rule in engineering is to avoid doing things that make your work complicated and difficult. If you find yourself working for the tools, you're living in an unhappy universe. Make the tools work for you. The tools can't create designs, so don't allow them to dictate to you how you can do the design work.

Link to comment
Share on other sites

  • 0
1 hour ago, rmccormack1 said:

How do I export it vitis then? Don't I need a board design?

Why do you think that a soft processor ( or Vitis for that matter ) is necessary for your project?

If you don't use MicroBlaze you don't need to use either the board design flow or any software development tools like Vitis.

Your board is perfectly suited to an all HDL design flow. Just create a new project in Vivado and add all of your HDL source code, plus your constraints file(s). You can still use Vivado IP for clocking, internal storage etc. if that's convenient.  FPGAs just aren't well suited for implementing replacements for general purpose computers systems. ( an exception might be for projects that are for experimentation of CPU architecture design concepts...)

My hunch is that a major reason why MicroBlaze shows up in projects for boards like yours is that users are afraid to tackle the job of implementing a free-standing DDR interface. That's just the way that FPGA vendors like it; but that's not in the best interests of their customers. The USB104-A7 has DDR, a SYZYGY port, and a DPTI supported USB interface. You don't need a soft processor to use any of those resources  

I haven't taken the time ot figure out how Digilent supports the SYZYGY DNA for your board but if they sell the board they have to provide IP to use it.

 

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