Good' day together, starting with Arty and just the first Problems..

[Dachs]

Hello together,

 I just got my first Arty A7-35 board and after playing around with some VHDL, I try to follow some tutorials now, which utlilize the microblaze and schematic editor.

 

I made a new project, selected my board (board files comes from the digilent github), and built a 'cookie cutter' schematic as shown in many tutorials. Clock wizard, ram, microblaze (83 MHz) and peripherials. I also did the connection automation as well as design validation (successful). 

But unfortunately it does not implement correctly (route design error): 

Quote

[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_0_mig/u_ddr3_infrastructure/gen_mmcm.mmcm_i. The computed FVCO is 400.000 MHz. The valid FVCO range for speed grade -1 is 600MHz to 1200MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 8.000, CLKIN1_PERIOD = 20.00000, and DIVCLK_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.

Quote

[DRC PDRC-34] MMCM_adv_ClkFrequency_div_no_dclk: The computed value 400.000 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_0_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 (20.000000), 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.

Where do the 400 MHz come from? I don't see any multiplier in the wizard to achieve this. And why does it not work like the tutorials, it's the standard workflow.

 

Thanks in advance for hints and solutions!

 

(Config is attached)

[Dachs]

Update:

If I set my clk_out_1 and 2 to "crazy" values (300 and 600 MHz) to meet the "GHz" requirements given in the error message it successvully runs through implementation , but this cannot be the solution (it also gives me timing error warnings) and I don't think that Arty is built only to work at exceeding maximum clock frequency. 

Before that I just started the schematic from scratch and filled in the same values like in all tutorials and it should work like this, maybe it is a bug.

Thanks and best regards!

[Dachs]

Hey together, sorry for spamming my own thread and all that self talk ? ..

 

..but maybe it helps to circle the problem.

Now I built a new block design from scratch with clock wizard and microblaze but without the DDR3 Memory block, and now it runs thru' it until successful bitstream generation.

So it seems like there is a compatibility problem/bug in one of the board libraries/IP of the DDR3 Memory Block, maybe an Issue with Vivado 2020.2, since a lot of the files is made for older versions of vivado? Could someone verify that?

As I mentioned before, I used Arty A7 board files v1.0 from the digilent github.  

 

Thanks a lot!

[JColvin]

Hi @Dachs,

I believe you'll need some different clock values from the Arty A7; based the table hiding in the Add a DDR Interface in our guide here: https://reference.digilentinc.com/reference/programmable-logic/guides/getting-started-with-ipi#add_a_processor_to_a_block_design, the Arty A7 should use 166.66667 MHz for it's sys_clk_i input for the MIG and 200 MHz for the ref_clk_i input.

I think I have heard of some issues with the MIG/Microblaze for the latest versions of Vivado that Digilent needs to look into. I will try making a simple design in 2020.1 / 20.2 like you show and see what I find.

Thanks,
JColvin

[Dachs]

Hello JColvin, thanks for your quick answer! I also tried those frequency, which gives me basically the same error (apart from different frequencies mentioned in the error message).

Thanks a lot for your help!

[JColvin]

Hi @Dachs,

I'm not sure what you mean by v1.0 of the board files, the latest board file for the Arty A7-35T is E.0, https://github.com/Digilent/vivado-boards/tree/master/new/board_files.

I was able to successfully generate a bitstream for the Arty A7 35T in Vivado 2020.2 with a simple Microblaze + USBUART in my block design. The Vivado library source I used is the one available on our GitHub, https://github.com/Digilent/vivado-library (I used the direct download, not the release).

Let me know if you have any questions about this.

Thanks,
JColvin

[Dachs]

Hi Jcolvin, 

 

thanks for your Answer. Don't ask me why, but I tried again now with cleaned directories, new project and I got a fresh download of the board files, which I'm 100 percent sure I already downloaded from that source (btw, by version I meant that one shown in the attachment, and it says Arty without T). And now it builds successfully including the bitstream.

But a couple of days ago I downloaded some board files via xilinx xhub, maybe that messed up something and I set the board directory now to the digilent boards exclusively. 

So, thanks a lot for your patience, maybe the gods of computer science had a good day ?