UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
458 Views
Registered: ‎05-12-2014

Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hello,

This question is related to the one that I asked yesterday, but I think that they are different enough that it warrants its own post.

I have an INPUT port that is routed to a connector for a pluggable board. I have two boards that may be plugged in (only one at a time). The same Artix-7 FPGA design must support both boards.

  1. When the first board is plugged in, the input port must function as a 250 MHz clock signal (the pin is SRCC).
  2. When the second board is plugged in, the input port must function as a data input. In this case, the data input can be thought of as asynchronous (it is not synchronous to any pin-level clock).

Because only one board can be plugged in at a time, the signal will never be used simultaneously as a clock signal and data signal. I see this as two mutually-exclusive scenarios that need to be individually constrained. Is this possible?

Thanks in advance for your advice!

Best regards,
Dave

0 Kudos
1 Solution

Accepted Solutions
224 Views
Registered: ‎01-22-2015

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Dave,

In short, I believe that you have correctly done what is needed to make your multiuse ports work properly.

Bear with me as I think out loud a little….

When thinking about this problem, it helps to note that there are certain “hardware truths” that cannot be changed by any constraints we write or by anything that timing analysis does. For example, when looking at the schematic for the INOUT_18P2 project, if we send a clock into port, CLKI1, then it will (without doubt) be routed to the input of CLKGEN1 – and CLKGEN1 will (without doubt) create output clocks from this input. Similarly, the signal, sig1_reg, will (without doubt) be sent to port, CLKI1, if our HDL code properly controls pin-T of the IOBUF.

When viewed in this light, the circuits described in the INOUT_18P2 project will correctly function as the multiuse ports that you require.

So, what are we worried about?  As always with FPGA work, we are worried that clocked-logic circuits in our design will pass timing analysis (ie. that they will function properly). Vivado does this job for us if each clocked-logic circuit is receiving a properly defined clock and we have not prevented proper timing analysis by writing an incorrect timing exception (ie. set_false_path).

So, our checklist for making the multiuse ports (CLKI1 and CLKI2) work properly is:

  1. Functionally correct hardware connections have been made between FPGA internal components and the multiuse ports. This has been achieved.
  2. Our HDL code knows what IO is present on the multiuse ports (ie. which board is plugged into these ports) and uses these IO properly. This is a straightforward HDL coding problem, I think.
  3. The clocked-logic circuits that we care about are receiving properly defined clocks and we have written proper timing exceptions/constraints for all circuits. This needs to be verified.

Work on item 3) goes something like the following…

Have clocks been properly defined?  I think the answer is yes – especially because you have reconfigured the MMCMs to have a clock-input Source of “no buffer”. Also, because you have used create_clock constraints that reference the FPGA ports (CLKI1 and CLKI2), which is conventional. Finally, report_clocks is showing no extra or unusual clocks in the design. For extra assurance that you have done the right thing, read AR#71679.

Are circuits that we care about receiving properly defined clocks? The sig1-to-OUT1 and the sig2-to-OUT2 circuits are representative of all the clocked-logic circuits that we care about. Running report_timing for these circuit-paths shows they are receiving the properly-defined clocks.

Are timing exceptions/constraints correct and enough? As you noted, the circuit from CLKI2-to-sig2 (when CLKI2 is considered an asynchronous signal input) need not undergo timing analysis. Therefore, the set_false_path exception you have written is appropriate and correct. Also, you have omitted set_input_delay or set_output_delay constraints for the multiuse ports, which is (I think) is necessary for the ports to be multiuse.  Omitting these constraints means that Vivado cannot do timing analysis on paths that extend through these ports to devices outside the FPGA.  Again, I think this is something we must "give up" in order for the ports to be multiuse.  I think that project, INOUT_18P2, now has all the necessary timing exceptions/constraints for the multiuse ports.

Again, congratulations on making this all work in Vivado. I hope you will post a short note to us when you get it working in hardware.

Cheers,
Mark

8 Replies
385 Views
Registered: ‎01-22-2015

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Dave,

My testing with Vivado (where I specified a 7-Series FPGA) shows there are no problems with what you are trying to do and that no special constraints need be written.

The design procedure I followed was:

  • For the clock-capable pin, place the usual set_property constraints for IOSTANDARD and PACKAGE_PIN in the project xdc-file.
  • In the top-level component of a VHDL design, specify the clock-capable pin to have mode, IN.
  • Use the Clocking Wizard IP as usual to create an MMCM, specifying that the Input Clock “Source” is a “Single ended clock capable pin”.
  • Connected the clock-capable pin to the MMCM clock input
  • Connected the clock-capable pin to fabric logic that receives a signal from the clock-capable pin.

Synthesis and implementation gave warnings about a redundant IBUF - but no errors. Clocking constraints associated with MMCM and with the FPGA clock-capable input were automatically created by Vivado and placed in a special constraints(xdc) file associated with the MMCM. 

Of course, your project needs to know which of the pluggable boards is being used so that it can properly use the input from the clock-capable pin.

Cheers,
Mark
CLKI2_to_MMCM.jpg

0 Kudos
345 Views
Registered: ‎01-22-2015

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Dave,

A trusted friend and guardian suggested that things don’t seem quite right with my previous answer to your post.  Upon reflection, it is amazing that this strange multiuse of an FPGA pin/port has not received more complaints from Vivado.  So, thought I’d look under the hood of this interesting problem and try to interpret what is found (I hope my guardians will keep a watchful eye on me).

Tools & Project:  I am using Vivado v2018.2 and have built a project that allows me to investigate the multiuse port you described in this post and the multiuse port you described in your <other post>.  The project is described nicely by the following schematic from the implemented design.  CLKI1 is the multiuse port that can be either a clock-input or a signal-output.  CLKI2 is the multiuse port that can be either a clock-input or a signal-input.  -and I’ve thrown in a few registers and other ports to make it look like a real project.

INOUT_proj.jpg

Constraints: I wrote only the usual set_property (IOSTANDARD and PACKAGE_PIN) constraints on each port.  I did not write set_input_delay or set_output_delay constraints.

Synthesis & Implementation:  no errors but a few warnings about “removing redundant IBUF” and “cannot create IBUF constraint”, which (because they are ordinary warnings) did not raise much concern

Timing Analysis:  passed

report_clocks:  CLKS1/inst/clk_in1, clkfbout_CLKGEN1, clk_out1_CLKGEN1, CLKS2/inst/clk_in1, clkfbout_CLKGEN2 clk_out1_CLKGEN2.  That is, one clock-input and two clock-outputs from each MMCM, which seemed normal at first glance (see report_methodology below).

report_timing_summary:  normal looking timing paths from sig1_reg to OUT1_reg and from sig2_reg to OUT2_reg

report_drc:  no violations found

report_methodology:  Aha!  I get a TIMING-2 warning, “A primary clock CLKS1/inst/clk_in1 is created on an inappropriate pin CLKS1/inst/clk_in1…”.   I also get a TIMING-27 warning, “A primary clock CLKS2/inst/clk_in1 is created on an inappropriate pin CLKS2/inst/clk_in1…”.   These warnings are described further in Appendix-A of UG906. 

Because of the TIMING-2 and TIMING-27 warnings, I looked at the constraints that Vivado autogenerated for the MMCMs, which are:

--from CLKGEN1.xdc:
create_clock -period 10.000 [get_ports clk_in1]
set_input_jitter [get_clocks -of_objects [get_ports clk_in1]] 0.1
set_property PHASESHIFT_MODE WAVEFORM [get_cells -hierarchical *adv*]

--from CLKGEN2.xdc:
create_clock -period 5.000 [get_ports clk_in1]
set_input_jitter [get_clocks -of_objects [get_ports clk_in1]] 0.05
set_property PHASESHIFT_MODE WAVEFORM [get_cells -hierarchical *adv*]

These constraints indicate that the clock-source for each MMCM is the clock-input pin of the MMCM.  This is unusual because the clock-source for this usage of MMCM would normally be FPGA pins/ports (ie. either [get_ports CLKI1] or [get_ports CLKI2] in this example).  So, is this a problem?  Well, it means that the MMCM cannot do the delay compensation described in UG472 for the path between the clock-capable input pins and the MMCM.  That is, phase of the MMCM clock outputs will not be kept aligned with phase of the clocks entering CLKI1 and CLKI2.  If the only purpose of the clocks entering CLKI1 and CLKI2 is to feed the MMCMs (ie. CLKI1 and CLKI2 are not used for FPGA IO), then I think this loss of phase-alignment (ie. delay compensation) is not a problem?

So, along with my original answer to your question, I should add that your multiuse ports are possible if:  1) the only purpose of the clocks entering CLKI1 and CLKI2 is to feed the MMCMs, and 2) you do not need to write set_input_delay or set_output_delay constraints on the multiuse ports/pins (ie. on CLKI1 and CLKI2).

Mark

Adventurer
Adventurer
299 Views
Registered: ‎05-12-2014

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Mark,

First off, you (and your guardians) are awesome! Thanks so much for your investigation into my problem and your detailed posts. I would like to use your example project as the starting point for some additional experimentation. If you still have it, would you mind to attach it to this post?

I will update this post with my results. Thanks again, and Happy New Year!

Best regards,
Dave

0 Kudos
281 Views
Registered: ‎01-22-2015

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Dave,

Your interesting questions gave me something to do over the (too long) holidays. Thank you.

Attached is a Vivado v2018.2 archive of the project.  As you’ll see, I’m using VHDL.

     I will update this post with my results.
Yes, please!  Once, I wanted to do what you are attempting but quickly discarded the idea as being too crazy.  So, I, for one, will be very interested to see if you get this working in hardware (ie. I suspect some challenges remain).

Happy New Year!
Mark

0 Kudos
Adventurer
Adventurer
252 Views
Registered: ‎05-12-2014

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Mark,

After working with the example project for a bit, I think that the "redundant IBUF" warnings and TIMING warnings are related to the configuration of the Clocking Wizard IPs. They are configured with the input clock source set to "single ended clock capable pin." I think this means that the IP is expecting the clk_in1 port to be connected directly to a top-level port (that is, not through an IBUF). Therefore, the IP is attempting to instantiate an IBUF internally, which is where the redundant IBUF warnings are coming from. As a further consequence of this, the timing constraints generated by the IP are not exactly correct, because they are assuming that the clk_in1 port is indeed a top-level port -- and because it is not, the TIMING warnings are generated.

So I re-customized the IP to set the input clock source to "no buffer" because we are separately instantiating the IBUFs. When I did this, the timing constraints generated by the IP changed:

--from CLKGEN1.xdc:
# Input clock periods. These duplicate the values entered for the
# input clocks. You can use these to time your system. If required
# commented constraints can be used in the top level xdc
#----------------------------------------------------------------
#create_clock -period 10.000 [get_ports clk_in1]
#set_input_jitter [get_clocks -of_objects [get_ports clk_in1]] 0.1
set_property PHASESHIFT_MODE WAVEFORM [get_cells -hierarchical *adv*] --from CLKGEN2.xdc: # Input clock periods. These duplicate the values entered for the
# input clocks. You can use these to time your system. If required
# commented constraints can be used in the top level xdc
#----------------------------------------------------------------
#create_clock -period 5.000 [get_ports clk_in1]
#set_input_jitter [get_clocks -of_objects [get_ports clk_in1]] 0.05
set_property PHASESHIFT_MODE WAVEFORM [get_cells -hierarchical *adv*]

So I copied and pasted the commented constraints into the top-level XDC file, replacing clk_in1 with either CLKI1 or CLKI2, as appropriate:

 

create_clock -period 10.000 [get_ports CLKI1]
set_input_jitter [get_clocks -of_objects [get_ports CLKI1]] 0.1
create_clock -period 5.000 [get_ports CLKI2]
set_input_jitter [get_clocks -of_objects [get_ports CLKI2]] 0.05

 

 

Synthesis & Implementation: No warnings.

Timing Analysis: Passed.

report_clocks: CLKI1, clkfbout_CLKGEN1, clk_out1_CLKGEN1, CLKI2, clkfbout_CLKGEN2, clk_out1_CLKGEN2 (note that the top-level ports are now in there)

 

Report Clock Interaction: We now see that there is an unsafe interaction on the path from CLKI2 to sig2_reg/D. This is because we are using the output of the CLKI2 IBUF as a data input in a different clock domain. However, in my particular case we know that when this signal is used as a data input, it is not simultaneously used as a clock input. Furthermore, this is an asynchronous data input in my design, so I added the following timing exception to the top-level XDC file and re-implemented the design: set_false_path -from [get_ports CLKI2] -to [get_pins sig2_reg/D]

Note: If this had not been an asynchronous data input, I don't know if/how it could be constrained against its real clock domain, because the tool already thinks that it is part of the CLKI2 domain.

Report DRC: No violations found.

Report Methodology:

Warning TIMING-10: One or more logic synchronizer has been detected between 2 clock domains but the synchronizer does not have the property ASYNC_REG defined on one or both registers. It is recommended to run report_cdc for a complete and detailed CDC coverage
Warning TIMING-18: An output delay is missing on OUT2 relative to clock(s) CLKI1

The first warning concerns the asynchronous input false path, and could be remedied by properly using a synchronizer on that asynchronous input. The second warning can be ignored in my particular case because that output is also asynchronous in my design.

 

Mark, do you see any problems with my analysis? At the end of the day, I find myself coming to the same conclusion as you did: It seems likely that these "multiuse" ports will work as long as I do not need to have set_input_delay/set_output_delay constraints on them (i.e., the data signals are asynchronous to the design).

Thanks again for all your help!  -- Dave

 

225 Views
Registered: ‎01-22-2015

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Dave,

In short, I believe that you have correctly done what is needed to make your multiuse ports work properly.

Bear with me as I think out loud a little….

When thinking about this problem, it helps to note that there are certain “hardware truths” that cannot be changed by any constraints we write or by anything that timing analysis does. For example, when looking at the schematic for the INOUT_18P2 project, if we send a clock into port, CLKI1, then it will (without doubt) be routed to the input of CLKGEN1 – and CLKGEN1 will (without doubt) create output clocks from this input. Similarly, the signal, sig1_reg, will (without doubt) be sent to port, CLKI1, if our HDL code properly controls pin-T of the IOBUF.

When viewed in this light, the circuits described in the INOUT_18P2 project will correctly function as the multiuse ports that you require.

So, what are we worried about?  As always with FPGA work, we are worried that clocked-logic circuits in our design will pass timing analysis (ie. that they will function properly). Vivado does this job for us if each clocked-logic circuit is receiving a properly defined clock and we have not prevented proper timing analysis by writing an incorrect timing exception (ie. set_false_path).

So, our checklist for making the multiuse ports (CLKI1 and CLKI2) work properly is:

  1. Functionally correct hardware connections have been made between FPGA internal components and the multiuse ports. This has been achieved.
  2. Our HDL code knows what IO is present on the multiuse ports (ie. which board is plugged into these ports) and uses these IO properly. This is a straightforward HDL coding problem, I think.
  3. The clocked-logic circuits that we care about are receiving properly defined clocks and we have written proper timing exceptions/constraints for all circuits. This needs to be verified.

Work on item 3) goes something like the following…

Have clocks been properly defined?  I think the answer is yes – especially because you have reconfigured the MMCMs to have a clock-input Source of “no buffer”. Also, because you have used create_clock constraints that reference the FPGA ports (CLKI1 and CLKI2), which is conventional. Finally, report_clocks is showing no extra or unusual clocks in the design. For extra assurance that you have done the right thing, read AR#71679.

Are circuits that we care about receiving properly defined clocks? The sig1-to-OUT1 and the sig2-to-OUT2 circuits are representative of all the clocked-logic circuits that we care about. Running report_timing for these circuit-paths shows they are receiving the properly-defined clocks.

Are timing exceptions/constraints correct and enough? As you noted, the circuit from CLKI2-to-sig2 (when CLKI2 is considered an asynchronous signal input) need not undergo timing analysis. Therefore, the set_false_path exception you have written is appropriate and correct. Also, you have omitted set_input_delay or set_output_delay constraints for the multiuse ports, which is (I think) is necessary for the ports to be multiuse.  Omitting these constraints means that Vivado cannot do timing analysis on paths that extend through these ports to devices outside the FPGA.  Again, I think this is something we must "give up" in order for the ports to be multiuse.  I think that project, INOUT_18P2, now has all the necessary timing exceptions/constraints for the multiuse ports.

Again, congratulations on making this all work in Vivado. I hope you will post a short note to us when you get it working in hardware.

Cheers,
Mark

Adventurer
Adventurer
177 Views
Registered: ‎05-12-2014

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution
Hi Mark, thanks again for all of your attention and help. It is greatly appreciated. It's still going to be a little while until I have the PCBs to actually test this in hardware, but I will try to remember to post a little something when I do. Have a great day!

Best regards,
Dave
0 Kudos
149 Views
Registered: ‎01-22-2015

Re: Can an input pin be treated as either an input clock signal or an input data signal?

Jump to solution

Hi Dave,

-some afterthoughts:

1) The MMCM called CLKGEN1 has output, clk1. The MMCM called CLKGEN2 has output, clk2.   These clocks, clk1 and clk2, cannot be considered synchronous – even if the inputs to these MMCMs are synchronous.  That is, if you plan to pass data between the clk1-domain and the clk2-domain, you will need to use a synchronizer.

2) When the multiuse input, CLKI2, is used as a signal input then we have agreed that this must be an asynchronous signal input. -and you have correctly put a set_false_path timing exception on this input.  You should also place a 2-flip-flop synchronizer on this input take care of the metastability problem.

Mark