- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
20Mhz limitation for ICAP_SPART AN6
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-30-2012 04:00 AM
Hi
I just read the thread and doc about icap below:
and document : HWICAP IP (v5.01.a)
The document say : "3. In case of Spartan-6 the ICAP clock must be connected to 20 MHz."
I'm using ICAP (not HWICAP) on a PCI CARD design with 33Mhz clock.
In this design I need another PLL for this 20Mhz clock.
But the area consideration is not allow to add this PLL.
If there any consideration for this limitation like stability concern?
Could I use the clock lower than 20Mhz? Or there have any tolerence for this 20MHz
I have tried 13.5MHz and 16.666 Mhz clock source for ICAP_SPARTAN6 and they both work.
Those clock sources are divied from 33Hhz and 27Mhz OSC by divider like below:
always@(posedge sys_clk or negedge rst_n)
begin
if (~rst_n)
begin
clk_div <= 0;
end
else
begin
clk_div <= ~clk_div;
end
end
It seems okay now , but I'm not sure if it will still okay in the futrue.
Could you please tell me the concern of this limitation?
Thanks
Solved! Go to Solution.
Re: 20Mhz limitation for ICAP_SPART AN6
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-30-2012 07:45 AM
a,
For this IP core, any frequency below 20 MHz is just fine.
The ICAP primitive has some path delays to/from that may not meet timing if they are run at higher frequencies.
Generally speaking, if those paths are fast enough (by luck they were placed so that they the source/sink were close to each other), then the ICAp will run as fast as the fastest configuration clock specified in the datasheet.
The tools do not have the necessary timing information to make the right choices for the ICAP instatiation, and getting all the paths to meet the timing constraints. If the speed is important, you may use FPGA Editor to examine the placement, and the paths. If the longest delay on any path is short enough, then the frequency may be higher than 20 MHz.
Principal Engineer
Xilinx San Jose
Re: 20Mhz limitation for ICAP_SPART AN6
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-30-2012 07:03 PM
I got it, thanks for the reply.
"The tools do not have the necessary timing information to make the right choices for the ICAP instatiation" make me worry .If there any timing spec for this IP? like setupt time hold time etc...? I do found the constrain example in the document for reference:
The following MAXDELAY constraints are required in the UCF:
NET "xps_hwicap_0/xps_hwicap_0/HWICAP_CTRL_I/icap_stat
NET "xps_hwicap_0/xps_hwicap_0/HWICAP_CTRL_I/icap_stat
NET "xps_hwicap_0/xps_hwicap_0/HWICAP_CTRL_I/icap_stat
If those constraints for all FPGAs or just 100Mhz clock? what should they become in other device like Spartan6 ,3A and V5? As my understand ICAPs are different in different FPGA series like ICAP_SPARTAN6 or ICAP_SPARTAN3A etc...
Thanks again
Re: 20Mhz limitation for ICAP_SPART AN6
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-31-2012 07:28 AM
ICAP,
Is not what we call a "fully supported" block, in that the timing, as mentioned, isn't perfectly done, without either hand placement, and also having the constraints that are listed in the answer records.
That said, it gets fully tested, and characterized, so examination of the final placed and routed design is sufficient to guarantee proper operation. This is something that we continue to improve, and will get done properly at some point (with incremental improvements along the way).
I would not worry about it, but rather observe the recommended added constraints, and follow the datasheet numbers, and the IP clock rate suggestions. If you need it to work faster (some do), contact your local Xilinx FAE for assistance.
Principal Engineer
Xilinx San Jose











