Another mapper bug report. I should probably mention, in support of Xilinx, that even with these inefficiencies, the Xilinx silicon is still maybe 12 times as efficent at performing these functions than Altera. With these improvements, we can get that ratio up to 16 or more.
Bugs are always present in engineering software, it is the responsibility of engineers who use the software to report the bugs. So here it is:
Mapper error, Foundation 1.5i, SRL16E interaction with FD
Bug description: Mapper won't put an FDE flip-flop on the output of an SRL16E in the same slice. This is easily done in EPIC, and since my design will use 1728 of these constructs, I would really appreciate the mapper correction. Otherwise, I will use some other technique, and my utilization for that part of the circuit will increase about 25%.
Importance: Other users will, no doubt, find an improved functionality with this fix. For area utilization, adding the flip-flop means that a 17-bit shift register can be placed in a half of a slice. In addition, modification to the output by a change in the address inputs will become synchronous instead of asynchronous as it currently is. This is a significant improvement, making timing much easier for those who wish to use variable length shift registers. (The address inputs specify the length of the shift, from 1 to 16.)
Design Information
------------------
Command Line : map -p xcv100-4-pq240 -o map.ncd gentest.ngd gentest.pcf
Target Device : xv100
Target Package : pq240
Target Speed : -4
Mapper Version : virtex -- M1.5.25p
Mapped Date : Fri Jan 08 18:31:03 1999
Design Summary
--------------
Number of errors : 1
Number of warnings : 1
Section 1 - Errors
------------------
FATAL_ERROR:xvkma:xvkmapper.c:1691:1.112 - Cannot satisfy LOC/RLOC constraint
on comp I201 Process will terminate. Please call Xilinx support.
Note that I201 is the output flip-flop (FDE). The two SRL16Es and the FDE are RLOCed to the same slice: "R0C0.S0".
The third error, seems to actually be a mislabeled warning, as after giving you the error, it goes on and places and routes the design correctly:
Mapper error/warning, Foundation 1.5i, RAM32X1S and F6MUX interaction
Description: If you put two RAM32X1S primitives into different slices of the same CLB, and then multiplex their outputs using a F6MUX, you get what could be called a RAM64X1S (which probably should be a Virtex primitive). But when I do this, I get the following mapper error message:
ERROR:xvkma - F6MUX I218 has incompatible locs with F5MUX at pin 1 I217.
Despite this ERROR (as opposed to warning), the design completes, and uses the F6MUX correctly. Note that the outputs of a RAM32X1S are automatically F5MUX outputs, and so are compatible with the F6MUX, contrary to the above message. Of course it works perfectly in EPIC.
The mapper still doesn't allow the output of the F6MUX to be registered, just as is the case with a single RAM32X1S. This is easily done in EPIC, and adding this ability will improve 64x1 SRAM, making it synchronous for both reads and writes. RLOCing a flip-flop to the F6MUX output in the same slice gives a fatal mapper error, but can easily be done in EPIC. Note that EPIC also allows you to register the output of a RAM with an FDE instead of an FD, though I have not found the need to do this in my design...
-- Carl |
