Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Xilinx (XLNX) -- Ignore unavailable to you. Want to Upgrade?

To: Bilow who wrote (2170)	1/9/1999 2:01:00 AM
From: Bilow	Respond to of 3291

The other day I sent a bug report into Xilinx. The mapper doesn't let you register the output of a RAM in the same slice as the RAM. Allowing this would be a significant performance improvement, and the current silicon is capable of it, as can be verified with the EPIC tool. (The EPIC tool allows you to directly examine and modify the design of an FPGA.) The response from the Xilinx engineer enraged me so badly that I immediately erased it, otherwise I would be posting it here. He/she suggested that I not restrict the flip-flop to the same location as the RAM primitive, and maybe the mapper would "suck" them into the same cell. Having worked with the mapper for four weeks, I figured that the mapper was highly unlikely to combine them. (For instance, the mapper won't put a MUXF5 into the same slice as the two LUT4s that feed it.) So his advice was basically an invitation to waste my time testing his silly hypothesis. (I did waste my time testing the hypothesis, of course it didn't work, but it only took 7 minutes.) In addition, his response didn't tell me whether he had passed my bug report on to the mapper group. So I don't even know if there is anyone at Xilinx who is now working on the problem. Consequently, I decided to post a couple mapper bug reports on this thread. Hopefully there is someone in the mapper group who reads SI, and who will send these reports to the right software engineer... Mapper error, Foundation 1.5i, RAM32X1S interaction with FD. Bug description: Can't put a flip-flop on the output of the RAM32x1S part in the same slice. This is easily done in EPIC, and is something the mapper should allow. Importance: The mapper error is significant in that allowing the RAM output to be run through a flip-flop turns the RAM32X1S into a fully synchronous RAM. The write port is already synchronous, this change will allow the read port to be similarly synchronous. Anybody who is doing really high speed designs is likely to need a synchronous read port. With the current situation, only those willing to use inconvenient hard macros can get the lower area utilization and higher speed performance. Error Message: 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:27:47 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 I219 Process will terminate. Please call Xilinx support. Note that I219 is the flipflop (FD), RLOCed to the same slice as the RAM32X1S: "R0C0.S0". -- Carl

To: Bilow who wrote (2170)	1/9/1999 2:10:00 AM
From: Bilow	Read Replies (1) \| Respond to of 3291

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