Hi All, I am trying to port the lowrisc v0.5 design to a custom V2000T device System Details: Vivado 2015.4 lowrisc v0.5 release Ubuntu 16.04 LTS I have made the following changes to the clocks that are generated in the design, - 200 MHz to MIG, which generates a 100 MHz mig_ui_clk - MIG additional clock 0 - 25 MHz for the processor core (assigned to wire *clk*) - MIG additional clock 1 - 200 MHz for peripheral core psoc wire *clk_200MHz* - Modified the axi_clock_converter_0 clk_conv to 1:4 to match the 25 MHz processor input. - clk_wiz_0 clk_gen generates the following - clk_out_1 - 60 MHz for wire *clk_io_uart* - clk_out_2 - 50 MHz for wire *clk_rmii* - clk_out_3 - 50 MHz for wire *clk_rmii_quad* - I have removed the connection for pxl_clk, since I will not be using VGA or keyboard mouse. During place design, I get the following timing violation: Slack (VIOLATED) : -5.551ns (arrival time - required time) Source: eth_i/open/gmii_tx_inst/gmii_tx_en_reg_reg/C (rising edge-triggered cell FDRE clocked by clk_out2_clk_wiz_0 {rise(a)0.000ns fall(a)10.000ns period=20.000ns}) Destination: eth_i/open/tx_enable_dly_reg[2]/R (rising edge-triggered cell FDRE clocked by mmcm_clkout0 {rise(a)0.000ns fall(a)20.000ns period=40.000ns}) Path Group: mmcm_clkout0 Path Type: Hold (Min at Slow Process Corner) Clock Domain Crossing: Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path. Kindly let me know if I have gone wrong in any of the clock settings or If this path has to be given set_false_path constraint. I have not attached the entire timing report in this mail. Let me know if that is required. Thanks & Regards, Anup Kini.

Hi Jonathan, When I use mig_sys_clk as 200 MHz for the peripheral soc, I get the following error msg during opt_design: ERROR: [Opt 31-304] Invalid connectivity on net clk_p_IBUF between IBUF clk_p_IBUF_inst and IBUFDS dram_ctl/u_mig_7series_0_mig/u_ddr3_clk_ibuf/diff_input_clk.u_ibufg_sys_clk. This is a dedicated connection. Resolution: Please fix the design to remove other logic connected onto this net. As a work around the above error, I generated an additional clock from within MIG. I will try to figure out how to mitigate the phase error, Incase you know a command or quick way to figure out the phase difference, Kindly help me with it. Will it be easier if I generate the UART, rmii and rmii_quad also from MIG ? Thanks & Regards, Anup Kini. On Mon, Feb 5, 2018 at 1:54 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote: I don't know why you added a MIG additional clock 1, when 200MHz is already available as mig_sys_clk. I don't know if this is the cause of the problem, but since we don't know the innards of the MIG, it would seem prudent to avoid using this except for signals that directly drive the MIG. However the actual violation seems to be a hold violation between a 25MHz clock and a 50MHz clock, which suggests that there is unwanted phase lag between the MIG clocks and the clk_wiz_0. However since clk_rmii goes nowhere else you are free to adjust the phase in the clock generator of clk_rmii and clk_rmii_quad to remove the hold violation. You should then confirm if you can with simulation that the function is still correct. On 05/02/18 06:20, Anup Kini wrote: Hi All, I am trying to port the lowrisc v0.5 design to a custom V2000T device System Details: Vivado 2015.4 lowrisc v0.5 release Ubuntu 16.04 LTS I have made the following changes to the clocks that are generated in the design, - 200 MHz to MIG, which generates a 100 MHz mig_ui_clk - MIG additional clock 0 - 25 MHz for the processor core (assigned to wire *clk*) - MIG additional clock 1 - 200 MHz for peripheral core psoc wire *clk_200MHz* - Modified the axi_clock_converter_0 clk_conv to 1:4 to match the 25 MHz processor input. - clk_wiz_0 clk_gen generates the following - clk_out_1 - 60 MHz for wire *clk_io_uart* - clk_out_2 - 50 MHz for wire *clk_rmii* - clk_out_3 - 50 MHz for wire *clk_rmii_quad* - I have removed the connection for pxl_clk, since I will not be using VGA or keyboard mouse. During place design, I get the following timing violation: Slack (VIOLATED) :        -5.551ns  (arrival time - required time)    Source:                 eth_i/open/gmii_tx_inst/gmii_tx_en_reg_reg/C                              (rising edge-triggered cell FDRE clocked by clk_out2_clk_wiz_0  {rise(a)0.000ns fall(a)10.000ns period=20.000ns})    Destination: eth_i/open/tx_enable_dly_reg[2]/R                              (rising edge-triggered cell FDRE clocked by mmcm_clkout0  {rise(a)0.000ns fall(a)20.000ns period=40.000ns})    Path Group:             mmcm_clkout0    Path Type:              Hold (Min at Slow Process Corner) Clock Domain Crossing:  Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path. Kindly let me know if I have gone wrong in any of the clock settings or If this path has to be given set_false_path constraint. I have not attached the entire timing report in this mail. Let me know if that is required. Thanks & Regards, Anup Kini.

Hi Jonathan, I took up the suggestion you gave and used the MIG_ui_clock to drive the clk_wiz_0 and clk_wiz_1. This has resolved all the Ethernet related timing violations. Now, I get timing violations in the SD card interface. Slack (VIOLATED) :        -5.321ns  (arrival time - required time)   Source:  psoc/sdtop/cmd_serial_host0/response_o_reg[69]/C                             (rising edge-triggered cell FDCE clocked by clk_sdclk_clk_wiz_1  {rise(a)0.000ns fall(a)100.000ns period=200.000ns})   Destination: psoc/sd_cmd_response_reg_reg[69]/D                             (rising edge-triggered cell FDRE clocked by mmcm_clkout0  {rise(a)0.000ns fall(a)20.000ns period=40.000ns})   Path Group:             mmcm_clkout0   Path Type:              Hold (Min at Slow Process Corner)   Requirement:            0.000ns  (mmcm_clkout0 rise(a)0.000ns - clk_sdclk_clk_wiz_1 rise(a)0.000ns)   Data Path Delay:        5.242ns  (logic 0.248ns (4.731%)  route 4.994ns (95.269%)) Kindly have a look at this and let me know if you have faced similar issues violations. Let me know if you require the entire timing report. Thanks & Regards, Anup Kini. On Mon, Feb 5, 2018 at 2:46 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote: You need to connect your MIG source clock as recommended in the MIG example design that comes in your board documentation. So if it uses an IBUFDS normally that would connect to a top level clock input port. But perhaps that is one of the parameters that you are able to change in the configuration of the MIG IP. Regarding phases if you have a 5ns failure out of 20 that implies a 90 degrees phase change will fix it. But I can't say that this is the solution because it could cause other timing errors to pop up. Static timing always gives you the worst case, whether valid or not. But you can easily change the phase in the clock wizard dialog until you reach an acceptable value. But right now it looks like the MIG is introducing a big skew because of the IBUFDS. You should examine the clock reports post implementation to see if it looks sensible. I don't think adding more MIG clock outputs will help unless you can get rid of the big skew on the MIG clocking somehow. Other configurations are possible such as driving the MIG directly from a toplevel port, and operating the clk_wiz_0 from the MIG ui clock. On 05/02/18 09:01, Anup Kini wrote: > Hi Jonathan, > > When I use mig_sys_clk as 200 MHz for the peripheral soc, I get > the following error msg during opt_design: > > ERROR: [Opt 31-304] Invalid connectivity on net clk_p_IBUF > between IBUF clk_p_IBUF_inst and IBUFDS > dram_ctl/u_mig_7series_0_mig/u_ddr3_clk_ibuf/diff_input_clk.u_ibufg_sys_clk. > This is a dedicated connection. > Resolution: Please fix the design to remove other logic connected > onto this net. > > As a work around the above error, I generated an additional clock > from within MIG. > > I will try to figure out how to mitigate the phase error, Incase > you know a command or quick way to figure out the phase > difference, Kindly help me with it. > Will it be easier if I generate the UART, rmii and rmii_quad also > from MIG ? > > > > Thanks & Regards, > Anup Kini. > > On Mon, Feb 5, 2018 at 1:54 PM, Dr Jonathan Kimmitt > <jrrk2(a)cam.ac.uk <mailto:jrrk2@cam.ac.uk>> wrote: > > I don't know why you added a MIG additional clock 1, when > 200MHz is > > already available as mig_sys_clk. I don't know if this is the > cause of the > > problem, but since we don't know the innards of the MIG, it > would seem > > prudent to avoid using this except for signals that directly > drive the MIG. > > > However the actual violation seems to be a hold violation > between a 25MHz clock > > and a 50MHz clock, which suggests that there is unwanted > phase lag between > > the MIG clocks and the clk_wiz_0. However since clk_rmii goes > nowhere else > > you are free to adjust the phase in the clock generator of > clk_rmii and clk_rmii_quad > > to remove the hold violation. You should then confirm if you > can with simulation that the > > function is still correct. > > > On 05/02/18 06:20, Anup Kini wrote: > > Hi All, > > I am trying to port the lowrisc v0.5 design to a custom > V2000T device > > System Details: > Vivado 2015.4 > lowrisc v0.5 release > Ubuntu 16.04 LTS > > I have made the following changes to the clocks that are > generated in the > design, > > - 200 MHz to MIG, which generates a 100 MHz mig_ui_clk > - MIG additional clock 0 - 25 MHz for the processor core > (assigned to wire > *clk*) > - MIG additional clock 1 - 200 MHz for peripheral core > psoc wire > *clk_200MHz* > - Modified the axi_clock_converter_0 clk_conv to 1:4 to > match the 25 MHz > processor input. > > - clk_wiz_0 clk_gen generates the following > - clk_out_1 - 60 MHz for wire *clk_io_uart* > - clk_out_2 - 50 MHz for wire *clk_rmii* > - clk_out_3 - 50 MHz for wire *clk_rmii_quad* > - I have removed the connection for pxl_clk, since I will > not be using VGA > or keyboard mouse. > > During place design, I get the following timing violation: > > Slack (VIOLATED) :        -5.551ns (arrival time - > required time) >    Source:  eth_i/open/gmii_tx_inst/gmii_tx_en_reg_reg/C >                              (rising edge-triggered cell > FDRE clocked by > clk_out2_clk_wiz_0  {rise(a)0.000ns <mailto:rise@0.000ns> > fall(a)10.000ns <mailto:fall@10.000ns> period=20.000ns}) >    Destination: eth_i/open/tx_enable_dly_reg[2]/R >                              (rising edge-triggered cell > FDRE clocked by > mmcm_clkout0  {rise(a)0.000ns <mailto:rise@0.000ns> > fall(a)20.000ns <mailto:fall@20.000ns> period=40.000ns}) >    Path Group:             mmcm_clkout0 >    Path Type:              Hold (Min at Slow Process Corner) > Clock Domain Crossing:  Inter clock paths are considered > valid unless > explicitly excluded by timing constraints such as > set_clock_groups or > set_false_path. > > > Kindly let me know if I have gone wrong in any of the > clock settings or If > this path has to be given set_false_path constraint. > I have not attached the entire timing report in this > mail. Let me know if > that is required. > > > Thanks & Regards, > Anup Kini. > > > >

On 7 Feb 2018, at 06:20, Anup Kini <anupkini(a)gmail.com&gt; wrote: Hi Jonathan, Thank you for the help with the timing violations, I was able to build the bitstream. There are some more timing issues, I have ignored them for now. I was able to run the bare-metal hello program successfully. But, it runs into a infinte loop, instead of printing it once and stopping. Is this expected or something in the design is wrong ? Thanks & Regards, Anup Kini. > On Mon, Feb 5, 2018 at 6:36 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk&gt; wrote: > This is another hold violation and is an indication that delays in your clock generation are not balanced. > > You should ensure your topology has the same number of global clock buffers in all arms of the clock > > distribution network. Feedback loops in the clock buffers will ensure outputs have the same delay if inputs have. > > The key point is global buffers have low skew but big insertion delay. The implementation clock reports are your > > friend because they can tell you where your skew is coming from. > > If you cannot diagnose what is going on in this big design, I suggest you start with a smaller subset, without the DDR, > > and see if you can get the clocking to work in this case. The key parts of the peripherals of the design may be tested and debugged without the DDR. Once you have this subset debugged, hopefully you will have amassed sufficient experience with Vivado to complete the clocking design for the whole system. > > I'm afraid it is not realistic for me to diagnose the details of your design choices. I'm afraid there are few if any designs that are robust against the kind of changes that you are making without some debugging. > > Having said that, the SD-card clocking is intended to be robust against some non-synchronous clocking, so you could go ahead and see what happens in real operation without being too concerned about clock domain crossing issues in this area, because the SD-card never operates simultaneously with its control registers being read/written. > If this is another case of skew between input clocks, your could experiment with entering different amounts of phase offset in clk_wiz_1 configuration to get rid of it. In this particular case you should be able to put any phase offset in without affecting the function. > > >> On 05/02/18 12:22, Anup Kini wrote: >> Hi Jonathan, >> >> I took up the suggestion you gave and used the MIG_ui_clock to drive the clk_wiz_0 and clk_wiz_1. >> This has resolved all the Ethernet related timing violations. >> >> Now, I get timing violations in the SD card interface. >> Slack (VIOLATED) : -5.321ns (arrival time - required time) >> Source: psoc/sdtop/cmd_serial_host0/response_o_reg[69]/C >> (rising edge-triggered cell FDCE clocked by clk_sdclk_clk_wiz_1 {rise(a)0.000ns fall(a)100.000ns period=200.000ns}) >> Destination: psoc/sd_cmd_response_reg_reg[69]/D >> (rising edge-triggered cell FDRE clocked by mmcm_clkout0 {rise(a)0.000ns fall(a)20.000ns period=40.000ns}) >> Path Group: mmcm_clkout0 >> Path Type: Hold (Min at Slow Process Corner) >> Requirement: 0.000ns (mmcm_clkout0 rise(a)0.000ns - clk_sdclk_clk_wiz_1 rise(a)0.000ns) >> Data Path Delay: 5.242ns (logic 0.248ns (4.731%) route 4.994ns (95.269%)) >> >> Kindly have a look at this and let me know if you have faced similar issues violations. >> Let me know if you require the entire timing report. >> >> >> Thanks & Regards, >> Anup Kini. >> >>> On Mon, Feb 5, 2018 at 2:46 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk&gt; wrote: >>> You need to connect your MIG source clock as recommended in the MIG example design that comes in your board documentation. So if it uses an IBUFDS normally that would connect to a top level clock input port. But perhaps that is one of the parameters that you are able to change in the configuration of the MIG IP. >>> >>> Regarding phases if you have a 5ns failure out of 20 that implies a 90 degrees phase change will fix it. But I can't say that this is the solution because it could cause other timing errors to pop up. Static timing always gives you the worst case, whether valid or not. But you can easily change the phase in the clock wizard dialog until you reach an acceptable value. >>> >>> But right now it looks like the MIG is introducing a big skew because of the IBUFDS. You should examine the clock reports post implementation to see if it looks sensible. I don't think adding more MIG clock outputs will help unless you can get rid of the big skew on the MIG clocking somehow. >>> >>> Other configurations are possible such as driving the MIG directly from a toplevel port, and operating the clk_wiz_0 from the MIG ui clock. >>> >>>> On 05/02/18 09:01, Anup Kini wrote: >>>> Hi Jonathan, >>>> >>>> When I use mig_sys_clk as 200 MHz for the peripheral soc, I get the following error msg during opt_design: >>>> >>>> ERROR: [Opt 31-304] Invalid connectivity on net clk_p_IBUF between IBUF clk_p_IBUF_inst and IBUFDS dram_ctl/u_mig_7series_0_mig/u_ddr3_clk_ibuf/diff_input_clk.u_ibufg_sys_clk. This is a dedicated connection. >>>> Resolution: Please fix the design to remove other logic connected onto this net. >>>> >>>> As a work around the above error, I generated an additional clock from within MIG. >>>> >>>> I will try to figure out how to mitigate the phase error, Incase you know a command or quick way to figure out the phase difference, Kindly help me with it. >>>> Will it be easier if I generate the UART, rmii and rmii_quad also from MIG ? >>>> >>>> >>>> >>>> Thanks & Regards, >>>> Anup Kini. >>>> >>>>> On Mon, Feb 5, 2018 at 1:54 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk&gt; wrote: >>>>> I don't know why you added a MIG additional clock 1, when 200MHz is >>>>> >>>>> already available as mig_sys_clk. I don't know if this is the cause of the >>>>> >>>>> problem, but since we don't know the innards of the MIG, it would seem >>>>> >>>>> prudent to avoid using this except for signals that directly drive the MIG. >>>>> >>>>> >>>>> However the actual violation seems to be a hold violation between a 25MHz clock >>>>> >>>>> and a 50MHz clock, which suggests that there is unwanted phase lag between >>>>> >>>>> the MIG clocks and the clk_wiz_0. However since clk_rmii goes nowhere else >>>>> >>>>> you are free to adjust the phase in the clock generator of clk_rmii and clk_rmii_quad >>>>> >>>>> to remove the hold violation. You should then confirm if you can with simulation that the >>>>> >>>>> function is still correct. >>>>> >>>>> >>>>>> On 05/02/18 06:20, Anup Kini wrote: >>>>>> Hi All, >>>>>> >>>>>> I am trying to port the lowrisc v0.5 design to a custom V2000T device >>>>>> >>>>>> System Details: >>>>>> Vivado 2015.4 >>>>>> lowrisc v0.5 release >>>>>> Ubuntu 16.04 LTS >>>>>> >>>>>> I have made the following changes to the clocks that are generated in the >>>>>> design, >>>>>> >>>>>> - 200 MHz to MIG, which generates a 100 MHz mig_ui_clk >>>>>> - MIG additional clock 0 - 25 MHz for the processor core (assigned to wire >>>>>> *clk*) >>>>>> - MIG additional clock 1 - 200 MHz for peripheral core psoc wire >>>>>> *clk_200MHz* >>>>>> - Modified the axi_clock_converter_0 clk_conv to 1:4 to match the 25 MHz >>>>>> processor input. >>>>>> >>>>>> - clk_wiz_0 clk_gen generates the following >>>>>> - clk_out_1 - 60 MHz for wire *clk_io_uart* >>>>>> - clk_out_2 - 50 MHz for wire *clk_rmii* >>>>>> - clk_out_3 - 50 MHz for wire *clk_rmii_quad* >>>>>> - I have removed the connection for pxl_clk, since I will not be using VGA >>>>>> or keyboard mouse. >>>>>> >>>>>> During place design, I get the following timing violation: >>>>>> >>>>>> Slack (VIOLATED) : -5.551ns (arrival time - required time) >>>>>> Source: eth_i/open/gmii_tx_inst/gmii_tx_en_reg_reg/C >>>>>> (rising edge-triggered cell FDRE clocked by >>>>>> clk_out2_clk_wiz_0 {rise(a)0.000ns fall(a)10.000ns period=20.000ns}) >>>>>> Destination: eth_i/open/tx_enable_dly_reg[2]/R >>>>>> (rising edge-triggered cell FDRE clocked by >>>>>> mmcm_clkout0 {rise(a)0.000ns fall(a)20.000ns period=40.000ns}) >>>>>> Path Group: mmcm_clkout0 >>>>>> Path Type: Hold (Min at Slow Process Corner) >>>>>> Clock Domain Crossing: Inter clock paths are considered valid unless >>>>>> explicitly excluded by timing constraints such as set_clock_groups or >>>>>> set_false_path. >>>>>> >>>>>> >>>>>> Kindly let me know if I have gone wrong in any of the clock settings or If >>>>>> this path has to be given set_false_path constraint. >>>>>> I have not attached the entire timing report in this mail. Let me know if >>>>>> that is required. >>>>>> >>>>>> >>>>>> Thanks & Regards, >>>>>> Anup Kini. >>>>> >>>>> >>>> >>> >> >