Jump to content

apullin

Members
  • Posts

    5
  • Joined

  • Last visited

apullin's Achievements

Newbie

Newbie (1/4)

0

Reputation

  1. Ah. OK. This sends me down the right path. If the requirement is that it is user responsibility to create a 166.67 Mhz block, connect it to the MIG sys_clk_i, and manually set the MIG UI configuration setting to match, then things are a little clearer. I was using the 166 Mhz clock to run the Microblaze, but turned that down to 100 Mhz since it was failing timing. My solution ultimately was to generate 3 clocks with the Clocking Wizard: - 100 MHz for the Microblaze (fails timing higher than this) - 166.67 Mhz for MIG sys_clk_i, per the requirement in the reference doc - 200 Mhz for MIG ref_clk_i, following the guide Although I am not sure if this follows "best practices", it does result in a generated bitstream. Block Design (slightly different than above TCL, since I re-created the project): @thinkthinkthink thanks for the help!
  2. Well, I also tried installing 2020.1 and reproducing the project, and I cannot get it to work. With clk_ref_i = 200 Mhz , sys_clk_i = 100 Mhz, the error now reports CLICK1_PERIOD of 20.00000 . No idea what is going on.
  3. Thanks for trying that out for me. I am using Vivado 2020.2.2, the absolute latest version, because I just installed it. I cannot find any combination of settings that seem to make this work. Although it is quite opaque to me, and unclear why there are two separate clocking options, the two that you highlight. Shouldn't the "Input Clock Period" match up with either the 66.667 Mhz clock or the 200 Mhz clock from the clocking wizard that generates the wires that run to sys_clk and ref_clk? Also of note is that when I try to regenerate the configuration for the MIG, I get the error: [Vivado 12-3563] The Nested sub-design 'c:/Users/my_user/fpga/arty_microblaze/arty_microblaze.srcs/sources_1/bd/design_1/ip/design_1_mig_7series_0_0/design_1_mig_7series_0_0.xci' can only be generated by its parent sub-design. And, again, searching in the Vivado forum only results in finding a handful of years-old death threads with no solution. I am starting to suspect that this is either a bug in 2020.2.2, or some kind of regression introduced into the block automation that the Digilent board files provide, due to the new version.
  4. I am following various tutorials and tinkering of my own to try and get a Microblaze core working on Artix, to try it out on my Arty board. I am fairly new to FPGA tech, and so I can neither find a working configuration, nor do I understand how I should attack this problem given the silicon I am trying to work on. Of course, the latter is the knowledge I would like to develop. For a standard Microblaze design w/ 128K BRAM and a few AXI peipherals, i.e. GPIO and USB-UART, it works fine, and I can use the Clocking Wizard to generate a clock in the 100-166.6667 Mhz range, and it seems to implement and run OK. But now I would like to try and get the SDRAM working. Following this older walkthrough, I am adding a 2nd clock output, 200Mhz, to use as the ref_clk to the Memory Interface Generator. https://reference.digilentinc.com/learn/programmable-logic/tutorials/arty-getting-started-with-microblaze/start If I am understanding the error correctly, something in the Memory Interface Generator core is just not working out correctly, and not choosing the right clock settings? I am slowly reading through the 7 Series Clocking Resources User Guide, but it is quite a lot to take in. Same for the MIG IP docs. I have really mostly be using default this-and-that, generated by the Digilent board files automation tie-ins and fairly naieve drag-and-drop block design. From reading, it seems like many Vivado problems are solved with fairly trivial actions, like "regenerate this block". So I am unsure if this is a procedural Vivado thing, or a real physical setting being wrong. Regenerating the MIG IP by opening the block and clicking through, then re-running synthesis does not appear to resolve the issue. And unfortunately, the Xilinx forums appear to be a dead end for this, with no clear solution. (but, apparently, other people having this same issue for the same eval board). The actual warning I am getting is: [DRC AVAL-46] v7v8_mmcm_fvco_rule1: The current computed target frequency, FVCO, is out of range for cell design_1_i/mig_7series_0/u_design_1_mig_7series_0_5_mig/u_ddr3_infrastructure/gen_mmcm.mmcm_i. The computed FVCO is 266.667 MHz.The valid FVCO range forspeed grade -1 is 600MHz to 1200MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 8.000, CLKIN1_PERIOD = 30.00000, andDIVCLK_DIVIDE = 1 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)) This violation may be corrected by 1. The timer uses timing constraints for clock period or clock frequency that affect CLKIN1 to set cell attribute CLKIN1_PERIOD, over-riding any previous value. This may already be in place and, if so this violation will be resolved once Timing is run. Otherwise, consider modifying timing constraints to adjust the CLKIN1_PERIOD and bring FVCO into the allowed range. 2. In the absence of timing constraints that affect CLKIN1, consider modifying the cell CLKIN1_PERIOD to bring FVCO into the allowed range. 3. If CLKIN1_PERIOD is satisfactory, modify the CLKFBOUT_MULT_F or DIVCLK_DIVIDE cell attributes to bring FVCO into the allowed range. 4. The MMCM configuration may be dynamically modified by use of DRP which is recognized by an ACTIVE signal on DCLK pin. And the errors I am getting are: [DRC PDRC-34] MMCM_adv_ClkFrequency_div_no_dclk: The computed value 266.667 MHz (CLKIN1_PERIOD, net pll_clk3) for the VCO operating frequency of the MMCME2_ADV site MMCME2_ADV_X1Y0 (cell design_1_i/mig_7series_0/u_design_1_mig_7series_0_5_mig/u_ddr3_infrastructure/gen_mmcm.mmcm_i) falls outside the operating range of the MMCM VCO frequency for this device (600.000 - 1200.000 MHz). The computed value is (CLKFBOUT_MULT_F * 1000 / (CLKINx_PERIOD * DIVCLK_DIVIDE)). Please run update_timing to update the MMCM settings. If that does not work, adjust either the input period CLKINx_PERIOD (29.999998), multiplication factor CLKFBOUT_MULT_F (8.000000) or the division factor DIVCLK_DIVIDE (1), in order to achieve a VCO frequency within the rated operating range for this device. and [DRC PDRC-43] PLL_adv_ClkFrequency_div_no_dclk: The computed value 533.333 MHz (CLKIN1_PERIOD, net clk_out1) for the VCO operating frequency of the PLLE2_ADV site PLLE2_ADV_X1Y0 (cell design_1_i/mig_7series_0/u_design_1_mig_7series_0_5_mig/u_ddr3_infrastructure/plle2_i) falls outside the operating range of the PLL VCO frequency for this device (800.000 - 1600.000 MHz). The computed value is (CLKFBOUT_MULT_F * 1000 / (CLKINx_PERIOD * DIVCLK_DIVIDE)). Please adjust either the input period CLKINx_PERIOD (14.999999), multiplication factor CLKFBOUT_MULT_F (8) or the division factor DIVCLK_DIVIDE (1), in order to achieve a VCO frequency within the rated operating range for this device. My current project is attached as a ZIP of the exported project TCL. Any insight or feedback would be appreciated. arty_microblaze_proj_tcl.zip
×
×
  • Create New...