Developing hardware in FPGA with LED Driver Chip
During the firmware build process, the Map stage maps the top level signals of your firmware to physical FPGA pins. This assignment is almost always done manually by including pin assignments in a file called the constraints file (by the xilinx tool set, at least). If no constraints are found the pins will be allocated by the build tool.

Essentially, all your top level module signals end up being physical pins. Here's an example from a board I'm designing at the moment:



And this is an extract from the Xilinx constraints file:

(yours might look different if you're using a different vendor's tools)

NET "DEBUG_CONN_1" LOC = "M7";
NET "DEBUG_CONN_2" LOC = "M8";
NET "DEBUG_CONN_3" LOC = "R4";
NET "DEBUG_CONN_4" LOC = "P4";
NET "DEBUG_CONN_5" LOC = "M6";
NET "DEBUG_CONN_6" LOC = "L6";
NET "DEBUG_CONN_7" LOC = "P3";
NET "DEBUG_CONN_8" LOC = "N4";
NET "DEBUG_CONN_OE" LOC = "M5";


This tells the FPGA map tool which signals to map to which pin.

And finally, an extract from the top level entity:

(this is VHDL because that's what I use, but it should give you the right idea)

ENTITY 6slx45fgg484 is
    PORT (
        DEBUG_CONN_1    : OUT STD_LOGIC;
        DEBUG_CONN_2    : OUT STD_LOGIC;
        DEBUG_CONN_3    : OUT STD_LOGIC;
        DEBUG_CONN_4    : OUT STD_LOGIC;
        DEBUG_CONN_5    : OUT STD_LOGIC;
        DEBUG_CONN_6    : OUT STD_LOGIC;
        DEBUG_CONN_7    : OUT STD_LOGIC;
        DEBUG_CONN_8    : OUT STD_LOGIC;
        DEBUG_CONN_OE   : OUT STD_LOGIC;
        .
        .
        .
        );
END 6slx45fgg484;


The constraints file is used to specify various parameters about the physical pins. For example, IO standards, termination and drive strengths may all be specified in the constraints file. Additionally, this is where you specify clock speeds for timing analysis, and the mapping of bigger firmware blocks like built-in trancievers. 

If you're interfacing with a device that uses a clock to clock data into or out of the FPGA, you might need to change clock domains or triple register your signals in order to convert the signals into your working domain on the way in, or the device's domain on the way out. 

Generally, if you're just writing code in order to pre-empt the hardware, you can just write a module where the input and output entity signals match those of the device. When the hardware arrives, it's a matter of mapping your entity signals through to the top level, configuring the constraints to match the hardware, and you should be good to go.