Layout Table~~~~1179~1179~~

Main Links~~~~1179~2243~~

Layout Table~~~~1179~2242~~

product links~~~~1179~2241~~

Layout Table~~~~1179~2240~~

Links~[Techitips]
[Pushing PicoBlaze] [FPGA Design Checklist] [Incremental Synthesis] [Using I/O Registers]~~~1179~1341~~

Using I/O Registers~~~~1179~1318~~

A powerful and often under used resource of modern FPGAs a~A powerful and often under used resource of modern FPGAs are the I/O registers that are available in most vendor offerings. So why make an effort to use these registers? Well the answer is simply that they provide a stable interface between the world outside and your FPGA. Ever wondered why some FPGA builds work and some don't? Using non I/O cell flip-flops, or worse asynchronous input / output logic stages, means that the timing can vary widely between builds. Where system timing allows we would always recommend using the I/O registering available even if that means adding registers at the periphery of your design.

Designers primarily used to CPLDs, or board level designers, moving over to FPGAs often expect the semi-guaranteed I/O timing that CPLDs or standard logic devices usually offer. Not so, FPGA setup, hold and clock to output times vary widely with routing and logic structure. Routing and logic structure depend on virtually all tools in the design chain. Are you at the mercy of your synthesizer, mapping and p&r tools? Using I/O registers minimizes the possible design variations between builds. For all builds the I/O register will be in the same place, with the same delay between register and pin. This leaves timing that will only depend on clock routing, I/O cell delay elements and environmental factors such as voltage and temperature. A significantly more stable situation than fabric based flip-flops or asynchronous logic would present.

Ok so how do you find out if you are using I/O registers. In Xilinx, our speciality, you can look at the map report which usually lists the number of I/O registers, compare this number to pin count. You can also run timing analyser and look for I/O that have either a wide set of setup/hold (input) or have a relatively large clock to out time (offset out). You can also use Floorplanner and FPGA Editor tools to examine a place & routed design to see if I/O registers are used. In you are not using Xilinx then Altera and other vendors have similar tools by which you can examine your implementation.

If you are not using I/O registers for all pins check the I/O register option available in Map Options is set appropriately. You can do this in ISE by pressing the right mouse key over "MAP" in the process window and then selecting "PROPERTIES" you should see a window like this:

~~~1179~1322~~

ISE4[1]~~~~1179~1324~~

We usually set for "inputs and outputs". Set timing constrain~We usually set for "inputs and outputs". Set timing constraints for clock frequency, setup and hold (offset in), and clock to output time (offset out). After each build of your design tighten your setup and hold and clock to output constraints up if there is obvious slack. These constrains can act as flag if later in the process you accidentally "break" a register. With experience on a given part you will be able to set these values first time or within a couple of interations. The easiest way to set constraints is to double click on "constraints editor" in the process window as shown below:~~~1179~1326~~

ise_const1~~~~1179~1328~~

If you have not already run the synthesizer (XST in this view) an~If you have not already run the synthesizer (XST in this view) and "translate" then ISE will run these and the constraints editor window will pop up. You may need to define a constraints file in later ISE versions before this will run. Add a constraints file using right mouse key in the sources window and selecting "add source". Once successfully run the constraints editor will look like this:~~~1179~1330~~

constraints1~~~~1179~1332~~

Add you clock timing constraints under the global tab and save. Th~Add you clock timing constraints under the global tab and save. The ISE tools will usually warn that you must rerun "translate" and a process reset window will appear. Reset the flow to rerun "translate" then run the tools through the full flow.

Still got elusive registers? Ok time to look at your source HDL. One of the usual problems is a piece of asynchronous logic between the register and the pin of the FPGA. look at your code to see if there are any bits that a synthesizer might generate a piece of asynchronous logic. One common mistake is using pin muxes for internal register read back or write. Make these muxes synchronous if you can.

Another common problem is caused by synthesizers taking equivalent registers and combining them. Often in this case the register ends up in the main FPGA fabric with a route to two or more I/O cells. You will have to overcome your synthesizer equivalent register removal on appropriate signals. This varies from synthesizer to synthesizer and is sometimes a code attribute such as "preserve_signal" (VHDL) or alternatively a synthesizer constraint, look up your manual.

Other synthesizer issues can affect the insertion of I/O registers. On old Xilinx families, XC4000, original Spartan and older, the I/O registers was a different element to the CLB register. For these families you must ensure that the synthesizer inserts the correct register in the output netlist. This issue does not affect Spartan2/2E/3 or Virtex families as the register element is the same for I/O and CLB fabric.

Occasionally registers not in the top level HDL file are not netlisted such that I/O registers can be used. This problem is usually related to synthesizer hierarchy settings. If possible infer your I/O registers using a simple pipeline style at your top level, i.e. reg output = input under a clock process, avoiding complex logic functions at this level. Place the complex logic functions in other processes or lower levels of the hierarchy. This is usually reliable but can add a clock period of extra latency.

~~~1179~1336~~

disclaimer~Disclaimer

TechiTips are supplied as suggestions only. They are prepared in good faith to be as accurate as possible but we can't accept any responsibility for mistakes or omissions in these tips. We hope you find the tips useful but can't offer any support on these tips other than to our in-maintainence contract customers. Please revisit for future tips.

~~~1179~1334~~

Future Tips~Future Tips

If you have a good idea for a subject to cover please send them to tipsuggestions@enterpoint.co.uk

If you would like an email when this page is updated please sent an email to tips_notify@enterpoint.co.uk~~~1179~1333~~