Spartan 3 ICAP primitive

Xilinx what is correct in ISE 5.1 schematics editor the ICAP primitive doesnt show, but if looking at XDL output then ICAP primitive does exist ?!

I was very disappointed to see that Spartan 3 doesnt have ICAP (i.e. self reconfig) but it seems it is there?

antti

Reply to
Antti Lukats
Loading thread data ...

Spartan3 is basically a Virtex2, trimmed down in various ways. The internal logic is pretty much identical as far as I can gather (CLBs, IOBs etc).

So, physically there's probably an ICAP hiding in every Spartan3, it's just hidden by the tools. The philosophy seems to be that self-reconfiguration is still an experimental/research concept, and as such doesn't have a place in Spartan3, which Xilinx views and markets as a commodity FPGA.

Note also that Jbits now supports Virtex2, but don't hold your breath waiting for Jbits for Spartan3 - the same thinking probably applies.

Bitstream hacking could probably uncover the S3's ICAP - Virtex2 and Spartan3 bitstreams will likely have much in common.

Regards,

John

Reply to
John Williams

Looks like I have not done my homework on this. I had done some research on modular configuration which was what I required. The Spartan lines seem to be supported for this although they don't yet list the Spartan3 chips. But I was under the impression that partial configuration was the down load technique to support this in the devices. I see that only Virtex and Virtex-II are supported by partial configuration. This is not good.

What is up with this? I guess there may be other reasons to use partial configuration other than cost, but I would expect this to be the main driver. If I don't care about cost, I can just implement all of the possible configurations at the same time and mux the IOs. If I care about cost, I certainly don't want to be forced to use the Virtex or Virtex-II chips. The Spartan chips are all about cost.

So why the disconnect on partial configuration Xilinx? Why not support Spartan-3 devices?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

ICAP, or the Internal Configuration Access Port, is not supported in Spartan-3 FPGAs. Glimpses of the ICAP interface appear in various tools, either because it was too difficult to remove this function from the software, or the software mistakenly assumed that Spartan-3 had ICAP.

Dynamic reconfiguration is still supported in Spartan-3 via the external SelectMAP interface or JTAG, just not through the ICAP interface. The decision to remove it was due to silicon resource requirements and testing cost. Although dynamic reconfiguration is a powerful concept, few consumer-oriented applications use it.

The following is some background on partial reconfiguration in Spartan-3 and the ICAP primitive.

Does Spartan-3 Support Partial Reconfiguration?

Virtex/E, Virtex-II, and Virtex-II Pro devices - generically called Virtex throughout this article - support a feature called partial reconfiguration. Using this feature, an application can modify a portion of the bitstream programming inside an FPGA to change the FPGA's functionality. Spartan-3 FPGAs support some of these same capabilities, but with limitations compared to Virtex.

Via today's design software, partial bitstream changes must be performed on an entire IOB, CLB, or Block RAM column basis in both Virtex and Spartan-3 FPGAs. For example, to change a single bit within a single LUT, the application must update all the CLBs in the affected column. Any unmodified CLBs within the column are overwritten with the same configuration data.

Perhaps the most important difference between Virtex and Spartan-3 FPGAs is how the FPGA logic behaves during the reconfiguration process. In the Virtex devices, any unmodified bits in the affected column continue to operate normally. Consequently, if bits within a column are unchanged, then the surrounding logic continues to function normally. In Spartan-3 FPGAs, however, even unmodified bits in a column are temporarily reset during the reconfiguration process, which greatly complicates using partial reconfiguration. Partial reconfiguration works in Spartan-3 FPGAs, just with extra complications.

A column consists of multiple configuration frames. Physically, the Virtex hardware supports configuration changes at the frame level, but software currently just supports changes at the column level. The Spartan-3 hardware supports bitstream changes at the column level only.

The application can partially reconfigure the FPGA via a variety of means, including the parallel SelectMap configuration interface and the FPGA's JTAG port. Virtex-II and Virtex-II Pro families also support another means called the ICAP (Internal Configuration Access Port). The ICAP interface is similar to the parallel SelectMAP interface, but is available from within the FPGA. Although the Spartan-3 architecture is based on the Virtex-II and Virtex-II Pro architectures, the Spartan-3 family does not support the ICAP interface.

Table 1 summarizes how partial reconfiguration compares between families.

Table 1. Partial Reconfiguration Support in Virtex-II vs. Spartan-3.

Software supports... Virtex: Column-based reconfiguration Spartan-3: Column-based reconfiguration

Hardware supports... Virtex: Frame-based reconfiguration Spartan-3: Column-based reconfiguration

Unmodified logic remains active during reconfiguration? Virtex: Yes Spartan-3: No

Reconfigure via SelectMAP? Virtex: Yes Spartan-3: Yes

Reconfigure via JTAG? Virtex: Yes Spartan-3: Yes

Reconfigure via ICAP? Virtex: Virtex-II and Virtex-II Pro only Spartan-3: No

For more information on partial reconfiguration, visit the following web links:

Partial Reconfigurability Frequently Asked Questions

formatting link

XAPP151: Virtex Series Configuration Architecture User Guide

formatting link

XAPP290: Two Flows for Partial Reconfiguration: Module Based or Small Bit Manipulations

formatting link

--------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. Spartan-3/II/IIE FPGAs

formatting link

--------------------------------- Spartan-3: Make it Your ASIC

Reply to
Steven K. Knapp

Don't panic! the S3 still supports partial reconfiguration - the ICAP primitive that Antti and I were talking about is a block that allows the partial reconfigruration to be controlled from within the device itself ie. self-reconfiguration.

All the Virtex's and S3 can be partially reconfigured from *outside* the device, via SelectMap or slave serial or whatever, either partial or total reconfiguration.

As I said, it's just the ICAP (internal configuration access port), not the partial reconfig capability itself.

Regards,

John

>
--
Dr John Williams, Research Fellow,
Reconfigurable Computing, School of ITEE
 Click to see the full signature
Reply to
John Williams

Hi Steven,

I was not referring to tools! Tools dont show S3 ICAP! ICAP as primitive is visible when doing -report query with XDL e.g.

XDL -report 3s200

(tile 29 29 BR LR 9 (primitive_site RLL_X23Y0 RESERVED_LL internal 8 6) (primitive_site DCI3 DCI internal 13 -1) (primitive_site DCI4 DCI internal 13 -1) (primitive_site DCIRESET3 DCIRESET internal 1 -1) (primitive_site DCIRESET4 DCIRESET internal 1 -1) (primitive_site STARTUP STARTUP internal 3 -1) (primitive_site ICAP ICAP internal 20 -1) (primitive_site CAPTURE CAPTURE internal 2 -1) (primitive_site VCC_X24Y0 VCC internal 1 -1) )

this is report from Xilinx S3 database, so I assume tools have to use it when doing doing placement, routing and bitgen.

if the ICAP actually isnt there then xilinx S3 databases are wrong not the tools.

anyway its real sad news that S3 doesnt support ICAP. It meanst that NO XILINX FGPA in NON-BGA support ICAP. this means that NO XILINX FPGA (in NON-BGA) can compete with Atmel Cachelogic device AT40, AT94K (self reconfig).

if there have been no real world applications for self reconfig then well that doesnt mean that they would not come. It doesnt mean that they would make much sense on Spartan 3 - larger S3 have actually more resources than V2 - so partial reconfig and self reconfig would make sense.

for me this is sad news.

I am planning a small litte thing an Pascal-Programmable FPGA it executes the original (modified version from N. Wirth's) Pascal-S pseudocode directly (most single cycle). The idea was to put the Pascal-S engine on one side, and let the other part of FPGA to be user configurable (from Pascal program). If S3 doesnt have ICAP, I can still achieve the goal by inserting an array of MPGA (Meta FPGA) cells as user FPGA, but allows way less resources to be used. Sure it using MPGA would allow full toolchain without using any xilinx software or tools.

a web-based (SVG + javascript) MPGA - Editor is already work in progress

formatting link
(project to be moved to
formatting link
soon) its only local interconnect view and no editor bounded yet.

antti

Reply to
Antti Lukats

I am still in panic mode. I started digging and found that the Spartan

3 devices are not suitable for modular configuration. Seems the tbuf is one of the features in the V2 devices that has been taken out for "optimization" in the S3. The tbuf is required for signals that traverse modules.

I have exchanged a couple of emails with Xilinx on this and am waiting for the final word. But it is looking like the Sparan 3 devices will not be able to do what I need in any defined timeframe.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Given your observation, plus the info provided by Steve Knapp from Xilinx in an earlier post (cell behaviour during partial reconfig) it seems that partial reconfig in S3 devices is not encouraged.

So it seems.

Regards,

John

Reply to
John Williams

I am working on a consumer product development. We have decided to use the Spartan 3 FPGA. But to keep the cost down, we want to use a very small PROM on the board. How could I program the Spartan 3 FPGA with a tiny PROM?

I was thinking of creating a compressed bitstream for the small processor interface logic that will take hardly 5 to 10% of the slices(that should lead to good compression ratios so as to fit in a tiny PROM) and then use this logic to self configure the new bitstream file from the processor interface and the FPGA having an external interface to talk to itself using selectMAP port (since Spartan 3 does not have any ICAP module).

But I have many questions:

  1. First of all, does Spartan 3 at all support self/dynamic reconfiguation as my microprocessor interface inside the FPGA has to keep working to configure the FPGA? So Spartan3 partial reconfiguration should not affect my functionality.
  2. I know there is a option called compressed bitstream. Is it possible to use compressed bitstream from the PROM at the powerup? I did not notice any decompression engine in the spart3 documentation. I need to use the compressed bitstream at the startup because I want to use the small PROM, but the partial reconfiguraton requires that very first configuration should be of full bit stream. So I need to have a tiny bitstream that can be loaded in the PROM, and used by the Spartan3 for the first time configuration.

Thank you ~Naveen

Reply to
video1

Hi Steven, I am using Spartan 3 in a product development. I had one question. It is said that Spartan3 supports partial reconfiguration though it does not have ICAP module. My questions are

  1. Does Spartan 3 support active partial reconfiguration? I want to put a tiny CPU interface in the FPGA first, and then use this CPU inside the FPGA to reconfigure itself using the selectMap interface.
  2. This question is useful only if Spartan 3 allows itself to configure itself. I will use master/slave serial mode to configure the FPGA with the CPU interface so the mode pins will have the corresponding settings. But but to reconfigure the FPGA from inside the FPGA I need to talk to selectMap interface..what happens to mode pins....or when I can use selectMap for active reconfiguration anytime independent of the mode and init pins.

Thank you ~Naveen

Reply to
video1

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.