cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
23,046 Views
Registered: ‎06-30-2013

Zynq7020 interface to four ADS62P49 ADCs

Jump to solution

Hi Avrum:

 

I have seen multiple posts form you with very detailed answers to questions that are related to my issue and yet I must fundamentally not fully understand the clocking resources and constraint mechanisms that are required for my design.

 

Background:

I am using a ZedBoard with Zynq7020 to interface to a 4DSP FMC104 quad channel ADC card over an FMC-LPC interface.  Each of the four ADS62P49 ADCs provide their own differential clock and differential 7-signal DDR data bus.  The source of all of the ADC clocks are provided by a common PLL clock on the FMC104 with individual low skew clock buffers.  This is significant I believe because it means that if the trace routing for the ADC input clocks and output clocks and DDR data bus are matched, I think it should be possible to use only one ADC output clock to capture all DDR data in the Zynq7020.  In communication with 4DSP, they seem to have agreed with this approach??

 

Two of the ADC DDR busses and corresponding clocks are driven into IO Bank 34 with the clocks supplied to clock capable inputs sites M19/M20 and N19/N20.  The other two ADC DDR busses and corresponding clocks are fed into bank 35 with the clocks supplied to clock capable input sites B19/B20 and C20/D20.

 

I have tried several approaches but so far no approach has worked correctly other than I meet timing. My fear is that I have not properly constrained the design or am not using the correct clock infrastructure to accomplish what I need.

 

Because the data is supposed to be aligned properly as it leaves each TI ADS62P49 ADC chip,  and I believe the trace routing lengths to be relatively well matched on the FMC104 and ZedBoard, I thought I could simply feed the first ADC's clock (CLK_AB at M19/M20) into an IBUFGDS and then into an MMCM.  I configure the MMCM to have the CLK0 output phase aligned to the input clock for a source synchronous implementation.  The MMCM's CLK0 output is just re-generating the 100MHZ clock and my though was that I did not require anything else if I fed each of the seven IDDR blocks set for "SAME_EDGE_PIPELINED" mode to convert the ADC data to SDR.  The IDDR blocks are very close to each ADC differential IOB block so I assume that the data path skew is zero or very close.  Is this correct?

 

I did not think that any IDELAY elements would be required but from reading other forum posts I am questioning that belief as well as being unclear if my treatment of the clock capable CLK_AB signal is correct since it is not brought in on a global clock site.

 

I only have a simple PERIOD constraint on the MMCM clock input and I have no RISING or FALLING constraints on the actual ADC DDR busses into the IDDR elements.

 

Here is one more  interesting data point.  I rebuild the MMCM to have a second CLK1 output that has dynamic phase control and I implement a simple machine to allow the phase to be incremented and decremented.  I use a BUFGMUX_CTL to select between the MMCMs CLK0 and CLK1 outputs to select which clock I feed to all of the IDDRs for all four ADC channels.

 

If I manually adjust the phase of CLK 1, I can get good SDR ADC data from the IDDRs so I know my issue is internal clock/data alignment at the IDDR elements.

 

What am I fundamentally doing wrong here?

Are IDELAYs actually required or do I need to either fix the clock distribution mechanism or add correct data/clock constraints?

I thought that if the clock capable input was fed into the MMCM, then the clock outputs of the MMCM were automatically available to the global clock distribution fabric and hence to the IDDR elelements in banks 34 and 35?

 

Please help me understand what I am missing here?  I will supply any other design data that you require to help me so please advise as I have been struggling for a couple of weeks and cannot figure out how to solve the problem correctly.

 

Thank you very much for your help,

 

Craig

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
24,910 Views
Registered: ‎01-23-2009

how do I handle the differential clock?  Do I just refereece the positive half

 

If you have differential inputs or outputs (clocks or data) it is sufficient to constrain the P side only - you don't need to apply timing constraints to the N side.

 

If the FIFO inputs are at the same frequency and just phase shifted (meso-synchronous I believe?) can one just leave the read and write clock enables high and expect valid data in the new clock domain?

 

Mostly.

 

The phase of the 2 clocks can vary slighty over time. So if you start reading on the first clock that EMPTY is not asserted, and read continually from there you may underflow your FIFO; if the read clock starts drifting "earlier" then there may be one or a few clocks where there is no data in the FIFO to pop. The number of times this can happen is finite - depending on the possible phase drift of the clocks (and one for metastability), but...

 

If, on your read side, you wait for EMPTY to deassert and then wait for a few clocks (4 is probably enough, but you could consider 8) before you assert your read signal, then you are guaranteed to never underflow the FIFO, and you can read continually from this point. Your FIFO needs to be big enough to hold more than twice that number of entries (since the clocks can drift the other way), plus a few more for clock crossing latency. So, you can (and should) use a distributed RAM based dual-port FIFO - the distributed RAMs can hold 64 entries, so this is more than enough.

 

Avrum

View solution in original post

0 Kudos
38 Replies
Highlighted
Guide
Guide
22,995 Views
Registered: ‎01-23-2009

Craig,

 

I think it should be possible to use only one ADC output clock to capture all DDR data in the Zynq7020

 

I am pretty sure this can't work. You didn't tell me what sampling rate you are working at, so I will assume the fastest (210MSPS).

 

At this speed, the ADCs provide data centered around their individual clocks. The Tsu(min) and Th(min) are 0.75ns/0.75ns for a total data eye of 1.5ns. This is enough to capture statically.

 

Now lets look at what you are doing. We assume that the clock source on the 4DSP card is a clean clock and is distributed to the different DSPs in a balanced manner, and further that all 4 DSPs are using the same power supply and are at more or less the same temperature (they are on the same board). Therefore, according to the TI spec, the four output clocks will be "more or less" in phase - they are spec'ed as being "Tdelay SKEW", which is +/-500ps.

 

So, lets say you use only one clock to capture all the data. The data from one of the other channels has 0.75ns/0.75ns su/h with respect to its own clock. However, its clock may be 500ps earlier than the one you are sampling on (so the setup time goes down to 0.25ns), or it could be 500ps later than the one you are sampling on (so the hold time goes down to 0.25ns) [edit: actually vice versa, but it doesn't matter]. This gives a total data eye of 0.5ns, which is way to small to sample.

 

So, you have to sample each of the four data channels using its own clock. The ideal way to do this is to use "chip sync" clocking. Each of the clocks comes in on a clock capable I/O, and the data for that channel comes in on the same bank, so everything is good. Take the clock (after the IBUFGDS) and drive it to the input of both a BUFIO and BUFR. Then use the BUFIO to drive the clock of the IDDRs (SAME_EDGE_PIPELINED mode seems good) that you are using to capture the data. Now, you can capture the data with respect to this clock (in the IDDR) and can manipulate the data using the BUFR clock.

 

Of course, the data eye provided by the ADC is not in the right place to be sampled by the IDDR (with BUFIO clocking) as is, and will need to be modified. Refer to this post to insert the IDELAYs (on both clock and data) and adjust them properly.

 

Now you have each of the four channels captured, and running on their own BUFR clock domain. Now what do you need to do with them?

 

If you just want to process them, then you can just do so on the BUFR domain; keeping each of the four channels separate.

 

If you need to be able to do some analysis (or other transferring of data) on a common clock domain, then you need to bring the data from the 4 channels into one domain. Now we have a question... Are the four domains carrying correlated data? If the answer is "no" (i.e. there is no correlation between the channels - they are all independent analog signals being analyzed) then any clock crossing style will work. The easiest is a mesochronous clock crossing FIFO using distributed RAMs.

 

If, however, the data needs to be correlated, then things get more complex. We know that each of the four BUFR clocks are now within +/-500ps of eachother. Since they are all running at 210MHz, then you have a 4.76ns period. Internally, it should be easy to cross between these - you might just want to go from the falling edge of one domain to the rising edge of the other - that will give a little less than 2ns setup and 2ns hold internally, which is more than enough. Then you can do what you want with them - cross all of them into a global domain, or anything else. Of course, the BUFR clocks can only drive one clock region, so you may have some trouble bringing data from one domain to the other if they are not in the same, or at least adjacent regions.

 

It may also be possible to independently cross them all into a global domain. If you use one of the clocks as a "global" clock - use an MMCM a BUFG, with BUFG feedback, then the phase of the global clock should be "similar" to the phase of the BUFR clocks. You may be able to go synchronously between them - but I haven't analyzed this system, and we would need the timing analyzer (preferably in Vivado) to determine if this is OK. You would need to describe to the tool the uncertaintly between all these clocks to the tool though, to make sure it understands the +/-500ps skew between the clocks.

 

Avrum

Highlighted
Guide
Guide
22,988 Views
Registered: ‎01-23-2009

clock capable CLK_AB signal is correct since it is not brought in on a global clock site

 

In the 7 series, there are no global clock sites. In earlier generations (V5 particularly), there was a clear distinction between the clock capable I/O that can drive the BUFIO/BUFR, and the global clock sites that can drive DCM/MMCM and BUFG. In Virtex-6, they still had global clocks, but some of the clock capable I/O could also drive the BUFG and MMCM.

 

In the 7 series, the only clock inputs are the clock capable I/O, and they can drive the BUFIO/BUFR in the same region, as well as the MMCM in the same region and any BUFG.

 

Avrum

Highlighted
Guide
Guide
22,987 Views
Registered: ‎01-23-2009

I only have a simple PERIOD constraint on the MMCM clock input and I have no RISING or FALLING constraints on the actual ADC DDR busses into the IDDR elements

 

You must constrain the inputs. Without OFFSET IN constraints (or set_input_delay commands in Vivado), the tool has no information about the arrival time of the data, and hence the paths are unconstrained. Since there is no constraint, then, by definition, they pass.

 

You didn't tell me if you are using ISE or Vivado - I am assuming ISE.


On re-reading, I see that you did mention that the clock is 100MHz. The TI spec says the output clock duty cycle is Typ 52%. This worries me... Typical timings are completely useless for analyzing interfaces, and I have no idea why manufacturers specify them. All we care about is the min and max. For the moment, I will assume that the clock is 48/52, so the high and low times can be anywhere between 2.4ns and 2.6ns

 

Looking at the Kintex-7 datasheet in a -1 part, the device needs Tpscs/Tphcs of -0.34/1.73, which means a capture window of [0.34,1.73]; this is a 1.39s window. Your data has a valid window of [-0.75,0.75], so the two windows don't line up. Now you have to decide how to capture this. Do we push the data forward into the devices required window (by adding delay to the data), or push the clock forward to push the required window into the next data window (by adding delay to the clock).

 

If we do the former, then we lose +/-5ps/tap for the data dependent jitter of the idelay. If we do the latter, then we incur the penalty of the duty cycle imprecision of the ADCs clock (+/-100ps). Its probably better to do the former.

 

So, the ISE constraint would be

 

TIMEGRP <grp_of_pads_from_oneADC> OFFSET = IN 0.75ns VALID 1.5ns BEFORE <name_of_clk_for ADC> RISING;

TIMEGRP <grp_of_pads_from_oneADC> OFFSET = IN 0.75ns VALID 1.5ns BEFORE <name_of_clk_for ADC> FALLING;

 

To capture this, we need 13 taps of the IDELAY on the data, which adds +/-65ps of data dependent jitter. Hmmm... This may not quite work, since the closest IDELAY tap may be off by 78ps, and this +/-65ps, your window is now too small... (but just by a tiny bit). You should run this through the timing engine and see what it gives...

 

Avrum

 

 

Highlighted
Adventurer
Adventurer
22,958 Views
Registered: ‎06-30-2013

 

Hi Avrum:

 

Thank you very much for your detailed reply and help.

 

You have provided me with lots of good information that I need to study and digest fully.  I did want to clarify that the target device is the Zynq7020 with Artix fabric.  Does that affect any of the guidance you suggested?

 

I am surprised that the FAE from 4DSP told me I could use a single ADC channel clock to capture data fromm all four ADCs - maybe I did not ask my question correctly?

 

I did add in similar set of  OFFSET constraints for each of the four ADC channels but with different timing values after my original post and I have include them below.  For a 10ns sampling period, isn't the goal to have data valid slightly before and after the rising or  falling edges?  I thought my target was at 5ns so I used the following constraints but apparently I am not understanding this either.  Can you clarify the use of the "OFFSET" requirement in this case?

 

 

## constrain clock derived taken from the CLK_AB from the FMC104 ## we assume that CLK_AB=CLK_CD=CLK_EF= CLK_GH NET "system_I/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/clk_AB_IN" TNM_NET= "CLK_FMC_AB" ; TIMESPEC "TS_CLK_FMC_AB" = PERIOD "CLK_FMC_AB" 10 ns HIGH 50 %;

 

INST "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/ch_a_adc_ddr[*]" TNM = "adc_data_a"; TIMEGRP "adc_data_a" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB RISING ; TIMEGRP "adc_data_a" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB FALLING ; INST "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/ch_c_adc_ddr[*]" TNM = "adc_data_c"; TIMEGRP "adc_data_c" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB RISING ; TIMEGRP "adc_data_c" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB FALLING ; INST "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/ch_e_adc_ddr[*]" TNM = "adc_data_e"; TIMEGRP "adc_data_e" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB RISING ; TIMEGRP "adc_data_e" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB FALLING ; INST "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/ch_g_adc_ddr[*]" TNM = "adc_data_g"; TIMEGRP "adc_data_g" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB RISING ; TIMEGRP "adc_data_g" OFFSET = IN -0.5 ns VALID 5.5 ns BEFORE CLK_FMC_AB FALLING ;

 

 

 

My attempt did not work but I noticed that I did get valid data on some power cycles and not on others.    But when the Zedboard and FMC104 hardware powered up with valid ADC data it seemed to be valid and reliable.  To be clear, my implementation timing score was 0 but I guess that is meaningless if the constraints are not actually getting the data window aligned properly. 

 

The results still puzzle me though because it appears that some clock-to-data phase relationship is not consistent across power cycles?  Could this behavior be a symptom of incorrect constraints or the lack of chip-sync and IDELAY elements?

I am suspicious of the PLL on the FMC104 that generates the supposedly stable, low jitter and phase aligned input clocks to each ADC.

 

So before I implement the IDELAY implements if they are necessary, I just want to be clear that there is no way to implement chip-sync for each channel without IDELAYs?  Even though the data and clock leaving the individual ADCs are aligned properly and PCB routing is matched?   Are your statement below the answer to my question and if so, is there a difference with the Artix fabric?

 

Looking at the Kintex-7 datasheet in a -1 part, the device needs Tpscs/Tphcs of -0.34/1.73, which means a capture window of [0.34,1.73]; this is a 1.39s window. Your data has a valid window of [-0.75,0.75], so the two windows don't line up. Now you have to decide how to capture this. Do we push the data forward into the devices required window (by adding delay to the data), or push the clock forward to push the required window into the next data window (by adding delay to the clock).

 

Also, I do not need to correlate individual data samples from the four ADC channels but I do need to correlate groups of integrated ADC samples from the four channels.

 

I believe that my processing accomplishes this task but I am open for critique.  In each of the four ADC processing channels, I independently integrate ADC channel using the same clock that was used to clock the IDDRs.  I did use a common CLK_AB but I could use each individual channel clocks as you suggest.  The key is that I am effectively decimating the high speed ADC data so that each channel's integrated result along with associated data_valid strobe is used to cross over into a common PS clock domain using multiple registration of  the data_valid strobe signal and leading edge detection in the new domain.  I believe this works because the integrated data effectively appears static since it is latched with the strobe in its own clock domain.  The new delayed strobe in the PS domain is then used to grab that data since there is time while then next group of ADC samples is being integrated.   Does this seem sound?

 

I will continue to study your response and links in preparation of making the suggested modifications.

 

Thank you for your continued support and education -- it is greatly appreciated!

 

Best,

 

Craig

0 Kudos
Highlighted
Adventurer
Adventurer
22,951 Views
Registered: ‎06-30-2013

HI Avrum:

 

I did look at the post to which your referred me to for IDELAY inclusion and set-up but I did not see any detailed help.  There was mention of IDELAYs and the associated jitter penalty per tap when applied to the data signal but I have never used these elements and require more guidance.  Did I just miss the key section?  I apologize if I did but would appreciate it if you could clarify IDELAY instantiation and adjustment best practice.

 

Thanks again,

 

Craig

0 Kudos
Highlighted
Adventurer
Adventurer
22,946 Views
Registered: ‎06-30-2013

 

Hi Avrum:

 

After more research I made an attempt at implementing groups of IDELAY elements in the data path between the IO differential buffers and the IDDR inputs.  Here is a sample of the first of four channel instantiations.  BTW, I am using ISE14.6/PlanAhead and XPS as my tool set.

 

gen_cha_idelay : for ireg in (((num_adc_bits - 2)/2)-1) downto 0 generate
begin
 IDELAYE2_inst : IDELAYE2
   generic map (
      CINVCTRL_SEL => "FALSE",          -- Enable dynamic clock inversion (FALSE, TRUE)
      DELAY_src=> "IDATAIN",           -- Delay input (IDATAIN, DATAIN)
      HIGH_PERFORMANCE_MODE => "TRUE", -- Reduced jitter ("TRUE"), Reduced power ("FALSE")
      IDELAY_TYPE => "FIXED",           -- FIXED, VARIABLE, VAR_LOAD, VAR_LOAD_PIPE
      IDELAY_VALUE => 13,                -- Input delay tap setting (0-31)
      PIPE_SEL => "FALSE",              -- Select pipelined mode, FALSE, TRUE
      REFCLK_FREQUENCY => 200.0,        -- IDELAYCTRL clock input frequency in MHz (190.0-210.0, 290.0-310.0).
      SIGNAL_PATTERN => "DATA"          -- DATA, CLOCK input signal
   )
   port map (
      CNTVALUEOUT => open, -- 5-bit output: Counter value output
      DATAOUT => ch_a_adc_ddr_delayed(ireg),         -- 1-bit output: Delayed data output to IDDR flops
      C => CLK_AB_IDDR,                     -- 1-bit input: Clock input
      CE => '0',                   -- 1-bit input: Active high enable increment/decrement input
      CINVCTRL => '0',       -- 1-bit input: Dynamic clock inversion input
      CNTVALUEIN => (others => '0'),   -- 5-bit input: Counter value input
      DATAIN => '0',   -- 1-bit input: Internal delay data input
      IDATAIN => ch_a_adc_ddr(ireg),         -- 1-bit input: Data input from the I/O from differential I/O buffers
      INC => '0',                 -- 1-bit input: Increment / Decrement tap delay input
      LD => '0',                   -- 1-bit input: Load IDELAY_VALUE input
      LDPIPEEN => '0',       -- 1-bit input: Enable PIPELINE register to load data input
      REGRST => '0'            -- 1-bit input: Active-high reset tap-delay input
   );
end generate;

 

However, I am not sure I fully understand how to use these elements.  It appears as though most of the control inputs are not required when operating in the fixed mode with a tap value of 13.  So I am only supplying the DDR input bus from the IO diff buffers on the IDATAIN ports and taking the delayed signals from the DATAOUT ports.

I am using the same clock from the BUFIO that feeds the IDDR but should it be taken from the BUFR?

 

I only instantiated one IDELAYCTL in my design but I am not sure if this is correct?  It appears that this is a stand-alone control element and does not actually communicate with the IDELAY elements?  Is this true.  Since my clock capable inputs and DDR data busses are in IO Banks 34 and 35 do I need two of these or four of these?  Does it matter which clock I supply to the IDELAYCTRL?  Again, I chose the same clock used by the IDDR elements.

 

  IDELAYCTRL_0 : IDELAYCTRL
   port map (
      RDY => open,       -- 1-bit output: Ready output
      REFCLK => CLK_AB_IDDR, -- 1-bit input: Reference clock input
      RST => reset        -- 1-bit input: Active high reset input
   );

 

Thank you for your continued support and patience.

 

Craig

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
22,941 Views
Registered: ‎07-16-2008

One method of using IDELAYCTRL is to instantiate one unconstrained IDELAYCTRL. It's replicated to all clock regions and then, after placement, the unused IDELAYCTRLs are optimized away from the clock regions where they were not needed.

 

You can generate an example design from Coregen "SelectIO Wizard" IP and see how the IDELAY & IDELAYCTRL are instantiated.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Guide
Guide
22,939 Views
Registered: ‎01-23-2009

The IDELAY goes right after the input buffer.

 

CLOCK:

 

IBUFGDS.O -> IDELAY.IDATAIN -> IDELAY.DATAOUT -> BUFIO.I -> IDDR.C

                                                                               -> BUFR.I  -> Clock ports of other logic

 

DATA&colon;

 

IBUFDS.O -> IDELAY.IDATAIN -> IDELAY.DATAOUT -> IDDR.D

 

Since you are using the IDDR in FIXED mode, the C, CE, CINVCTRL, CNTVALUEIN, INC, LD, LDPIPEEN, and REGRST values are all irrelevent - tie them all to ground. The CNTVALUEOUT is irrelevent, leave it open

 

Since you are using it as a real input delay, DATAIN is also ittelevent, tie it to 0.

 

The SIGNAL_PATTERN on the IDELAY for the clock should be set to CLOCK and on the IDELAY for the data should be set to DATA. This is mostly just for simulation and timing analysis so that it knows whether to put the +-5ps/tap error in. All other parameters look OK.

 

The IDELAY_VALUE should be set to 13 for the IDELAY for data, and 0 for the IDELAY for clock. It is important to have the 0 tap IDELAY in the clock path to balance out the routing of the data going through the IDELAY on the way from the IBUFDS to the IDDR.

 

Note the REFCLK_FREQUENCY is 200.0MHz. This is important.

 

The way the IDELAY works is that it has a bunch of calibrated taps - 32 of them. These taps are calibrated by a reference clock - basically, the IDELAYCTRL is given a reference clock which it uses to calibrate all the taps of all the IDELAYs in the bank. This reference clock must be 200MHz (+/-5%, I think), except in a -3 speed grade where you can choose to use 300MHz (+/-5%). So, unless you are using a -3 part, you need to set the REFCLK_FREQUENCY to 200.00 and you need to feed the IDELAYCTRL with a 200MHz clock.

 

This 200MHz clock can come from anywhere in your system, but it needs to be continuous, relatively clean clock. It doesn't have to have anything at all to do with your actual interface - if you have an independent 200MHz oscillator on the board, use that. If you don't have one, then take any "real" clock on your system, and run it through an MMCM to generate a 200MHz clock. Then feed that to an IDELAYCTRL.

 

As was pointed out by others, the easiest thing to do is to just instantiate one IDELAYCTRL that is fed by a 200MHz clock. The 200MHz clock should be on a BUFG so that it can reach all banks, since the tools will automatically replicate the IDELAYCTRL into all banks that use an IDELAY.

 

From the port list, you are right - the IDELAYCTRL does not communicate with the IDELAYs. However, it really does, but this communication is actually an analog communication; the IDELAYCTRL is changing the biasing of the tap elements in the analog domain in order to calibrate them. Since it is in the analog domain, the "connection" between them is not represented in the port list.

 

Avrum

0 Kudos
Highlighted
Guide
Guide
22,935 Views
Registered: ‎01-23-2009

First,

 

You need to clarify exactly what sampling rate you are running at - I assumed 210Msps, but now I think you are only trying to do 100Msps. This makes a huge difference.

 

At this lower rate, the data eye is MUCH wider - the data sheet shows 2ns setup and 2ns hold (for a 4ns window). With a 4ns window you might be able to pay the +/-500ps Tdelay SKEW and sample all four channels with the same clock.

 

Whichever way you go, you always need input constraints. The constraints tell the tool exactly when the data at the pin of the FPGA becomes valid and stays valid. This is determined entirely by the device you are talking to. In this case (assuming the 100MHz sampling), the datasheet of the ADC tells us that the data becomes valid 2ns before the edge of the clock and remains valid for 2ns after the edge of the clock. This directly translates to

 

TIMEGRP <data_pads> OFFSET = IN 2ns VALID 4ns BEFORE <clk> RISING;

TIMEGRP <data_pads> OFFSET = IN 2ns VALID 4ns BEFORE <clk> FALLING;

 

If you have each of the channels clocked by its own clock, then the above is correct. If you choose to clock all four channels with a single clock, then the 3 channels that are not using their own clock pay a penalty - this gets reflected in the OFFSET IN constraint - we lose 500ps of setup and 500ps of hold (for the clock skew).

 

TIMEGRP <data_pads> OFFSET = IN 1.5ns VALID 3ns BEFORE <clk> RISING;

TIMEGRP <data_pads> OFFSET = IN 1.5ns VALID 3ns BEFORE <clk> FALLING;

 

Now the tool know when the data is valid. It can compare this against the internal requirements based on the structure of the clocking (IBUFDS -> IDELAY -> BUFIO -> IDDR) and I/O (IBUFDS -> IDELAY -> IDDR), including the IDELAY_VALUE for both, and ultimately tell you if the design will work or fail.

 

Avrum

Highlighted
Adventurer
Adventurer
20,657 Views
Registered: ‎06-30-2013

Hi Avrum:

 

I now understand the confusion over the sampling rate and the feasibility of supporting all four ADC channels from a single clock.  Maybe this is why the FAE at 4DSP thought it was possible.  However, my intention was to be able to support sampling rates up to the maximum of 250MSps.  But if the IDELAY taps are fixed for a particular data window that is a function of sampling rate then it seems that I would not be able toy support a variable sampling rate.  Is this true and if so, is the solution to dynamically adjust the IDELAY values for the data busses as a function of sampling rate?

 

Ok, I now see that I need to generate a 200Mhz clock so I can use an MMCM to synthesize this from my PS side 100MHz clock.  It is true that I initially have set the ADC sampling clock to 100MHz and I realize the data window is mush wider.  However, my intent is to support sampling rates all the way up to 250MSps. 

 

Thanks for clarifying the clock and data flow and the need to include an IDELAY in the clock path even though it has a zero tap delay.

 

In my initial designs, I was feeding the IDDR elements directly from the IBUFDS.  Why is the BUFIO always  required to drive the IDDRs?

 

 

Thank you,

 

Craig

0 Kudos
Highlighted
Guide
Guide
20,655 Views
Registered: ‎01-23-2009

The BUFIO is the input to the I/O clock network. This is a dedicated network for driving the the clock inputs of the IDDR (and IOB FFs and ISERDES) in the IOBs of one bank. There are 4 I/O clock networks in each bank, each one is driven bu one BUFIO. Each BUFIO can be driven by one of the clock capable I/Os in the bank, or the BUFMR (which can bring a clock from a clock capable I/O in an adjacent bank), or from the "High Performance Path" from the MMCM in the same clock region (from CLKOUT0-3).

 

If you don't instantiate the BUFIO on the clock path, its not clear how the tool will route the clock from the IBUFGDS to the clock input of the IDDRs. It might try and do it using fabric routing, which you must avoid at all costs! It is also possible (but I don't know if this is the case), that the tool will infer the BUFIO if you don't instantiate it (since it is the only reasonable way to get from the IBUFGDS to the clock inputs of the IDDRs), but I wouldn't count on it. You should always instantiate the clock buffer...

 

Avrum

0 Kudos
Highlighted
Guide
Guide
20,654 Views
Registered: ‎01-23-2009

Since the data setup/hold window is always centered around the clock, I think the same IDELAY value will be correct for all sampling rates. The 13 taps of delay places the "center" of the data eye in the center of the required sampling window. As you go to faster clock rates, the data eye will get narrower, but still stays centered around the clock. Hence your margins will go down, but the IDELAY shouldn't need to be adjusted.

 

Eventually, though, when the sampling rate gets high enough, the data valid window will become too small for accurate capture. If I am reading the ADC spec right, at 250MSps the data setup/hold becomes 0.55ns/0.55ns for a total window of 1.10ns. This is too small to sample statically. But you should be able to get close to, or even slightly above 200MSps and still have a reliable capture - even in an Artix-7 fabric.

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
20,647 Views
Registered: ‎06-30-2013

Hi Avrum:

 

Once again your explanations are masterful and have clarified my initially fragmented underrtsanding of the fabric resources.  I now see how the data window will remain centered independent of samplig rate but the valid window will become too small for reliable capture at the fastedst sampling rates.  So I initially will try and keep the timing for 210MSPs but operate at a 100MHz sampling rate. I would think that would just give me lots of extra margin if the tool can meet timing.

 

I implementd everything you suggested, not withstanding that my VHDL or UCF constraints may still be not correct, and I get into MAP and see the following MAP error for all four ADC channels.  I have to believe that my implemenation is not correct.  Before I added in the IDELAY elements, BUFIOs, BUFRs and new CLK_200M, I never saw these errors.  Looking around at other posts, I tried setting the "Ignore keep hierarchy" in MAP but that did not help.  Any ideas as to what I have done wrong?

 

 

  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chc_sdr[2].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chg_sdr[6].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_che_sdr[4].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_cha_sdr[0].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_cha_sdr[5].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_che_sdr[1].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chc_sdr[3].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chg_sdr[3].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_che_sdr[5].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_cha_sdr[1].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_cha_sdr[6].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chg_sdr[0].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_che_sdr[2].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chc_sdr[4].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_cha_sdr[2].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chc_sdr[0].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chg_sdr[4].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_che_sdr[6].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_cha_sdr[3].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chc_sdr[5].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chg_sdr[1].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chc_sdr[1].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chg_sdr[5].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_che_sdr[3].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chc_sdr[6].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_chg_sdr[2].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_cha_sdr[4].IDDR_inst" failed to join an ILOGIC component as required.
  • [Pack 2529] The dual data rate register "system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/gen_che_sdr[0].IDDR_inst" failed to join an ILOGIC component as required.
0 Kudos
Highlighted
Guide
Guide
20,636 Views
Registered: ‎01-23-2009
From the message, I would guess that there is something wrong with the VHDL. The interconnections between the IBUFDS, IDELAY, and IDDR is very specific, and if you get them incorrect, then the tools will not be able to merge them together.

I would check these connections, referring to the user guide which outlines what can be connected to what. You could also post your code so that we can see if we can spot what's wrong with it.

Avrum
0 Kudos
Highlighted
Adventurer
Adventurer
20,634 Views
Registered: ‎06-30-2013

Hi Avrum:

 

Yes, I am embarassed to admit that I had erroneously included BUFIOs in the IDELAY-to-IDDR path which was definitely a big mistake.  With that problem fixed, I am now facing some new errors related tot he IDELAYCTRL and banks  but need to dig in and see if I can solve on my own.

 

No doubt these are also VHDL/fabric connecton related.

 

I hope I can get this solved early tomorrow as I am anxious to see how the new design performs.

 

Thanks,

 

Craig

0 Kudos
Highlighted
Adventurer
Adventurer
20,627 Views
Registered: ‎06-30-2013

Hi Avrum:

 

I continue to struggle with implemenation of the chip-sync interface as I undersand it.  In order to aid this debug, I have attached the UCF file derived from the original ZedBoard constraint file, the key VHDL module and the MAP report.

 

I also noticed that during MAP I got critcial warnings that the tool could not find key clock nets driven by the BUFIOs for the IDDR clocks. This does not make sence to me.  For example, the tool says it can't find net CLK_AB_IDDR - is this possily becasue I have the clock PERIOD constraint tied to the output of the differential input clock buffer?

 

 

 

But the actual error is:

 

ERROR:Place:906 - Components driven by IO clock net
   <system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/CLK_EF_IDDR>
   can't be placed and routed because location constraints are causing the clock
   region rules to be violated. IO Clock net
   <system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/CLK_EF_IDDR>
   is being driven by BUFIO
   <system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/BUFIO_E>
   locked to site "BUFIO_X1Y9" Because of this location contraint,
   <system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/CLK_EF_IDDR>
   can only drive clock region "CLOCKREGION_X1Y2". The following components
   driven by
   <system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/CLK_EF_IDDR>
   have been locked to sites outside of these clock regions:
   system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/ch_e_adc_sdr[6]
   (Locked Site: ILOGIC_X1Y82 CLOCKREGION_X1Y1)
   system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/ch_e_adc_sdr[6]
   (Locked Site: ILOGIC_X1Y82 CLOCKREGION_X1Y1)
   Please evaluate the location constraints of both the BUFIO and the components
   driven by
   <system_i/zed_panther_0/zed_panther_0/zed_top_0/sig_proc_top_0/CLK_EF_IDDR>
   to ensure that they follow the clock region rules of the architecture. For
   more information on the clock region rules, please refer to the architecture
   user's guide. To debug your design with partially routed design, please allow
   mapper/placer to finish the execution (by setting environment variable
   XIL_PAR_DEBUG_IOCLKPLACER to 1).

 

I do not understand why the error refers to location constraints - I did not specifically add location constraints.   Also, why is this error only for the third ADC channel E and not the other ADC channels A. C, or G?  My understanding is that the FMC site is mapped so that IO Bank 34 handles channel A and C and IO Bank 35 handles channel E and G.

 

Perhaps the significance of the other WARNINGS is more critical than I realize?

 

Thanks for your continued support and patience...

 

Craig

0 Kudos
Highlighted
Adventurer
Adventurer
20,622 Views
Registered: ‎06-30-2013

HI Avrum:

 

I used a conditional generate block to remove the entire section of Channel E processing;  I was able to get through MAP.  Not sure if I have an error in my VHDL or UCF file or if the location of the channel E DDR data and clock sites lead to a MAP issue?

 

Craig

0 Kudos
Highlighted
Guide
Guide
20,620 Views
Registered: ‎01-23-2009

This looks like a bug on the Zedboard or ADC FMC card!

 

Looking at your channel E, the clock is on pin B19, which is one of the multi-region clock capable pins in I/O bank#35.

 

If you look at the 7 data pins associated with that channel, they are pins G15, G20, E19, G19, E15 and F18, which are all also in bank#35, but also J20, which is in bank #34!

 

It is correct that the BUFIO in bank #35 cannot reach the IOB in bank #34 (directly). So the error message is correct!

 

So, we need to understand if this is really the case. You need to check that the signal CHE_P[3] (which presumably ends up generating ch_e_adc_sdr[6]) really on pin J20, and is supposed to be clocked by the clock on pin B19.

 

If there are no mistakes in the UCF file, then this really won't work (as is).

 

If you need to accommodate this, then you will be forced to use the BUFMR. The clock on B19 is an MRCC clock (as opposed to a SRCC clock) - it is Multi-Region Clock Capable. That means that in addition to driving the BUFIO and BUFR in the same region it can instead drive the BUFMR in that region. The BUFMR can then drive the BUFIO and BUFR in the same region as the BUFMR, as well as the BUFIO and BUFR in the regions above and below. This will make the routing legal (since bank 34 is immediately above bank 35).

 

So, the IBUFGDS for the clock would connect to the .I port of the BUFMR. The .O port of the BUFMR would connect to TWO BUFIOs and TWO BUFRs. One of the BUFIO and BUFR sets would be used for all the pins in bank 35 (all but CHE_P[3]) and the other BUFIO/BUFR set would clock only CHE_P[3].

 

However, there is a performance penalty to pay in doing this. I don't know how much it is (trce will tell you) but its probably around 100ps (or maybe more) - this is going to come direcly out of your budget and hence reduce the maximum sample rate you can handle.

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
20,616 Views
Registered: ‎06-30-2013

Hi Avrum:

 

The UCF file and the actual pin connections are correct.  Unfortunately, the 4th DDR signal for ADC channel E WAS routed into bank 34 instead of bank 35 where the remaining clock and channel signals are connected.  Not sure which party missed the boat here but I did not catch this when I first built the UCF.  There were other pairs available in bank 35 handle this CHE signal.

 

So, it looks like I will have to use the BUFMR as you suggest and live with the timing hit.  Does the tool automaticaly figure out that the second set of BUFIO and BUFR in bank 34 is used for the single IDDR for CHE_03 or do I have to tell it to use them?

 

However, even when I remove both channels E and G from the design, although I get through MAP, I am failing in the Processor Subsystem clock domain.  Before I began using chip-sync, I did not have any timing errors in tis domain. Is this related to the added regional clock buffers?  What other problems with my design do you suspect?

 

Best,

 

Craig

 

----------------------------------------------------------------------------------------------------------
  Constraint                                                                |    Check    | Worst Case |  Best Case | Timing |   Timing  
                                                                                             |             |    Slack   | Achievable | Errors |    Score  
----------------------------------------------------------------------------------------------------------
* TS_clk_fpga_0 = PERIOD TIMEGRP "clk_fpga_ | SETUP       |     0.138ns      |     9.862ns|       0|           0
  0" 100 MHz HIGH 50%                                           | HOLD        |    -0.188ns           |            |      62|        3432

 

 

 

 

 

0 Kudos
Highlighted
Guide
Guide
13,961 Views
Registered: ‎01-23-2009

The tools will not automatically replicate BUFIOs and BUFRs - as I mentioned in the last e-mail, you will need to manually instantiate both sets and connect one set to the pins in bank 35 and the other set to the pin in bank 34.

 

As for the timing error, I need to see the detailed timing report.

 

One thing you need to be aware of is that you can't always find "causality" in a timing failure. Every time you do place and route after changing your design or constraints in any way, you will end up with a different result. Sometimes these runs won't meet timing - its not "because you added chip-sync timing" but "because something changed".

 

So, it could be either. It is possible that this has something to do with clock crossing between the BUFR and BUFG domains (which is why I need to see the full report), or it could just be the unpredictability of timing results.

 

Avrum

Actually I do need these latches in my design. I was using state machines, so there is a process only driven by current statement rather than clock signal. So there are some latches in my design.  Is this a problem?

0 Kudos
Highlighted
Adventurer
Adventurer
13,955 Views
Registered: ‎06-30-2013

Hi Avrum:

 

I have removed all of the clocking/logic associated with the channles E and G in my design to avoid the banking issue with the ADC_ch_E(3) signal and to reduce total logic resources. 

 

 

Even with this, I am failing in PAR with errors in the following clock domain:

 

'system_i/processing_system7_0/processing_system7_0/FCLK_CLK_unbuffered<0>'

 

I never had this problem before when I was using the single CLK_AB without the I/O and regional clock buffers.

 

I have attached the synthesis and PAR reports but the ststis timing or TRCE report does not seem to be available.  I think this is becasue of the PAR failure.  Is this true or is this my cockpit error?  How to I instruct PlanAhead to produce a static timing report even when PAR fails?

 

Whys is the clock from the processing subsystem referred to as "unbuffered"?  i think I saw a global clock buffer in the schematic view.

 

Thanks,

 

Craig

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
13,948 Views
Registered: ‎06-30-2013

Hi Avrum:

 

I am able to run a "Report Timing" option but I have not figured out if I can run the TRCE.  It appears to not be valid and I wonder if this is caused by the fact that PAR failed?

 

I attached a screen shot of the window that shows the top 10 failing paths and they are in the area of the AXI crossbar switch.  As I said earlier, I never saw this problem on numerous routes in this processor clock domain.

 

I have been trying to study UG472_7Series_Clocking but still do not appreciate what the reason or benefit is from having or using BUFR  or BUFH when the BUFG is claimed to reach anywhere in the chip?  I am not understanding when each type of buffer is most advantageous.

 

In my previous work with Spartan3, and Virtex 4 I was using single-clock designs or I was using DDR supported by the MIG tool so I never had to deal with the complexities of multiple clocks and clock regions.  I always had thought that once a clock signal was on a global clock path it could reach anywhere in the chip with minimum delay.

 

In this design, becasue my ADC clocks are fed on pins that are "clock capable" and not global clock inputs I think I understand how I need to use the special IO and regional buffers becasue the clocks cannot directly feed the global clock lines.  Is this correct?

 

I am trying to understand if the latest PAR errors in timing are just manifesting themselves becasue of the change in MAP of the modified design or becasue I am still fundamentally not handling the buffering of the PS based clock correctly?

 

Thanks,

 

Craig

 

 

 

 

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
13,946 Views
Registered: ‎06-30-2013

Hi Avrum:

 

When I look at some of the individual paths that fail in the AXI interface with the datamovers, I see that there are about 11 logic levels and the data delay is exceeding the clock period plus its delay by several ns.

 

What tools or options are at my disposal to deal with this problem assuming it is not related to clock distribution?

 

From my past experience, although limited, I was able to add registration in paths that had too many combinatorial logic levels but this was typically in HDL that I had written.  I think these paths are in the Xilinx IP so not sure how to deal with it.  Maybe I am wrong here and am missing something?

 

The other detail that I found from looking at the details fo the failing paths is that the desitination clock path includes the BUFG input and output so I think it is being properly buffered.  The problem is the logic delay casued by all these levels.

 

Craig

0 Kudos
Highlighted
Guide
Guide
13,943 Views
Registered: ‎01-23-2009

From the report you attached (the .par) there is no failure in PAR other than the fact that it failed to meet timing.

 

The static timing analysis should have been run, and would have the suffix .twr

 

Avrum

0 Kudos
Highlighted
Guide
Guide
13,942 Views
Registered: ‎01-23-2009

The timing report you attached is a post synthesis timing report, other than looking for truly gross timing violations, it is pretty much useless.

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
13,936 Views
Registered: ‎06-30-2013

Hi Avrum:

 

I cannot figure out how to get a static timing report generated.  What am I not doing correctly with the tool?  I have attached the portion of the Implementation settings that I thought were applicable.

 

When I look in the reports tab, the TRCE report is not available and after PAR fails, the option to run a TRCE report in the Tools menu is not available.  The only option I have as shown in the second screenshot is to "Report Timing".  I wrote out this report to a texdt file and  attached.   So this file appears to have the path details but I am confused why I can't get a TWR file directly.

 

Any thoughts on what I am doing or not doing to prevent the static timing report from being generated in PlanAhead 14.6?

 

More importantly, any insights into the failing paths and ways to decrease logic levels and/or delays?

 

Thank you,

Craig

0 Kudos
Highlighted
Adventurer
Adventurer
13,933 Views
Registered: ‎06-30-2013

Attached the screenshot file with the second screenshot that shows the Tool options available after PAR

0 Kudos
Highlighted
Guide
Guide
13,918 Views
Registered: ‎01-23-2009

I don't know why you are having trouble with getting the timing report, and I am confused by what you are telling me (since on one hand you are telling me that trce isn't running since the par "fails", but then you are sending me timing reports...)

 

As for why your design fails to meet timing it could be

  - your FPGA is now "fuller", and that is affecting timing

  - some parts of your logic are held near the pads where your ADC inputs come in, and your AXI busses are having to traverse longer distances to get there

 

But, I can't help you with these - these paths appear to be deep in the XPS generated stuff, and that's not really my expertise. You might want to start a different thread in the Embedded processor and System Design forum group.

 

Avrum

0 Kudos
Highlighted
Adventurer
Adventurer
13,915 Views
Registered: ‎06-30-2013

Hi Avrum:

 

I want to again thank you for all of your help and education.  I can't tell you how frustrating it is to learn how to use these tools.  I am asking my colleague to implement the design and see if he is able to run TRCE and generate a .TWR report on his platform. 

 

Like I said before, the only option I have under Tools | Report Timing is to write to a file so it does appear to give the failing paths.  Very confusing to me because the option for static timing and the TRCE is not available but the option for "Report Timing" is?????????

 

Once I get this issue solved, I may be posting additional timing related questions.

 

Best,

 

Craig

0 Kudos