Answers Database

MAKEBITS 5.2.X: length count differs due to new default -lc=aligned_lc


Record #780

Product Family:  Software

Product Line:  FPGA Core

Problem Title:
MAKEBITS 5.2.X: length count differs due to new default -lc=aligned_lc


Problem Description:
Keywords: MAKEBITS, length count, configuration

Urgency: Standard

Decription:

MAKEBITS 5.2.x generates a bitstream which has a different
length count than a bitstream created with previous versions
of MAKEBITS.


Solution 1:

The default options were changed for makebits between version 5.1 and
version 5.2. The default options for makebits 5.2 is: -lc=aligned_lc.
The default options for makebits 5.1/5.0 is: -lc=aligned_done.
The usage for makebits	5.2 still shows the default options as
-lc=aligned_done though it is -lc=aligned_lc.

To fix the problem, explicitly specify the length count option on
the command line:

makebits <design> -lc=aligned_done

It is important to note that, in spite of the length-count difference,
both files resulted in a properly functioning part.

The default option is "Length-Count aligned" which adjusts the
length-count value such that length-count match occurs during the
first bit in the last configuration byte. This assures sufficient
CCLK pulses to complete any selected type of start-up sequence.
The other option is "DONE-aligned", which adjusts length count value
to make DONE go active at the end of a configuration data byte,
which can cause problems in Peripheral mode.

So "Done-aligned" is sensitive to Peripheral mode.

The issue that led to the change is described on the last page of the
Xilinx app note "FPGA Configuration Guidelines".  It deals the appropriate
length-count value for byte-parallel  configuration.  ( For byte serial
configuration, the length count can be any value, as long as it is high
enough, and there never was any problem with that.)

For byte parallel configuration, it is mandatory.  From detecting the
length-count match to the real end of the configuration process (reaching
"F" in the drawing on page 4-54 of the '98 data book), all occurs
within the same byte. Therefore it matters where the byte boundary is,
and the length-count value is calculated appropriately.

The length-count calculation algorithm calculated a value that made
"DONE go High" at the end of the last byte.  This did work for most
cases, but created problems with some parallel interfaces driving
certain daisy-chains.

The "Length Count Aligned" offered a smarter way of calculating length
count:	Make sure that the "beginning of the end", the detection of
"length-count match" occurs at the first bit of the last byte, then there
will always be enough CCLK pulses to finish configuration. That's
obviously a cleaner and simpler algorithm.



End of Record #780