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: Joe Pirate who wrote (2215)	2/3/1999 9:17:00 PM
From: Bilow	Read Replies (1) \| Respond to of 3291

Physical macros... When you want to squeeze just a little bit more out of a Xilinx part, it helps to know how to put together physical macros. And Xilinx talks a lot about them on their problem solutions (i.e. bug work around) pages: xilinx.com xilinx.com xilinx.com xilinx.com xilinx.com xilinx.com xilinx.com xilinx.com These are older help files, but as recently as 12/98, Xilinx published: (pdf) xilinx.com which uses physical macros as a work around. But the company is amazingly quiet about the details of how to use them. A lot of the above documents refer to the on-line "Xilinx Manual EPIC Design Editor Reference/User Guide.": toolbox.xilinx.com This document discusses how to use EPIC in some detail, particularly how to make physical macros, but the only mention of how to use a physical macro in a schematic is the following: You can also instantiate the macro into a schematic drawing, by entering a block in the schematic, configuring the block appropriately, and placing a reference to the .nmc file in the schematic. Which is kind of brief... So when I had a problem with a physical macro, I figured it was probably just me, and putzed around with it for days trying to get it to work. Finally, I distilled the problem down to an extremely simple case, and submitted it to the Xilinx help guys. They wouldn't take a text description of the problem, so I e-mailed them a zip file showing the problem (which was of the mysterious sudden software crash variety.) Naturally, the file I sent contained a hard macro. I was stunned by the reply I got back from Xilinx help, something to the effect of "why is there a component in this schematic that does not have a defining schematic associated with it?" Since physical macros are such a big thing in the Xilinx solution files, I figured that everybody on the Xilinx help lines had to be familiar with what ".nmc" means. So I replied back with an explanation of what a physical macro was. This did nothing to convince me that the Xilinx help people know more about their product than the engineers who use them. Eventually, Xilinx help submitted the problem to the software group, which immediately responded, to the effect that this bug was easily avoided by setting the NO_DELAY_BASED_MERGE variable (presumably to TRUE). I could have saved at least 50 hours of work if this bug report had been placed on the Xilinx web site, indexed by the type of problem it generated. I looked today, and it still isn't there. Instead, when you do a search for "NO_DELAY_BASED_MERGE", all you get is: xilinx.com xilinx.com I really don't have an explanation for this sort of behavior from Xilinx. I accept that the tools are not going to be perfect. But I don't accept that the company is going to suppress bug reports. The lack of support for physical macros, I can only suppose, is due to a desire to have people use RLOCs instead. But the wealth of bug reports that reference physical macros suggest that ignoring problems with them is not a good way to go. (Yeah I was really angry when I wrote this, but it still needs to be said...) -- Carl P.S. While getting the links for the above, I am reminded of a problem report that didn't really show you a good way to work around the problem. I had the following problem (i.e. "zippering" RLOCed macros). I was able to work around it using the U_SET attribute, which is not mentioned in the problem report. (Basically, these give you a natural way to combine non-hierarchically related H_SETs into a set having a single RLOC_ORIGIN. This allows full zippering, provided you can determine the interrelation in advance. Maybe U_SET doesn't work this way on previous version of PAR, but it works great on 1.5i for me.) xilinx.com