Microblaze Constraint File and Timing Fails

[Robert R]

Dear Support,

I am trying to implement a Microblaze in the Arty S7 with 50T FPGA board revision E. (yes Rev E not B).  I instantiate GPIOs, Switches, LEDs, pushbuttons, UART and SPI at J7.  I want to write c code to control the LEDs and talk to an SPI device.

Attached is my implementation in picture format.  The design verifies, synthesizes, and implements, but I get timing is negative.

ISSUES

1. I am not sure how the GPIOs route from the block diagram to constraint file. I downloaded the constraint file, and uncomment the clock, and GPIO switches, etc...However, in the block diagram net names do not match the constraint file.  I don't know how to map them   In the case of the clock, I matched the Net CLK_12MHz in the block diagram to the constraint file, but for the GPIO, and others I am not sure I am doing this correctly. 

2. Timing fails no matter if I change the CLOCK_OUT from 100MHz, 96MHz, 80MHz.  Timing fails.

 

HOW TO IMPLEMENT THE CONSTRAINT FILE TO BLOCK DIAGRAM...They should match no?

 

Please advise how to fix timing, and how to map constraint file.  I am sure I am not doing this right.  I have watched numerous videos on implementation, and every implementation passes but they don't show how they setup other stuff. 

 

## Clock Signals
set_property -dict { PACKAGE_PIN F14   IOSTANDARD LVCMOS33 } [get_ports CLK_12MHz]; #IO_L13P_T2_MRCC_15 Sch=uclk
create_clock -add -name sys_clk_pin -period 83.333 -waveform {0 41.667} [get_ports CLK_12MHz];

## Switches
set_property -dict { PACKAGE_PIN H14   IOSTANDARD LVCMOS33 } [get_ports { sw[0] }]; #IO_L20N_T3_A19_15 Sch=sw[0]
set_property -dict { PACKAGE_PIN H18   IOSTANDARD LVCMOS33 } [get_ports { sw[1] }]; #IO_L21P_T3_DQS_15 Sch=sw[1]
set_property -dict { PACKAGE_PIN G18   IOSTANDARD LVCMOS33 } [get_ports { sw[2] }]; #IO_L21N_T3_DQS_A18_15 Sch=sw[2]
set_property -dict { PACKAGE_PIN M5    IOSTANDARD SSTL135 } [get_ports { sw[3] }]; #IO_L6N_T0_VREF_34 Sch=sw[3]

## LEDs
set_property -dict { PACKAGE_PIN E18   IOSTANDARD LVCMOS33 } [get_ports { led[0] }]; #IO_L16N_T2_A27_15 Sch=led[2]
set_property -dict { PACKAGE_PIN F13   IOSTANDARD LVCMOS33 } [get_ports { led[1] }]; #IO_L17P_T2_A26_15 Sch=led[3]
set_property -dict { PACKAGE_PIN E13   IOSTANDARD LVCMOS33 } [get_ports { led[2] }]; #IO_L17N_T2_A25_15 Sch=led[4]
set_property -dict { PACKAGE_PIN H15   IOSTANDARD LVCMOS33 } [get_ports { led[3] }]; #IO_L18P_T2_A24_15 Sch=led[5]

## Buttons
set_property -dict { PACKAGE_PIN G15   IOSTANDARD LVCMOS33 } [get_ports { btn[0] }]; #IO_L18N_T2_A23_15 Sch=btn[0]
set_property -dict { PACKAGE_PIN K16   IOSTANDARD LVCMOS33 } [get_ports { btn[1] }]; #IO_L19P_T3_A22_15 Sch=btn[1]
set_property -dict { PACKAGE_PIN J16   IOSTANDARD LVCMOS33 } [get_ports { btn[2] }]; #IO_L19N_T3_A21_VREF_15 Sch=btn[2]
set_property -dict { PACKAGE_PIN H13   IOSTANDARD LVCMOS33 } [get_ports { btn[3] }]; #IO_L20P_T3_A20_15 Sch=btn[3]

## USB-UART Interface
set_property -dict { PACKAGE_PIN R12   IOSTANDARD LVCMOS33 } [get_ports { uart_rxd_out }]; #IO_25_14 Sch=uart_rxd_out
set_property -dict { PACKAGE_PIN V12   IOSTANDARD LVCMOS33 } [get_ports { uart_txd_in }]; #IO_L24N_T3_A00_D16_14 Sch=uart_txd_in

## ChipKit SPI Header
## NOTE: The ChipKit SPI header ports can also be used as digital I/O and share FPGA pins with ck_io10-13. Do not use both at the same time.
set_property -dict { PACKAGE_PIN H16   IOSTANDARD LVCMOS33 } [get_ports { ck_io10_ss   }]; #IO_L22P_T3_A17_15   Sch=ck_io10_ss
set_property -dict { PACKAGE_PIN H17   IOSTANDARD LVCMOS33 } [get_ports { ck_io11_mosi }]; #IO_L22N_T3_A16_15   Sch=ck_io11_mosi
set_property -dict { PACKAGE_PIN K14   IOSTANDARD LVCMOS33 } [get_ports { ck_io12_miso }]; #IO_L23P_T3_FOE_B_15 Sch=ck_io12_miso
set_property -dict { PACKAGE_PIN G16   IOSTANDARD LVCMOS33 } [get_ports { ck_io13_sck  }]; #IO_L14P_T2_SRCC_15  Sch=ck_io13_sck

# Misc. ChipKit Ports
#set_property -dict { PACKAGE_PIN K13   IOSTANDARD LVCMOS33 } [get_ports { ck_ioa }]; #IO_25_15 Sch=ck_ioa
set_property -dict { PACKAGE_PIN C18   IOSTANDARD LVCMOS33 } [get_ports RESET_N]; #IO_L11N_T1_SRCC_15

## Configuration options, can be used for all designs
set_property BITSTREAM.CONFIG.CONFIGRATE 50 [current_design]
set_property CONFIG_VOLTAGE 3.3 [current_design]
set_property CFGBVS VCCO [current_design]
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 4 [current_design]
set_property CONFIG_MODE SPIx4 [current_design]

# SW3 is assigned to a pin M5 in the 1.35v bank. This pin can also be used as
## the VREF for BANK 34. To ensure that SW3 does not define the reference voltage
## and to be able to use this pin as an ordinary I/O the following property must
## be set to enable an internal VREF for BANK 34. Since a 1.35v supply is being
## used the internal reference is set to half that value (i.e. 0.675v). Note that
## this property must be set even if SW3 is not used in the design.
set_property INTERNAL_VREF 0.675 [get_iobanks 34]

 

 

Arty-S7-50-Rev-E-Master.xdc

[Robert R]

I was looking at the VHDL wrapper, and I picked the names of the wrapper inputs and outputs and changed the constraint file with those names...

could someone confirm this is the proper way to map the block diagram connections to the constraint file?  It seems logical, but I can be wrong as usual.

 

 

entity MB_MCU_TopLevel_wrapper is
  port (
    CLK_12MHz : in STD_LOGIC;
    RESET_N : in STD_LOGIC;
    dip_switches_4bits_tri_i : in STD_LOGIC_VECTOR ( 3 downto 0 );
    led_4bits_tri_o : out STD_LOGIC_VECTOR ( 3 downto 0 );
    push_buttons_4bits_tri_i : in STD_LOGIC_VECTOR ( 3 downto 0 );
    spi_io0_io : inout STD_LOGIC;
    spi_io1_io : inout STD_LOGIC;
    spi_sck_io : inout STD_LOGIC;
    spi_ss_io : inout STD_LOGIC;
    usb_uart_rxd : in STD_LOGIC;
    usb_uart_txd : out STD_LOGIC
  );
end MB_MCU_TopLevel_wrapper;

[JColvin]

Hi @Robert R,

When you create a block diagram based off of the Digilent board files, Vivado will automatically generate the appropriate details it needs for constraints when Vivado is going through the synthesis process. You do not need to add in a constraints file yourself to define any of the clocks or IO pins that you are using in a block design. Adding in your own .xdc can easily create conflicts if any of the names end up different. However, if there were any pins you wanted constrained that you did not address or use in your block design, you would want those pins individually constrained within a .xdc.

I'm waiting for my own Arty S7-50T to arrive to verify things for myself, but could you provide a screenshot or text of the timing errors you are receiving?

Thanks,
JColvin

 

[Robert R]

On 11/4/2019 at 3:03 PM, JColvin said:

Hi @Robert R,

When you create a block diagram based off of the Digilent board files, Vivado will automatically generate the appropriate details it needs for constraints when Vivado is going through the synthesis process. You do not need to add in a constraints file yourself to define any of the clocks or IO pins that you are using in a block design. Adding in your own .xdc can easily create conflicts if any of the names end up different. However, if there were any pins you wanted constrained that you did not address or use in your block design, you would want those pins individually constrained within a .xdc.

I'm waiting for my own Arty S7-50T to arrive to verify things for myself, but could you provide a screenshot or text of the timing errors you are receiving?

Thanks,
JColvin

 

Dear JColvin,

 

Timing report file is too big exceeding the 1.95MB limit set by the website.

 

 

[JColvin]

Hi @Robert R,

I haven't received my S7-50T as of yet, but you do not need to attach the entire timing report; a screenshot of the Problems or Timing tab (located by default in the bottom center of the Vivado GUI) will suffice for the moment. And to confirm, after creating the block design and the associated wrapper, does the project successfully generate a bitstream in addition to the verification, synthesis, and implementation that you mentioned?

Thanks,
JColvin

[zygot]

When doing a new design it's always a good idea to check the pin report to at least make sure that the toplevel signal assignments are correct. If the locations don't match the schematic or constraints file then something is wrong. Always run through the synthesis and implementation messages to look for any warnings about constraints being ignored. Often location constraint issues will result in BITGEN DRC errors that prevent bitstream generation; but not always. Be aware that the tools will assign default IOSTANDARD and other IO constraints unless you provide your own.

When you use vendor IP wizards in your design Vivado creates timing and sometimes location constraints that are not obvious in the heirarchal view so you have to go find them. Use problems like this to get familiar with Vivado. Open the implemented design and view all of the reports and informational views.

From what you've said timing seems to be what concerns you. After generating a bitstream the main summary report shows the maximum negative slack numbers. I guess that this is what you are looking at. Usually, if a simple design doesn't meet timing it's because the tools were never given basic external clock rates to work with. Understand that if your design has a wizard generated MMCM or PLL in it the constraints file for that IP will be in your design though it will be buried within the heirarchy. If you provde your own clock constraints that relate to the same inputs as the IP constraint you will get a warning in the synthesis and implementation reports. Open the implementation and looks around. Vivado reports all signals not constrained by a known clock rates. If also reports all known clocks. Often this information will point to a silly error.  

Vivado is complicated and finding the right view to get pertinent information is often contextual. I still sometimes fumble around trying to get to where I want to be every once in a while.. I'm not a fan of GUIs that limit access to a particular screen contextually. You just have to spend some time getting to know the tools' quirks and behavior.

FPGA development tools generate a lot of warnings. Even the IP wizard generated code generates warnings. For new projects it's worth the time to rund though these looking for obvious errors in your own code or just plain syntax mistakes or omissions that have confused the tools.

[Robert R]

18 hours ago, JColvin said:

Hi @Robert R,

I haven't received my S7-50T as of yet, but you do not need to attach the entire timing report; a screenshot of the Problems or Timing tab (located by default in the bottom center of the Vivado GUI) will suffice for the moment. And to confirm, after creating the block design and the associated wrapper, does the project successfully generate a bitstream in addition to the verification, synthesis, and implementation that you mentioned?

Thanks,
JColvin

Dear JColvin,

 

Attached is the window where timing failed.  In all microblaze videos I watched, this is not present.  So I am not sure what I am doing wrong, or what consequences this will have when the C code is executed on the hardware having negative time slacks.

Wished I understood the root cause.

[Robert R]

5 hours ago, zygot said:

When doing a new design it's always a good idea to check the pin report to at least make sure that the toplevel signal assignments are correct. If the locations don't match the schematic or constraints file then something is wrong. Always run through the synthesis and implementation messages to look for any warnings about constraints being ignored. Often location constraint issues will result in BITGEN DRC errors that prevent bitstream generation; but not always. Be aware that the tools will assign default IOSTANDARD and other IO constraints unless you provide your own.

When you use vendor IP wizards in your design Vivado creates timing and sometimes location constraints that are not obvious in the heirarchal view so you have to go find them. Use problems like this to get familiar with Vivado. Open the implemented design and view all of the reports and informational views.

From what you've said timing seems to be what concerns you. After generating a bitstream the main summary report shows the maximum negative slack numbers. I guess that this is what you are looking at. Usually, if a simple design doesn't meet timing it's because the tools were never given basic external clock rates to work with. Understand that if your design has a wizard generated MMCM or PLL in it the constraints file for that IP will be in your design though it will be buried within the heirarchy. If you provde your own clock constraints that relate to the same inputs as the IP constraint you will get a warning in the synthesis and implementation reports. Open the implementation and looks around. Vivado reports all signals not constrained by a known clock rates. If also reports all known clocks. Often this information will point to a silly error.  

Vivado is complicated and finding the right view to get pertinent information is often contextual. I still sometimes fumble around trying to get to where I want to be every once in a while.. I'm not a fan of GUIs that limit access to a particular screen contextually. You just have to spend some time getting to know the tools' quirks and behavior.

FPGA development tools generate a lot of warnings. Even the IP wizard generated code generates warnings. For new projects it's worth the time to rund though these looking for obvious errors in your own code or just plain syntax mistakes or omissions that have confused the tools.

 Dear Zygot,

 

thank you for the thorough explanation.  Vivado is indeed difficult to understand when you are a newbie.  I am trying to wrap my head around it.  All  I am trying to do is create a Soft core MCU and write SPI data to an external Peripheral.  In the ideal case, I would have a way to change the clock frequency to see if the peripheral responds.  MCUs can't do 40 MHz SPI clocks, so I am trying do it with an FPGA.

I am going to try a Microblaze Microcontroller version since all I need is an UART, GPIO and SPI engine.  I want to write SPI data  and using the UART I can command different clocks if possible at all.  I doubt it, but I will study it some more.

Once again, thank you very much for the useful tips.

Kindly

RR

[zygot]

1 hour ago, Robert R said:

since all I need is an UART, GPIO and SPI engine

Programmable logic devices are absolutely terrific for some things. For your project I wouldn't have a processor, soft or hard in the design. Of course I'm a bit more confident in my HDL skills. Still, if you have experience with an HDL you should consider an all HDL design. There are fewer to things to worry about. SPI is a nice interface to design for; just don't tell Vivado that the SCLK is a clock. With even low end Series 7 devices you should be able to implement a simple 40 MHz SPI master interface without timing issues. I'd start with the SPI master and verity timing using simulation. You can feed it with data from a BRAM to send out data formatted to support whatever it is that you want to connect to and capture it with an ILA. No software to worry about. Very little resource usage. Generally, devices with an SPI interface are pretty tolerant of less than great SCLK inputs.

My personal opinion is that implementing a soft-core processor in an FPGA is for an advanced developer. Yeah, I know that this goes against what most beginners hope is the case and what most FPGA vendors think will make using their devices easier and suitable for a broader audience. Really, a low percentage of FPGA designs need or should have s programmable core.

If you don't have the HDL chops there are controllers that do 40 Mbps SPI like  the Delfino and development kits are cheap. A TMS320F28379D launchpad would do everything you need. The only problem with that is the hardware is crazy complex to program with tons of unexpected limitations and modes to worry about. But Ti does offer pretty good tools for free. In fact that platform would be a good test platform for verifying an HDL Artix design implemented on hardware....

[edit] So after writing this I just noticed the report that you show above. I wouldn't worry too much about the TNS number as the WNS is positive. You have generate a detailed timing report to see how it came up with those numbers. Look for nets that are unconstrained. Your design might work fine as long as the IO pin locations and IOSTANDARD constraints are correct. So don't give up on what you've done too soon.

 

[Robert R]

1 hour ago, zygot said:

Programmable logic devices are absolutely terrific for some things. For your project I wouldn't have a processor, soft or hard in the design. Of course I'm a bit more confident in my HDL skills. Still, if you have experience with an HDL you should consider an all HDL design. There are fewer to things to worry about. SPI is a nice interface to design for; just don't tell Vivado that the SCLK is a clock. With even low end Series 7 devices you should be able to implement a simple 40 MHz SPI master interface without timing issues. I'd start with the SPI master and verity timing using simulation. You can feed it with data from a BRAM to send out data formatted to support whatever it is that you want to connect to and capture it with an ILA. No software to worry about. Very little resource usage. Generally, devices with an SPI interface are pretty tolerant of less than great SCLK inputs.

My personal opinion is that implementing a soft-core processor in an FPGA is for an advanced developer. Yeah, I know that this goes against what most beginners hope is the case and what most FPGA vendors think will make using their devices easier and suitable for a broader audience. Really, a low percentage of FPGA designs need or should have s programmable core.

If you don't have the HDL chops there are controllers that do 40 Mbps SPI like  the Delfino and development kits are cheap. A TMS320F28379D launchpad would do everything you need. The only problem with that is the hardware is crazy complex to program with tons of unexpected limitations and modes to worry about. But Ti does offer pretty good tools for free. In fact that platform would be a good test platform for verifying an HDL Artix design implemented on hardware....

[edit] So after writing this I just noticed the report that you show above. I wouldn't worry too much about the TNS number as the WNS is positive. You have generate a detailed timing report to see how it came up with those numbers. Look for nets that are unconstrained. Your design might work fine as long as the IO pin locations and IOSTANDARD constraints are correct. So don't give up on what you've done too soon.

 

Dear Zygot,

I hear you... Part of the effort here is trying to learn this soft core implementation.  It is a catch 22, you won't be good a FPGAs and soft cores if you don't do it, and you struggle doing because you don't do it enough... haha... So I have done simple HDL programs, but I don't consider myself a master on it.  I am sure I can figure out a master SPI VHDL program to achieve this.  or a VHDL UART... Just seemed easier dumping the blocks and be done... I am still going to keep trying it...

Again, many thanks for your valuable feedback and hardware platform suggestions.

Kindly,

RR

[Robert R]

On 11/8/2019 at 5:35 PM, JColvin said:

Hi @Robert R,

I haven't received my S7-50T as of yet, but you do not need to attach the entire timing report; a screenshot of the Problems or Timing tab (located by default in the bottom center of the Vivado GUI) will suffice for the moment. And to confirm, after creating the block design and the associated wrapper, does the project successfully generate a bitstream in addition to the verification, synthesis, and implementation that you mentioned?

Thanks,
JColvin

Ran the design again, and this time I didn't get errors.