Virtual Pin in Xilinx ISE

I've never heard of anything like that for the Xilinx flow - although it may exist. It sure would be useful. My experience with Xilinx is that it wouldn't be integrated throughout the flow. You'd have to specify the option in XST, then again in MAP. And then I'm not sure if PAR and bitgen would be happy with dangling logic (I've seen bitgen error out because of the MAP stage not cutting out unused logic). Although I'm not a big Project Navigator user - maybe someone else here knows better. One thing you could do is pipeline the results of any logic you want to keep and put them all through some kind of reducing function (i.e. OR them all together) and assign the single bit result to a pin. Alternatively if you have a uP bus, assign the outputs to a read-only register. Hacks, I know, but it'll work.

There are options to allow or prohibit automatic allocation of pins; if you prohibit allocation, only the pins you allocate (usually via the .ucf = user constraints file) will be allocated.

A "keep" attribute(*) on each non-pin signal should prevent it being optimised away.

(*) I say attribute, assuming you are using VHDL. I don't know the Verilog equivalent, but there must be one.

Searching for "keep attribute" and "ucf" or "pin constraints" should bring more info and examples.

- Brian

If you are using a package that has some unbonded pads on the die, you can assign your virtual pin to an unbonded pad

In my experience (eg, I didn't quite do it right) a keep attribute is optimised away when it comes to MAP or PAR. I can't recall which tool was to blame...

My solution was to assign the signals to an output pin via a reduction operator, and then to unroute the output pin from the rest of the FPGA after implementation. I then had to disable DRC for Bitgen, but it was the only error.

ed.

Thanks for the suggestions.

-Jeremy

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----

---= East/West-Coast Server Farms - Total Privacy via Encryption =---