# Developing hardware in FPGA with LED Driver Chip

I asked related TI TLC5944 LED Driver questions here, here and here

Actually initially I was supposed to simulate the following design. I had to simulate the driver functionality also (as the driver chip was not available to us).

But now my mentor is asking me not to bother about the simulation of the driver, as he will be getting the driver very soon. So now my task is to write Verilog code (for lighting a row of a LED matrix) which will run on a lattice board. I can not test my code as I do not have the real chip with me as of now. But I have to write the code assuming I have the driver chip.

I have already read the specification of this driver and have understood it. I have understood how the signals are coming , and what signals are required to lit a particular LED row. The problem is I have never used any external chip along with an FPGA. And so I am not feeling comfortable with this project. In past I have done some small projects such as converting a 24 bit BMP image to 1 bit image, designing counters, arbiter, image compression etc. In none of these I had to communicate with any external chip.

How do I start working for my current design which is having external chip i.e driver? What is the basic idea involved?

Update

Just to clarify more: My problem is NOT that I have to write the code without actually having the driver chip, rather it is that how do I write code when the FPGA will be communicating with the external driver. I have never written code in FPGA that interacts with an external chip.

• Abstraction. Write code for the TLC5944 that should work, with any calls to the hardware abstracted away with functions. Break it into sections, with the goal of portability. Animation is part 1, the tlc code is part 2, the spi (fpga direct output parts) code is part 3. This way, you don't need to the chip to test with yet. (Also, why not order a sample from Texas Instruments, you can get them in like a few days free) – Passerby Feb 5 '13 at 14:37
• You will probably want to build a simple model of the TLC5944 itself, so that you can test your design in software. – pjc50 Feb 5 '13 at 14:56
• It's not very apparent why an FPGA was selected for this task over a microcontroller, which is generally the preferred solution for things that don't need extremely tight timing or high parallelism. – Chris Stratton Feb 5 '13 at 15:04
• Your schematic needs a bit of work. I'm pretty sure you don't intend on tying the SCLK, DCSEL, XLAT, BLANK and GSCLK lines together. Perhaps you meant to use a bus schematic symbol? – akohlsmith Feb 6 '13 at 13:31

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.

I assume that in your previous FPGA projects, the modules you were writing interfaced with other modules inside the same FPGA. As such, you had to pay attention to the timing relationships among the various inteface signals.

Interfacing an FPGA to one or more external chips, from a functional point of view, is no different. You need to understand the required timing relationships and write your code to meet them.

The only real difference is learning how to connect your module's functional I/O ports to physical pins on the FPGA, and making sure the FPGA pin drivers and receivers are configured correctly to match the electrical characteristics of the external chips. This is one the functions of the "constraints file" (whatever the Lattice toolchain calls it) in your project, and there will be a section in the manual that discusses these aspects of FPGA design.