The challenge of learning to use FPGAa is actually an effort with quite a number individual factors. Here is a list of a number of those considerations.

A) Learning how to select which vendors technology is the best type for a particular design project. The main varieties are fine grained types (like QuickLogic parts) and higher level parts (like Lattice or Xilinx parts). Fine grained parts can end up with easier to route and fit into a part BUT you can end up with logic that is chained throuh multiple logic blocks and thus increase logic delays.

B) Dealing with pin number assignment and whether pin assignment can survive through several iterations of product support and design improvement. When you enter the FPGA world it is mandatory to FULLY design the part and derive its pin assignment before you commit to a PC board layout artwork. There is a tendancy for those new to FPGAs to draw a box on the board level schematic called FPGA and show all the things they think need to go in and out and establish a pinout. They then advance to a parallel effort of getting artwork designed and finalizing the FPGA design. There is often a mistaken impression that the FPGA can be treated as software as opposed to hardware. If you do this you will be sorry and most likely find that your first PC boards are scrap. Intensive FPGA designs often are the more complex designs and have fine pitch parts in them which are difficult to rework when the pinouts are in need of change.

C) There is a challenge of determining logic density in FPGAs versus the available pin I/O count. There is often a desire to cram all the logic into the biggest FPGA you can get. This can lead to a large package that hooks to every edge of the circuit board. This can make the PC board very difficult to route and the area near the FPGA can be a huge MESS. And by the way BGA packages can make this worse as the pin density per square unit of PC board real estate goes up. An experienced designer will be able to make good decisions on partitioning a design amoung multiple smaller devices to distribute the routing rats nest across the board.

D) Spare capacity is an important consideration that may take several design projects under the belt to gain a good appreciation of its importance. You never really should design a FPGA up to 98% of its capacity. FPGAs offer the ability to increase complexity and/or functionality of a design project. With that comes the tendancy to want to tweak the design after the product nears release. For this reason it is necessary find a good balance between FPGA part(s) cost versus the spare capacity allowed. For example it may be uneconomical to design in an FPGA that is only used to 30% of capacity whilest it may be impossible to support the product life cycle maintenance needs if a part is utilized to 90% capacity. I have found that 70% capacity utilization is a workable target. Spare capacity allows easier re-routing of a design in a part, better ability to maintain a pre-determined pinout assignment, and permits later addition of more logic in a part. Spare capacity should include both logic block available and extra I/O pins. Spare pins can be essential in supporting debug of a design on a PC board in system when it is possible to use the pins as a tap into internal circuits that are not normally visible. (And YES, it is very important to anticipate the need for re-programmable visibility inside a part despite the availability of simulation capability. I have had quite a few designs where the simulator was not able to properly support detailed analysis of the design when taking into account how the part was interfaced to the rest of the PC board. Of particular difficulty is the ability to simulate the timing of data turn around on bidirectional I/O pins). If a design is partitioned between multiple devices it can be a good idea to design a few I/Os that connect among the FPGA devices that are not used.

E) There is real need to use FPGAs with good hardware design practices. Seasoned hardware designers (particularly those who remember boards full of 74xx SSI and MSI parts) appreciate the value of synchronous design and the use of state machines. These techniques lend themselves very well to FPGA designs. I have seen many designs in the past, often done by more inexperienced designers, that one can term as asynchronous logic or "crash logic". This type of design should be considered unsuitable for FPGA designs.

F) I have often considered it a very good idea that a task to design in a new processor into a product should include learning and applying the assembly language for that processor. I would discourage the use of C language or other HLL exclusively. The same applies to the use of FPGAs. In my opinion it is a good idea to perform your first FPGA designs at the schematic level or simple boolean logic equation level. I have seen all too many times where a software type engineer (without previous hardware level design experience) will dive into using FPGAs by using the likes of VHDL or VERILOG out of the starting gate where the resulting design is a disaster!!!

G) It is extremely important to become very proficient at understanding the timing issues involved in hardware design and how to apply those to FPGA designs. FPGAs have their own considerations. How you achieve this is a subject that can lead to heated debate with experienced designers. I can suggest that this is MOST important for those designers that approch an FPGA design as "OK here is the circuit I need so how fast can I crank up the CLK and still have it still work?" On the other hand it is possible to select the right type of synchronous design technigue applied to the proper type of FPGA architecture and just know that the part will perform properly without exhaustive timimg and path analysis.

H) Learning FPGA design also has the burden of the "tool learning curve". This can be the biggest issue of you want to use the lowest cost tools and at the same time want to look at parts from multiple vendors. The free/low cost tools from each vendor are different and will require a separate learning curve for each tool set. The only way to get around this is to specailaize in a high level tool set that costs huge amounts of money but supports parts from multiple vendors. Unfortunately these high level tools often dont have as good of logic fitters as the tool sets that vendors have put into their own tools sets.

I hope this info is helpful
Michael Karas