Hello, Does somebody know if the last version of JBits (3.0) will work with spartans family? I know JBits 3.0 supports Virtex II, and an older version supported Virtex... but .. Spartan is kind of a Virtex.. so .. have anyone try this before?
Question for Xilinx: with JBits now DOA, how are customers supposed to use the ICAPs? Are they now strictly intended for "swapping" a set of prebuilt configurations? Without something like JBits you can't really do runtime template assembly AFAICT...
I wrote my own mail server and it still has a few bugs.
If you send me a message and it bounces, please forward the
Is this true? JBits support for V2 was announced just a few months ago.
Your question has a false premise - customers *aren't* supposed to use ICAP. :-S ... OK so I'm joking, but only just...
ICAP is there because it helps Xilinx test chips. They make it visible in the tools etc because it has some interesting research opportunities.
It's a bit of a chicken and egg problem - if someone can demonstrate a killer-app for ICAP and partial-reconfig, then support will follow. But without support, developing the killer-app is very difficult...
Xilinx had a lot of new tool features they were supporting such as modular configuration. I was told that they were commited to supporting the Spartan 3 devices. But that support never materialized and I dont' see where the new V4 chips are supported yet. Maybe they just don't see much need and are dropping some of these advanced tools on the newer chips. Or maybe it is the lack of tri-state buffers. I know the Spartan 3 chips have none, do the Virtex 4 chips have any internal tri-states?
Rick "rickman" Collins
I think the problem is probably in the underlying wire database (NCD) that the current-gen tools use. Using constraints for modular/partial flow is not ideal. Better would be to have a database that has the equivalent of the SQL "view" construct - create a virtual device that is some spatial subset of the full device, with full P&R capability over that subset. Of course I'm not saying it's easy!
I'm speculating again, but I think the whole tri-state/bus macro thing is a bit of a red-herring - it's just the easiest, guaranteed safe way to do it with the existing tools and tech.
Think about it, on-chip bidirectional buses are all done with wired-OR these days, yet functionally it acts like a tri-stated bus. Perhaps the same could be done with partial reconfiguration, it's just too hard to force the tools to obey such a construct. The bus-macros are so inefficient - one of my students looked into making a 32-bit bus macro, it would take more than the height of a V2-1000 device! To do real work with dynamic modules etc you need wide buses - bus macros just aren't gonna cut it.