cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
333 Views
Registered: ‎02-07-2020

Maximum operating frequency of ILA v6.1 on xc7a200tffg1156-3 (Artix 7) FPGA

Jump to solution

Hi,

What is the maximum operating frequency of ILA v6.1 implemented on an xc7a200tffg1156-3 (Artix 7) FPGA? Can it meet timing at a dbg clock frequency of 445MHz (period 2.247ns)?

I've managed to reduce the setup time slack quite a bit from what I had been getting initially by assigning the debug hub and ILA core to pblocks to move them away from the rest of the logic etc, simplifying the rest of the logic outside etc but finding it quite tough to reduce the slack below -1.2ns.

The failing timing paths are all INSIDE the ILA core itself. Have enabled ILA Pipelining etc, but doesn't seem to help much since the failing paths are inside the ILA core rather than outside.

Checked inside "Integrated Logic Analyzer v6.1 LogiCORE IP Product Guide" but couldn't really locate an absolute maximum operating frequency spec for this ILA core on a given FPGA.

Is it worth even attempting to meet timing for this target clock frequency for this particular FPGA model or is it a vain effort?

Thanks,

Anoop

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
319 Views
Registered: ‎06-21-2017

Re: Maximum operating frequency of ILA v6.1 on xc7a200tffg1156-3 (Artix 7) FPGA

Jump to solution

An Artix 7 -3 speedgrade BRAM can run at that frequency according to the data sheet, butyou are at the upper end of the range, so I suppose there is a chance.  Have you tried removing the trigger comparators from any probes that you are sure you don't want to use as a trigger.  A equality comparator may require several layers of logic and at this frequency, you can't afford many layers of logic.

View solution in original post

0 Kudos
5 Replies
Highlighted
320 Views
Registered: ‎06-21-2017

Re: Maximum operating frequency of ILA v6.1 on xc7a200tffg1156-3 (Artix 7) FPGA

Jump to solution

An Artix 7 -3 speedgrade BRAM can run at that frequency according to the data sheet, butyou are at the upper end of the range, so I suppose there is a chance.  Have you tried removing the trigger comparators from any probes that you are sure you don't want to use as a trigger.  A equality comparator may require several layers of logic and at this frequency, you can't afford many layers of logic.

View solution in original post

0 Kudos
Visitor
Visitor
279 Views
Registered: ‎02-07-2020

Re: Maximum operating frequency of ILA v6.1 on xc7a200tffg1156-3 (Artix 7) FPGA

Jump to solution

Hi Bruce,

Thanks for the reply. Yes, I had deliberately relaxed my dbg clock frequency to 445MHz from 500MHz using an MMCM (actually the 500MHz signal is the PCIe PIPE CLK, and I'm trying to monitor the PIPE interface signals here) specifically because of the BRAM Fmax spec for grade -3 defined at ~447MHz

Let me try out the approach you mentioned (removing the trigger comparators from signals that won't be used for triggering for sure) to reduce the requirement for levels of logic/fanout etc

Anyway, just pasting the summary as well as snapshot for a worst case failing path I got after trying out one of the synthesis/implementation strategy combos. The best I had gotten till now was a worst case slack of ~-1.3 (with a different synthesis/implementation strategy combo from what which was used for the case below). Clearly the levels of logic+the resulting routing delay to interconnect multiple LUTs is hitting me. Let me recheck after the approach mentioned above.

NamePath 1
Slack-1.889ns
Sourceu_ila_0/inst/ila_core_inst/u_ila_regs/U_XSDB_SLAVE/G_1PIPE_IFACE.s_den_r_reg/C   (rising edge-triggered cell FDRE clocked by ILA_CLK_forPIPEsignals_BUFG  {rise@0.000ns fall@1.124ns period=2.247ns})
Destinationu_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram/REGCEB   (rising edge-triggered cell RAMB36E1 clocked by ILA_CLK_forPIPEsignals_BUFG  {rise@0.000ns fall@1.124ns period=2.247ns})
Path GroupILA_CLK_forPIPEsignals_BUFG
Path TypeSetup (Max at Slow Process Corner)
Requirement2.247ns (ILA_CLK_forPIPEsignals_BUFG rise@2.247ns - ILA_CLK_forPIPEsignals_BUFG rise@0.000ns)
Data Path Delay3.829ns (logic 1.126ns (29.408%)  route 2.703ns (70.592%))
Logic Levels5  (LUT4=3 LUT6=2)
Clock Path Skew0.043ns
Clock Uncertainty0.112ns

Floorplan_snapshot_ILA+debughub.PNG

Thanks,

Anoop

0 Kudos
Highlighted
Visitor
Visitor
276 Views
Registered: ‎02-07-2020

Re: Maximum operating frequency of ILA v6.1 on xc7a200tffg1156-3 (Artix 7) FPGA

Jump to solution

Hi Bruce,

One doubt, by "removing the trigger comparators from any probes that you are sure you don't want to use as a trigger.", are you referring to setting the "probe type" as "data" for those signals that don't need to be used as triggers?

Thanks,

Anoop

0 Kudos
Highlighted
Visitor
Visitor
214 Views
Registered: ‎02-07-2020

Re: Maximum operating frequency of ILA v6.1 on xc7a200tffg1156-3 (Artix 7) FPGA

Jump to solution

Hi Bruce,

I checked with the approach you mentioned but looks like the timing actually got a bit worse (worst case slack became -1.8 from -1.6), but that's probably because the placement and routing process may have arrived at a sub optimal result. I do see that the amount of logic utilization has certainly come down. Let me play around a bit with the constraints and see if I can improve things with the newly modified trigger and data configurations

Thanks,

Anoop

0 Kudos
Highlighted
Visitor
Visitor
183 Views
Registered: ‎02-07-2020

Re: Maximum operating frequency of ILA v6.1 on xc7a200tffg1156-3 (Artix 7) FPGA

Jump to solution

Hi,

One update is that, I realized I had been using the same 445MHz clock that I had been using for the Debug Core Clock for the Debug Hub Clock as well. I changed the Debug Hub Clock to a separate 100MHz clock after which the load on the timing optimization side seems to have reduced and the timing slack on the setup time reduced considerably to <1ns etc. Still some way to go though

Thanks,

Anoop

0 Kudos