Registers at I/O

In order to have reliable (deterministic and short) timing at the IO boundaries you need to have registers in the IO.

The other comment that you referred to is also a very good practice. Registering an asynchronous input at the boundary will resolve the asynchronous event to a single clock edge within the module (metastability concerns aside) so that timing analysis can be done correctly and so that all parts of the module will "see" the same value. Since this is an asynchronous signal and by its definition can happen at any time adding a register has no practical impact.

These are not absolute rules. You are free to create your design in any way that you see fit, but when the design isn't stable and reliable you should remember these design tips.

You speak like about primary I/O. Yet, partitions are blocks of the same FPGA design. They are under full control of the tools. Do you mean that partitions treated as designs, absolutely external to each other?

Thank you.

One of the games is register retiming to improve Fmax. If I describe a 128 input OR gate without registers, my fmax will be very bad, and the tools can do nothing about it. If I pipeline the design with registers, syntheses can move the luts around to optimize Fmax.

-- Mike Treseler

(snip)

(snip)

It would be nice if the tools could help placing of such registers.

For the 128 input OR, I might know that it can have one pipeline register inside, but don't know where it should be. (My pipelines are usually more complicated than an OR gate, but the same idea applies.)

One possibility would be to have a set of registers that are optional, such that the tools should leave them in if it improves Fmax, but omit them if it doesn't. It will take a while to converge, but still better than trial and error.

-- glen

It doesn't matter, at least with quartus. I can put a shift(n) register on all the outputs, turn on reg dupe and reg retime, and let synthesis have a go at it.

Mine too. The gate example was just for clarity.

Would be nice, but that's not how it is with quartus today. Trial and error works OK with a reasonable starting guess for n.

-- Mike Treseler

(snip, I wrote)

OK, one specific problem. The designs I am interested in are linear arrays of pipelined elements. I can optimize the individual element, but I also need to optimize their placement in the arrays.

It might be that the tools can well optimize a linear (on chip) array of unit cells, but sometime it will get to the chip boundary and need to turn around. The paths needed at that point are likely longer, and so I might want to add additional registers. I don't know very well where those points are. In addition, there is the path from the I/O buffers to the first, and from the last to I/O buffers, which again have complications in timing and placement.

Even more, last time I tried this with the Xilinx tools, adding extra registers where I thought they might help, the tools implemented the double register as SRL16 cells, (shift registers), instead of spacing them out as I had hoped.

-- glen

If the design does not fit in one FPGA, you are on your own.

That means register retiming was not switched on. Try a simpler example to see if ISE can do it at all.

To banish all SRL16s (or the altera equivalents) add a reset input to the process.

Good luck.

-- Mike Treseler