This is covered fairly thoroughly in Product Info/Product
Bulletin/Frame Relay Broadcast Queue, Cisco Product Bulletin # 256,
available on CIO.

Via the web (requires CIO username and pasword)
        http://cio.cisco.com/warp/customer/417/38.html

An excerpt:

(Virtual Interfaces)

   It should be noted that in the IOS (Internetworking Operating System)
   10.0 software there is a limit of 256 Virtual and physical
   interfaces. Hence, if each DLCI is given its own virtual interface,
   the router is limited to 256 DLCIs. This restriction is expected to be
   removed in a future release.
   
   In most scenarios, it is not necessary that each DLCI have its own
   Virtual Interface. In particular, IP has the facility which allows
   disabling of split-horizon routing and hence does not require Virtual
   Interfaces to support partial mesh topologies.
   
(Appendix 1: How many DLCIs Can Cisco Support on an Interface?)

   This question is similar to the question of how many PCs can you put
   on an Ethernet. In general, you can put a lot more than you should
   given performance and availability constraints.
   
   When dimensioning a router in a large network, the following issues
   should be considered:
   
   DLCI Address Space: The only hard limits are the roughly 1000 DLCI
   limit due to the 10 bit DLCI address space in the Frame Relay frame
   header.
   
   LMI Status Update: The LMI protocol requires that all status reports
   fit into a single packet and generally limits the number of DLCIs to
   less than 800.
   

  Max DLCIs (approx) = (MTU -20)/5,
        where MTU is the MTU size in bytes on the Frame Relay link.


   Broadcast Replication: When sending, the router must replicate the
   packet on each DLCI and this causes congestion on the access link. The
   Broadcast Queue reduces this problem. In general, the network should
   designed to keep the routing update load to below 20 percent of the
   access lines speed. It is also important that memory requirements for
   the Broadcast Queue be considered. A good technique to reduce this
   restriction is the use of default route or extending the update
   timers.
   
   Broadcast Receipt: When receiving, the router must receive updates
   from the network. The issue here is that the upstream switch can be
   overloaded and drop packets. When routing updates are dropped, routing
   instability occurs. Again, the receiving routing update load should be
   kept to less than 20 percent of the access link speed and preferably
   lower. Where very high speed links are used, a limit of 128 Kbit/s
   worth of routing updates is recommended.
   
   Routing Stability: When using a link state protocol to reduce the
   update traffic, the dimensioning should be done assuming the periodic
   update process and the worst case for Link State Updates (i.e.,
   assuming link and power instability). Dimensioning should not be based
   on the Hello traffic. As a rule of thumb, dimension assuming a
   distance vector protocol, but assume that extra bandwidth is available
   for user data.
   
   User Data Traffic: Clearly, the number of DLCIs is dependent on the
   traffic on each DLCI and the performance requirements to be met. In
   general, Frame Relay accesses should be run at lower loads than
   router-to-router links since the prioritisation capabilities are not
   as strong in many cases and in general the marginal costs of
   increasing access link speed are lower than with dedicated lines.
   
   Many of the issues covered here are included in the Internet Design
   Guide manual that Cisco provides.

Update:

The limit of 256 PVCs goes away in IOS 11.1. I think the number is now
something like 1024 per router or some even more ludicrous number. There are
still lots of reasons you never want to do that. ;-)
The limit of 256 PVCs goes away in IOS 11.1. I think the number is now
something like 1024 per router or some even more ludicrous number. There are
still lots of reasons you never want to do that. ;-)