04-05-2010 10:40 AM
I need some advice for doing something quite tricky on an XC2VP30 device. I am presently using ISE 9.2 webpack, but I could change to 10.1 if necessary. I am sorry in advance if my target device and/or ISE version are too old for this discussion board, or if I am posting in the wrong section.
Well, on to the problem itsself:
In the context of my MSc Thesis project, I have a small design (around 100 Virtex2Pro Slices) that works properly on the actual device. Now, for some reason having to do with my thesis objectives, I want to use the FPGA editor for MANUALLY editing a small part of the system (5 slices in particular) and afterwards generate a bit stream and implement the whole system on the device. The manual part is so small and simple that I can (actually I WANT to) implement it by hand through the FPGA editor, instead of describing it in an HDL.
What is the simpler/most reliable way to use the ISE design flow in order to achieve this?
Below I explain the way I already failed once (in case anyone is interested):
-- I removed the VHDL description of the component that I intend to build manually.
-- I defined the outputs of the removed component as inputs of the system's top level module, in order to have a dummy version of them available later on, coming from FPGA PADs.
-- I implemented the design (all the way to P&R).
-- I opened the routed design with the FPGA editor.
-- I "added" 5 new slices, unused until then, and manually implemented on them the functionallity of the removed component.
-- I cut the dummy versions of the component's outputs from the signals they are supposedly driving, and drove these signals from the actual, physical outputs of the manually implemented version of the component.
-- I drove the actual, physical inputs of the manually implemented version of the component with the signals that are supposed to drive them. Please note that the last two steps were essentially manual routing.
-- I got errors while generating the .bit file, namely "The pin <asfdas> of block <jljkljk> is used but has no
parent signal." and "The network <dafasd> has an antenna. Routing is
incomplete.". Of course, the pins and networks in question corresponded to tha manual part.
Either explaining to me how my method could work or proposing a method that does would be great help. Thanks in advance!
04-05-2010 12:33 PM
The equations and other control declarations for your individual slices define what pins are used and what pins are not. Every defined input has to have a driver.
The nets also have a specified number of destinations for one source. If one of those destinations is removed by altering a slice, the route to that pin should be removed, too. If a pin is said to be on the net, the pin should be routed.
Your task is doable, you just need to be absolutely complete inall your connections using normally undocumented syntax to fully specify the operation of your slice.
My approach would tend to include compiling a base design then changing what's there rather than just adding new components. When I get confused about syntax, I'd compile a design with a slice that has everything connected just how I want and copy the syntax from that slice to place in my later manually-controlled design.
The work is tedious but you can accomplish what you want. You just need to be complete, thorough, and often creative.
04-05-2010 01:36 PM
thanks for the quick reply. Actually my next approach would be roughly the way you explain:
-- Define the component in VHDL and even try to roughly approach the intended functionality/configuration.
-- Constraint the component to specific slices so i can easily play with it internally.
-- Modify this component internally so it exactly matches the intended configuration.
-- Reroute whatever inputs/outputs were moved to a different slice pin by the previous step.
Another question which I know I can answer myself but you might be able to save me some time:
Is it possible to constraint a net on a specific pin of a specific slice during P&R? This way I can even eliminate the last step of the above procedure.
04-05-2010 02:37 PM
My recollection is that I had to use the LUT4 primitive to get the input names right so I could confine the pins properly. By having I0 through I3 inputs for the primitive, you can use the LOCK_PINS constraint to get the actual LUT inputs A1 through A4 properly assigned to the primitive LUT4 inputs. See, for instance, page 131 of the constraints guide:
for the LOCK_PINS constraint. I *think* I had to assign I0 to A1 through I3 to A4 (or perhaps I used "all" successfully) or else the tool I used that year spat its own choice of pin selection back at me despite following the syntax as well as I could.