I ran into difficulties adapting the static source handler for Spartan6.
The major problem occurs in the method
that is working on the field
HashMap<Integer, SinkPin=""> sinks;
For a certain Pin no sink pins can be found although there have to be some. I checked that in the xdlrc-file and ISE finds a route too. So there has to be a problem with the population of fields or even with the .dat file itself. The problem occurs on various tiles.
As a result one cannot find a switch matrix that is connected to the pin.
Instead of using FileTools.loadDevice() to read in the device properties I tried the method XDLRCParser.parseXDLRC(). But the latter did not work for Spartan6 neither for Virtex5 because there was a problem with the wireEnumerator; some wires could not be found.
I'm sorry you are seeing this issue. Can you provide an example of the pin connections that appear to be missing?
You can try to rebuild the Spartan6 database files if you'd like. You can run the installer, see edu.byu.ece.rapidSmith.util.Installer.main() and pass it 'spartan6' as a parameter. You will want to delete and backup the existing Spartan6 files though before you do so.
here some sample pins for which the switchMatrixSink is missing:
A6 on tile=CLEXL
CLK on tile=MACCSITE2
DIA0 on tile=BRAMSITE2
PSEN on tile=CMT_DCM_BOT
I am not able to rebuild the database because the installer also calls the XDLRCParser.parseXDLRC() method, which does not properly work in my RapidSmith Version 0.5.2 , neither for Spartan6 nor for Virtex5.
It fails when trying to read the Device of the current Tile, but the value is just null
Are you able to run the XDLRCParser.parseXDLRC() method or even to rebuild the database with the last RP Version 0.5.2 ?
The API you are calling requires pins that are on placed design instances. I have attached a short run-able example as to what is needed for this to work. This method was designed to help with routing nets and presumes a placed design in order for this to work. Have a look and see if this helps answer your first question.
As for the installer failure, I haven't had a chance to try and reproduce it, but when I do I will let you know my results.
I attached a modified version of your file, for you to reproduce my error. I changed the device and the site to that respective one where the neighboring switch matrix cannot be found.
From your file I was able to reproduce the issue. I have submitted a fix for the Installer issue. You can either sync-up to the HEAD of the SVN repository or you can overwrite your device/XDLRCParser.java with the new file I have attached.
I rebuilt that particular database file that you had listed in your version of TestS6Pins.java and the problem is still recurring.
I believe the problem might be somewhere in the Device.populateSinkPins() method that happens during database file creation. The SinkPins are not getting populated properly and this is causing the problem. Unfortunately, this function is a bit complex and it appears that I only got it working for some families.
Unfortunately the demands of life and my schedule will make it to resolve this issue and it may have to wait until later next week. However, feel free to take a look yourself (load it up in the debugger) and you might be able to find the problem.
I'm sorry I can't be much more help at the moment. Feel free to reach out with more questions and I'll try to answer them.
I apologize this took so long, each time I tried to work on this, I could get enough time to figure out what was going on.
The SwitchMatrixSink hash was not getting populated because the Spartan 6 has an extra Switch Matrix tile type called INT_BRK and I have attached a fix here. It will take some time to validate this change to make sure that it doesn't impact other architectures so, you will have to re-run the installer your self to get the new files.
First, overwrite your existing Device.java with the one I have attached to this post.
To run the installer , you'll have to just delete the files:
Then run the installer:
java -Xmx1200M edu.byu.ece.rapidSmith.util.Installer spartan6
(you can make this run faster if you are only interested in 1 or a few parts by supplying them on the command line, run the installer without options for more details)
Make sure you have several GBs of disk space when you do this because it will have to generate a few large XDL files simultaneously and might take a while.
This bug was present simply because we never did any work with the Spartan 6 and I failed to review this architecture in detail.
If you have any more trouble please respond back and I will try to respond much more quickly.
Thanks and wish you well in your thesis!
I tried to rerun the Installer for Spartan6 architecture, but unfortunately it fails after a few familytypes at following type:
Part Name: xc6slx45fgg484
Tile Rows: 141
Tile Cols: 90
Total Tiles: 12690
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
So i continued working with familytype xc6slx4tqg144, which data files were created sucessfully and run the BasicRouter with it. But then there is still following error:
Exception in thread "main" java.lang.NullPointerException
This error is related to the method "public WireConnection get(int key)" in "WireHashMap", which returns a null pointer instead of a WireConnection-Array.
Thanks in advance,
I've gotten that index out of bounds error too. It happens when the getFamilyWireCount() method in the Device class returns a number that is smaller than the actual family wire count. Unfortunately, because Xilinx doesn't provide any exact numbers on the count of unique wires across their families, we usually have to make an educated guess at this number. The good news is, the number this method returns doesn't have to be exact, it just has to be greater than or equal to the actual number. In the file Chris posted, try changing line 1397 to return a larger number such as 60000. If you're still getting this error, increase it some more. Hope this helps.
by increasing this number to 100000 helped and the installer finished sucessfully.
But there is still the same problem with the BasicRouter as mentioned before.
in my search for possible solutions some properties have shown up, I dont really understand.
Sometimes the key-parameter of "public WireConnection get(int key)" has the value "-1".
I thought, that this key should refer to a valid wire and an entry in the "values" list can not be found, because it is not a valid wire either?
In other cases, where the key-value seems to be valid, there is no entry in the values-list for this key?
When there is no entry the function returns a null-pointer, is that ok?
Sometimes when generating a new Node in method "public Node getSwitchBoxSink(Device dev)" of class Node, a negative tile-column value is calculated and then no corresponding tile can be found for this invalid column.
Would you mind posting the design you are attempting to route? Or, if you can't, just post the net that you are attempting to route. That would make it much easier to debug.
here is a simple design. It just serves the purpose for testing and consists of some connections to a TIEOFF as static source. I adapted the code accordingly for Spartan6, but nevertheless the error occurs very early when this special settings are not yet necessary.
Exception in thread "main" java.lang.NullPointerException
Hope you can fix this issue,
I tried looking at this tonight, but you must have changed the code in BasicRouter because there are multiple safeguard errors in place that say Spartan6 is not supported.
Both are in StaticSourceHandler. Did you provide a slicePin equivalent for Spartan6 or a pinSwitchMatrixMap? I'm curious as to what you did because we don't currently have any implementations for Spartan 6.
I remember spending a non-trivial amount of time writing those functions for Virtex 4 and Virtex 5 so I imagine doing so will take an equivalent amount of time for Spartan 6.
Are you skipping GND/VDD nets? Would you be willing to post a snapshot of your changes?
It might be difficult to provide help since we don't currently have support for Spartan 6 routing.
On another note, you may want to try something that might be causing an issue. Try restoring all of the files in
from the repository and delete only the part that you are interested in. Then, re-run the installer as I described earlier and see if that has any affect on the behavior you are seeing.
I did following adaptions for Spartan6:
line 119: SlicePin for Spartan6
line 523: new Function sortPinsSpartan6()
line 693: new Function step3_Spartan6()
line 930: new case SPARTAN6
line 958: call step3_Spartan6()
line 1353: call findSLICE_Spartan6()
line 1403: new Function findSLICE_Spartan6()
line 1487: new specific BounceMap for Spartan6
line 73: new case SPARTAN6
and added the S6PinSorter class.
Here the java files...
Thanks for providing an example XDL file. I will be looking into this over the next two weeks and should have an answer for you by then, if Chris doesn't find one sooner.
Dear Chris and Brad,
I have managed to adapt the routing for spartan6. To achieve that, I had to do a few adjustments in the RapidSmith code.
I modified some of the actual RapidSmith classes in order to generate valid .dat files for spartan6 and added some adaptions and forks.
I appended the classes I have changed and created in the folders "modified" and "new" respectively. The SinkPinsPopulator class provides an alternative populateSinkPins method to bypass the original one in the class Device.
The BounceMapCreator class creates a BounceMap according to the BounceMap already existing in the StaticSourceHandler. So far the BounceMap is exported into a file and could be integrated in the code.
I have marked the changes in the code. You also should easily be able to recognize them by comparing our files to the original ones. With the modifications the code should still run for other architectures like Virtex4 or Virtex5. So you could integrate them into the RapidSmith project after reviewing them.