ARTY A7-100 Need to use external clock

[davec]

Hi,

How do I bring the clock in on a different pin?

I have a working microblaze design on an Arty A7-100 board and need to provide my own external 100 MHz clock.  When I define the clock pin in my constraints file, I get this error:

"[Place 30-575] Sub-optimal placement for a clock-capable IO pin and MMCM pair. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule. < set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets hopper_i/clk_wiz_0/inst/clk_in1_hopper_clk_wiz_0_0] > hopper_i/clk_wiz_0/inst/clkin1_ibufg (IBUF.O) is locked to IOB_X0Y76 hopper_i/clk_wiz_0/inst/mmcm_adv_inst (MMCME2_ADV.CLKIN1) is provisionally placed by clockplacer on MMCME2_ADV_X1Y2 The above error could possibly be related to other connected instances. Following is a list of all the related clock rules and their respective instances. Clock Rule: rule_mmcm_bufg Status: PASS Rule Description: An MMCM driving a BUFG must be placed on the same half side (top/bottom) of the device hopper_i/clk_wiz_0/inst/mmcm_adv_inst (MMCME2_ADV.CLKFBOUT) is provisionally placed by clockplacer on MMCME2_ADV_X1Y2 and hopper_i/clk_wiz_0/inst/clkf_buf (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y21"

It seems the clock wizard is being placed from the board file in a location not compatible with my desired pin constraint (P17), even though I select "custom" in the clocking wizard IP for clock input, instead of board file.  Do I need to draw a GCLK IOB in the block design, or some such?

Thanks

[zygot]

This is one of those instances where the tool actually provides a clear and detailed description of your problem. It's less clear about how to resolve it.

FPGAs have clocking regions. Intel FPGA devices tend to be more restrictive in this regard, and boards using those devices require more externally connected clock inputs. You can read the Series 7 Clocking reference manual as well as the documentation on timing closure for more details, and I highly recommend doing that. The tools come with default synthesis and implementation strategies that don't always overcome all FPGA board design choices. You are stuck with the board layout and pin assignments that you have. This isn't necessarily a problem though. You can change the default strategy settings. You can manually place resources like MMCM to be more "optimal", though this might impact timing closure depending on your design and the IO pin assignments that you have to work with.

Probably the best way forward is just to add the CLOCK_DEDICATED_ROUTE BACKBONE constraint suggested by the tools and see if you have timing issues in the post-implementation reports ( assuming that you have the report set up appropriately ). This likely works for just about anything that you want to do with your board. Vivado provides templates for such constraints, though these are not always up to date making them not so helpful. The TCL console is another way to obtain valid syntax for constraints. Sometimes this works out. Unfortunately, these features sometimes provide guidance that the synthesis and P&R tools will subsequently reject due to syntax changes. The tools, using the GUI, are just too complicated to maintain... though this problem as a pretty easy fix.

It isn't likely that you can connect an external clock source to your FPGA clock capable pin optimally anyway. There are FPGA boards that are designed to accept such signals. Except for boards with SYZYGY or FMC headers Digilent boards are not designed to accept external clock sources. Most likely, this isn't a significant issue for any designs that are likely to be implemented on the cheaper FPGA platforms.

I'm not sure why Xilinx has decided that a "non-optimal" class message that might be just a warning should be a promoted to a bitgen error... perhaps it's just to get the customer's attention to a possible situation where the tools can't produce great results. There are a lot of moving parts involved in pin assignments and resource placement and the tools are designed to avoid certain failure modes.

Often overlooked is the fact that clocking wizards in FPGA vendor tools depend on a default jitter specification. This resolves some issues but adds restrictions as well. I haven't tried this but you can experiment with the settings to see if this makes a difference... though I'd be surprised if it does.

This is one of those questions where being inquisitive and willing to do some experimentation would definitely be worth the time and effort if one wants to get good at this, but usually most people are just interested in completing a particular objective. Edited July 18, 2022 by zygot

[davec]

Thanks for your reply zygot.  Vivado also says:

"The above error could possibly be related to other connected instances. Following is a list of all the related clock rules and their respective instances.

    Clock Rule: rule_mmcm_bufg
    Status: PASS
    Rule Description: An MMCM driving a BUFG must be placed on the same half side (top/bottom) of the device
     hopper_i/clk_wiz_0/inst/mmcm_adv_inst (MMCME2_ADV.CLKFBOUT) is provisionally placed by clockplacer on MMCME2_ADV_X1Y2
     and hopper_i/clk_wiz_0/inst/clkf_buf (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y21"

Something is telling the placer to put the MMCM in X1Y2, which is where the original clk pin was (E3).  I constrained the clk to be on pin P17, which should be in X0Y1.  Is this from a board file, or maybe there is no MMCM in X0Y1 region of this chip?

It routed with CLOCK_DEDICATED_ROUTE BACKBONE and CLOCK_DEDICATED_ROUTE FALSE constraints on the clk_wiz.

In the old days, I would pip hack the connection if the router would not, but these chips are too big for that.  :^)

[zygot]

I (almost) always specify a device part number rather than a board in the project setting because I do an HDL design flow rather than the IPI design flow. I mention this because I do run into this situation for larger designs using multiple clock domains sourced by unrelated external clocks. Being unaware of all of the constraints in a design can indeed cause problems. Your observation about the MMCM placement being correct for an external clock that might be good for an external clock pin assignment in the board file sources is more than interesting and worth tracking down. I figure that one needs to be familiar with the quirks and habits of one's team mates if one wants to win games. In the case of FPGA vendor tools it's not always clear that they are on the same team as I am. I decided a long time ago that letting the tools be in charge was not in my best interests even if that meant more work for me. I keep coming across reasons to continue with that strategy every once in a while. New tool versions introduce new bugs and odd behaviors as documentation doesn't keep up with syntax or database changes and updating scripts get overlooked. The trend with the big FPGA vendors is to 'encourage' ( or force ) users into letting the tools manage the details of a project, so I find myself fighting with the tool even more than previously.

You'd think that the tools would find a problem with an initial placement strategy that would lead to a hard error early in the analysis phase and terminate processing well before going through a complete analysis and implementation run. You'd think that making a 'pre-processor' that identifies confusing source constraints very early in the operation of the tools and notifies the user wouldn't be that hard to do. No doubt, companies that run the tools from home-grown scripts rather than the GUI interface do this as finding some problems before going through the algorithm crunching phase should save a lot of time.

FPGA vendor tools don't reveal all of the 'tricks' behind the curtain. Sometimes this causes consternation and mysterious and seemingly bizarre behavior. Either you investigate or just move on. In general modern FPGA devices are so good that most designs never need that much hand holding in terms of timing closure. It might be wise to just put off worrying about having designs that are 'non-optimal' until timing closure becomes a problem... or not. I tend to stick with older tool devils ( versions ) that I know unless there's a compelling reaons not to so spending the time to resolve such quirks makes more sense. When I do need to use a newer version of the tools there tends to be a limit on how much time I'm willing to choose to spend fighting the tools verses how much time I have no other choice.

[edit] It might be an easy and simple experiment to create a separate project, using the same sources, but targeting the proper device rather than your board. I do similar sanity checks when confronted with odd issues that seem to be very weird. A/B testing is a tried and true form of debugging, particularly when you are debugging the tools. More often, I find myself doing this with a different version of the tools on a different PC host to help expose release bugs and quirks. This works best with HDL designs of course as breaking old IP is a constant feature of new tools. I'm very cautious of letting the tools know more than they need to about my designs and platform because what exactly they do with board files isn't well documented or transparent. I do know, based on experience that the same IP, when used in native mode for the HDL design flow, doesn't get implemented the same way or work the same way as when used in the IPI flow... at least for the few times that I've tried doing this to test out new FMC mezzanine cards. Generally, the time saving and detail hiding options of FPGA vendor tools ends up giving me more problems than any imagined benefit. I do recommend that no one ever try and run two instances of the tool on the same host as this is a good way to expose some really bad coding practices on the part of the tool developers, in particular for Vivado. Edited July 19, 2022 by zygot

[davec]

Has anyone ever had success bring sys_clk in on a different pin on the ARTY (other than E3)?  I cannot get a complete route no matter what i do.  It seems SOMETHING in the board file is always placing the MMCM in a clock region (X0Y1) different than the MRCC clock pin that I am trying to use.  Clock_dedicated_route_false does not help.

[zygot]

There's nothing special about the ARTY as far as using a MRCC or SRCC pin routed to a PMOD connector as a clock source is concerned. You shouldn't be having so much trouble with it... so perhaps there's something else going on. You can definitely use any available clock capable pin as an eternal clock source regardless of the platform being targeted. I frequently have multiple clock domains using pins that aren't defined in the master constraints file supplied by board vendors.

You mention assigning sys_clk to an arbitrary pin. Signal names are important. Try naming your new clock 'clock_p17' or other unique name. I suspect that reading the messages carefully will help identify the problem. Make sure that you source and constraints are using the EXACT same name for signals.

This is one of the many examples where the IPI design flow causes more headaches and confusion than an HDL design flow would if the designer maintains all of the sources, including the constraints file(s).

Don't for get to supply at least one timing constraint defining your new external clock frequency. If you have more than one clock domain in your design you need to know how to allow signals in your design interact properly using good logic design methods. You are likely to require additional timing constraints to get good synthesis and implementation results. Except for the few IPI design example projects that handle this for you, this design flow isn't so helpful when you want to do a custom design.

I don't have a huge problem with IPI. It just isn't good for learning FPGA development. Sometimes it's OK for an expert in programmable logic design who just wants to quickly prototype an idea or concept. Even then it only works out well some of the time as script generated source code isn't usually easy to slog through when things aren't working as expected. Edited July 26, 2022 by zygot