Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
the sort of thing that you are looking for is becomming less and less obscure as OEMs want really high performance (beyond a DSP). Take a look at http:\\transtech-dsp.com Amongst other things you will find a PMC (PCI electrically but a mezanine) with 66MHz 64 bit PCI and a completely uncomitted Vertex. The reason that its not in PCI form factor is that we are talking more bandwidth than a PC could possibly cope with (!) In mezanine form it can sit the other side of a bridge with other decent performance stuff and the PC is relegated to hosting whatever the solution is. Rob PS yes I work here no I'm not in sales. In article <Pine.GSO.4.02.10011221458100.4926-100000@rock>, Christian Werner <cwerner@informatik.hu-berlin.de> wrote: > Hi! > > I'm looking for Virtex prototyping boards with a PCI-interface. > > The PCI-interface shold be controlled by a seperate chip, so that the FPGA > does not need to provide the functionality for the PCI-Bus. > > Is there anybody who has some (good or bad) experiences with such a board > and can give me any hints which board I should buy? > > As I don't know much about PCI-programming I would appreciate a board > that is shipped with ready-to-use PCI-drivers for Linux and/or Windows and > some examples how to use them. > > Thanks in advance, > > Christian Werner > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27701
When you recalc a CRC, you need not get the same CRC, only the final register state need be the same. This may sound strange, but when you calculate a CRC on a block, you append the final register state to the block. This is the CRC. (It may be inverted before you do that, as with ethernet). When you verify a CRC, you calculate the CRC over the whole block INCLUDING the CRC itself. You should then get a certain magic number - depending on the algorithm used - this number will always be the same. Therefore, to 'fix' a CRC, you can modify any value in the block to make the final magic number appear correctly. How to do that - well, I dunno - I never needed to do that! If one only wants to change a value near the end of a block, then one could load the final value, run the CRC in reverse over the old data, using the reverse polynomial, till a point before the value you want to change, change the value, then reverse direction and run forwards again with the normal polynomial and append the CRC as usual. If you want to add something to the beginning of the table, it becomes a different matter. In general, it may be easier to recalc the CRC on the whole block, rather than trying to patch it! Cheers, Herman http://www.AerospaceSoftware.com john_stiekema@my-deja.com wrote: > > I have a similar problem. I would like to change a table in EEPROM and > still have the CRC verify correctly. > > It should be possible to provide an additional dummy table with some > "CRC correction bytes", which would bring the CRC back to the original > value, so that the table data could be modified as desired, provided > that the appropriate "correction bytes" are also modified. > > Question is, how does one go about determining rules to generate the > correction bytes, for any given table data? > > I assume that at least the following information would be required: > - Initialisation CRC (CRC calculated to beginning of table) > - Static bytes between table and dummy table, assuming dummy table does > not directly follow the first table in memory. > - Initial bytes in table, and dummy table > > Any ideas, Herman? > > In article <3A28514B.7F695805@AerospaceSoftware.com>, > Herman Oosthuysen <aerosoft@AerospaceSoftware.com> wrote: > > Well, you can run a CRC forwards and reverse. The reverse is actually > a > > different polynomial. See DSP Guru for the trick, but basically you > > just take the (order - power) for each term to get the other > > polynomial. You should be able to use this info to gen a CRC patch - > I > > dunno how though, but I think it would be workable. If you get > > completely stuck, drop me some mail, I know a few tricks. > > > > Cheers, > > > > Herman > > http://www.AerospaceSoftware.com > > > > Marc Warden wrote: > > > > > > Michael Barr wrote: > > > > > > > I've just (finally) gotten around to posting a three-part article > I > > > > wrote about a year ago on computing checksums and CRCs and the > source > > > > code that goes with it. The URLs of the three articles are: > > > > > > > > http://www.netrino.com/Connecting/1999-11/ > > > > http://www.netrino.com/Connecting/1999-12/ > > > > http://www.netrino.com/Connecting/2000-01/ > > > > > > > > If you're new to the subject, I recommend reading them in order. > If, > > > > however, you are familiar with the theory of checksums and CRCs > and just > > > > want to get directly into the CRC implementation, you can just > read the > > > > third. > > > > > > > > A ZIP file containing just the source code for the CRC routines is > at: > > > > > > > > http://www.netrino.com/Connecting/2000-01/crc.zip > > > > > > > > The code is placed into the public domain and may be used for any > purpose > > > > public or private. There are some limitations in its use (it's > written > > > > in C), but the underlying algorithms are solid and could be ported > to the > > > > assembly language (or hardware) of your choice if necessary. > > > > > > > > Enjoy, > > > > Michael Barr > > > > > > Hi Michael. > > > > > > Question for you: Have you ever come across a method in a CRC of > removing a > > > byte, word, or long from the block of data, changing it (on purpose) > and > > > putting it back into the block of data (in its same location) and > then > > > modifying the CRC and if the CRC is checked it will check out OK? > > > > > > That is, I don't want to have to modify the data location and then > > > recalculate the CRC on the whole block of data, but would like to > have the > > > CRC verify. > > > > > > The data is code being run in 'real time' and because it was written > for one > > > processor but being run on a new processor (the code is down loaded > into the > > > new processor's address space) and before the data/code is run, it > is patched > > > to address some instruction differences between teh original CPU > target vs. > > > the new one. > > > > > > Right now I'm patching the code/data and have disabled CRC checking > (because > > > I know it will fail and cause the system to halt any further > processing) but > > > I would like to (if possible) re-enable CRC checking (to catch > unententional > > > changes to the code/data) but have the checking insensitive to > intentional > > > changes to a few locations in the code/data. > > > > > > I know I know. No matter how I put it, it sounds goofy... > > > > > > Sincerely, > > > > > > MarcW. (And it is.) > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 27702
Neil Franklin wrote: > JBits for the XS40? Xilinx says JBits is not for XC4000 (it once was, > but this support has been dropped). > > Hmmm, I just went to http://www.xess.com/ho03000.html (Example Designs). > There are Jbits XHWIF for XS40-005XL and XSV-100. Does Xilinx not even > know its own software? Looks like tomorrow is going to be interesting. These examples of XHWIF ports are written by Gordon Hollingworth from the University of York, England. They are nothing to do with Xilinx, though they do use the architecture independent XHWIF interface from Xilinx. And as far as I know, Gordon works on evolvable hardware for Virtex: the original poster should maybe talk to him for some more hints and tips. As you correctly point out, JBits for the 4k is no longer supported. But there still is a ton of software floating out there that uses this API. My advice would be to go Virtex, and use the latest (and greatest) version of JBits for any new projects. Phil -- --------------------------------------------------------------------- __ / /\/ Dr Phil James-Roxby Direct Dial: 303-544-5545 \ \ Staff Software Engineer Fax: Unreliable use email :-) / / Loki/DARPA Email: phil.james-roxby@xilinx.com \_\/\ Xilinx Boulder ---------------------------------------------------------------------Article: 27703
Kent Orthner wrote: > On a side note, when I look at the CY Muxes, do you know what the 'BX' > input is, and what it's for? I'm presuming you mean the BX input of the CLB. The BX input is used to inject a constant 0 or 1 into the carry chain. If no signal is connected to the BX input, it is pulled high. Then by passing this high through a configurable buffer/invertor, you can get a 0 or 1. BX is also used as the select line for the F5 mux, and finally acts as the data input when using the LUT as a shift register or a RAM. Phil -- --------------------------------------------------------------------- __ / /\/ Dr Phil James-Roxby Direct Dial: 303-544-5545 \ \ Staff Software Engineer Fax: Unreliable use email :-) / / Loki/DARPA Email: phil.james-roxby@xilinx.com \_\/\ Xilinx Boulder ---------------------------------------------------------------------Article: 27704
There is such a method. As I recall it was published 8-12 years ago by some folks from DEC. The article describes a procedure to modify a message and then repair the CRC without recomputing it over the entire message. I have a copy of the article somewhere in my office ... no futher than 10 feet from where I'm sitting now. I will post details if I find it before the sun burns out. Marc Warden wrote: > Question for you: Have you ever come across a method in a CRC of removing a > byte, word, or long from the block of data, changing it (on purpose) and > putting it back into the block of data (in its same location) and then > modifying the CRC and if the CRC is checked it will check out OK? > > That is, I don't want to have to modify the data location and then > recalculate the CRC on the whole block of data, but would like to have the > CRC verify. > > The data is code being run in 'real time' and because it was written for one > processor but being run on a new processor (the code is down loaded into the > new processor's address space) and before the data/code is run, it is patched > to address some instruction differences between teh original CPU target vs. > the new one. > > Right now I'm patching the code/data and have disabled CRC checking (because > I know it will fail and cause the system to halt any further processing) but > I would like to (if possible) re-enable CRC checking (to catch unententional > changes to the code/data) but have the checking insensitive to intentional > changes to a few locations in the code/data. > > I know I know. No matter how I put it, it sounds goofy... > > Sincerely, > > MarcW. (And it is.)Article: 27705
Neil Franklin wrote: > Mail to the address given on the page (JBits@xilinx.com). They then > send you an URL (actually 3 URLs, Windows NT, Solaris, Linux) plus > password. Then download (9MByte), install and have fun. That address is also the one to use for general queries about JBits to see if its going to work for your particular app., and for support once you've installed it. And yes, you will have fun. I had so much I joined the company. Phil -- --------------------------------------------------------------------- __ / /\/ Dr Phil James-Roxby Direct Dial: 303-544-5545 \ \ Staff Software Engineer Fax: Unreliable use email :-) / / Loki/DARPA Email: phil.james-roxby@xilinx.com \_\/\ Xilinx Boulder ---------------------------------------------------------------------Article: 27706
Has Xilinx made a strategic decision to limit Spartan II available ? Or, has Xilinx failed to meet the Spartan II availability expectations of its customers because of technical reasons ? The pricing is so low on the Spartan II, I always felt that they were harming their bottom line. Spartan II pricing seemed a little ahead of the market and themselves. It seemed reasonable to push back their availablility untill competitive forces made their mass availability a necessity. Yes new lines are announced ahead of availability. This time though something is up. Strategic decision or technical problems ? Comments ? Sincerely Daniel DeConinck High Res Technologies, Inc.Article: 27707
Got it! Here's the bibliographic citation. Perhaps somebody has time to look for an online copy. Irvin, David R. "Preserving the integrity of cyclic-redundancy checks when protected text is intentionally altered." IBM J. Res. Develop., Vol. 33, No. 6, November 1989, pp 618-626. Copyright 1989 by International Business Machines Corporation. Did I say DEC? I meant IBM. Abstract As a digitally encoded message traverses a series of point-to-point communication links, it may be necessary to change the contents of that message at an intermediate station. If bit errors are introduced by the intermediary while the text is unprotected, these errors will be subsequently undetectable by cyclic redundancy checks. An algorithm is presented here for ensuring that such errors will not go undetected. Since the cyclic redundancy check is based on a linear mathematical operation, the frame-check sequence may be modifed, rather than recalculated, by each intermediary changing the protected text. A frame-check sequence constructed in this way will reveal any errors introduced in the transmission path when the message is finally examined at the ultimate destination. Examples of the proposed technique applied to various local-area network bridges are developed. The technique is shown to be beneficial in these examples when the internal bit-error ratio of the text-changing device exceeds 10^(-19) on unprotected paths. Don Bockenfeld wrote: > There is such a method. As I recall it was published 8-12 years ago by some > folks > from DEC. The article describes a procedure to modify a message and then repair > > the CRC without recomputing it over the entire message. > > I have a copy of the article somewhere in my office ... no futher than 10 feet > from > where I'm sitting now. I will post details if I find it before the sun burns > out. > > Marc Warden wrote: > > > Question for you: Have you ever come across a method in a CRC of removing a > > byte, word, or long from the block of data, changing it (on purpose) and > > putting it back into the block of data (in its same location) and then > > modifying the CRC and if the CRC is checked it will check out OK? > > > > That is, I don't want to have to modify the data location and then > > recalculate the CRC on the whole block of data, but would like to have the > > CRC verify. > > > > The data is code being run in 'real time' and because it was written for one > > processor but being run on a new processor (the code is down loaded into the > > new processor's address space) and before the data/code is run, it is patched > > to address some instruction differences between teh original CPU target vs. > > the new one. > > > > Right now I'm patching the code/data and have disabled CRC checking (because > > I know it will fail and cause the system to halt any further processing) but > > I would like to (if possible) re-enable CRC checking (to catch unententional > > changes to the code/data) but have the checking insensitive to intentional > > changes to a few locations in the code/data. > > > > I know I know. No matter how I put it, it sounds goofy... > > > > Sincerely, > > > > MarcW. (And it is.)Article: 27708
On Mon, 04 Dec 2000 08:33:52 +0000, Nial Stewart <nials@sqf.hp.com> wrote: >One thing to look out for with Altera devices/tools is unused pins. > >With the Xilinx tools if a pin in unused it is tri-stated, but with >the Altera tools it's arbitrarily connected to an internal net and >driven out. Are you sure about the "arbitrarily" part ? My experience has been that they were driven to zero but I haven't verified that it was actually the case but I am pretty sure I didn't have any randomly changing unconnected pins. If you want your pins to be tri-stated in Altera (at least Flex 10K), you can put them in the ACF. If they are missing from the design EDF, Max+Plus2 will tri-state them. Driving zero has some sense too. If you don't pull-up/down your pins and they are tri-stated, you might get arbitrarily large currents in in the floating driver. The issue is that Xilinx parts have pull-ups, and Altera parts don't. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 27709
Don Bockenfeld <donbock@fltvis.com> writes: > Got it! Here's the bibliographic citation. Perhaps somebody has time > to look for an online copy. > > Irvin, David R. "Preserving the integrity of cyclic-redundancy checks when > protected text is intentionally altered." IBM J. Res. Develop., Vol. 33, > No. 6, November 1989, pp 618-626. Copyright 1989 by International > Business Machines Corporation. Check out the patent (if you want to pay for it) on: http://www.delphion.com/details?&pn10=US05121396 Ciao, Peter K. -- Peter J. Kootsookos Wb: www.clubi.ie/PeterK "Here comes the future and you can't run from it, If you've got a blacklist I want to be on it" - 'Waiting for the great leap forwards', Billy BraggArticle: 27710
gazit@my-deja.com wrote: > > Hi, > I am working on a new design , using XCV400-BG560. > How can I find out (except looking at the Pin-out symbol diagram) which > I/O pin belongs to each of the banks ? The data sheet for the part will tell you. > Is there a source for Orcad symbols for Virtex family parts or do I > need to generate my own ?. I always generate my own FPGA symbols. Instead of one big block with 560 pins, I break the symbol up into multiple logical symbols (SDRAM controller, local interface, clocks/reset/power, test points, etc.) It's much easier to read. -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27711
Let me address the two concerns: SpartanII availability through distribution is limited because these devices are being snapped up by the major customers at a faster rate than we expected. Xilinx will ship about a million SpartanII devices this quarter, so these are not sample quantities. They just don't make in onto the distributor shelves in sufficient numbers. This may not help you much, but it shows that there really is no fundamental problem. It's "just" excessive demand... Start-up current at low temperatures is higher than we and you like it to be, but remember: There is no reliability issue here. The current is widely distributed on the chip, and lasts for milliseconds only. So neither heat nor metal migration are an issue. You "just" have to design the power supply and regulator appropriately. I thought you might appreciate a straight answer... Peter Alfke, Xilinx Applications ============================= Rick Collins wrote: > I am starting a new board design where I wanted to use the SpartanII > FPGAs. But I am not sure if I should continue with these parts or change > to another. According to a January press release, the SpartanII chips > were supposed to be in full production "within the current quarter". > Here it is nearly a year later and they are still not listed as being > readily available at distributors. The latest data sheet (Nov 2, 2000) > is still labeled as "Preliminary". > > The other problem I have is with the high startup current these parts > require. I need to be able to sell these boards for an industrial (-40C > to 85C) temp range. At startup in this range, the four parts on this > board will require 2 amps from the 2.5 volt supply. Otherwise this > supply only needs to be built to handle 1 amp including power to spare. > I have seen several posts here that seem to indicate that the startup > current requirement may be spec'd a little more tightly when these parts > are in fully qualified. > > Does anyone have an idea of when these parts will be fully qualified and > in full production? I have been burned before trying to use parts that > are new and not available. But these parts are "just what the doctor > ordered" other than these two issues. > > I know that Lucent has no plans for product to compete with SpartanII at > the low end. Does anyone know if Altera is introducing a similar low > cost, high density family of parts? > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > URL http://www.arius.comArticle: 27712
Muzaffer Kal wrote: > > On Mon, 04 Dec 2000 08:33:52 +0000, Nial Stewart <nials@sqf.hp.com> > wrote: > >One thing to look out for with Altera devices/tools is unused pins. > > > >With the Xilinx tools if a pin in unused it is tri-stated, but with > >the Altera tools it's arbitrarily connected to an internal net and > >driven out. > > Are you sure about the "arbitrarily" part ? My experience has been > that they were driven to zero but I haven't verified that it was > actually the case but I am pretty sure I didn't have any randomly > changing unconnected pins. Aye you're probably right, but they are _driven_ out, not just weak pull downs. > If you want your pins to be tri-stated in Altera (at least Flex 10K), > you can put them in the ACF. If they are missing from the design EDF, > Max+Plus2 will tri-state them. Are you _sure_ about that? I'm sure I've seen unassigned Flex 10K pins driven out. I'm almost defenite I've seen it on a Max7000 device. > Driving zero has some sense too. If you don't pull-up/down your pins > and they are tri-stated, you might get arbitrarily large currents in > in the floating driver. The issue is that Xilinx parts have pull-ups, > and Altera parts don't. I agree that you can't have unassigned pins 'floating', but weak pull ups/downs would seem to be a more sensible solution. Nial.Article: 27713
This is a multi-part message in MIME format. --------------262029F309552194B3AD5103 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Rotem, Xilinx does not provide Orcad symbols for the Virtex or any other device. I have attached a text file that you may find helpful, however. It is a text representation of the pin out symbol in the data book. Hope this helps, John gazit@my-deja.com wrote: > Hi, > I am working on a new design , using XCV400-BG560. > How can I find out (except looking at the Pin-out symbol diagram) which > I/O pin belongs to each of the banks ? > Is there a source for Orcad symbols for Virtex family parts or do I > need to generate my own ?. > Thanks, > Rotem. > > Sent via Deja.com http://www.deja.com/ > Before you buy. --------------262029F309552194B3AD5103 Content-Type: text/plain; charset=us-ascii; name="v400bg560.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v400bg560.txt" package v400bg560 1 0 1 0 Physical Row/Col-RAM Package VCCO IO Name Location Name Bank Type -------- ----------- ------- ----- --------- VCCO --- VCCO_7 7 VCCO_7 VCCO --- VCCO_0 0 VCCO_0 TCK --- E29 - TCK PAD2 R1C1 D30 0 IO PAD4 R1C2 E28 0 IO PAD5 R1C3 D29 0 IO PAD6 R1C3 C30 0 IO PAD7 R1C4 D28 0 IO PAD8 R1C4 A31 0 IO GND --- GND - GND VCCO --- VCCO_0 0 VCCO_0 PAD9 R1C5 E27 0 IO_VREF_0 PAD10 R1C5 C29 0 IO PAD12 R1C6 B30 0 IO PAD13 R1C7 D27 0 IO PAD14 R1C7 C28 0 IO PAD15 R1C8 E26 0 IO PAD16 R1C8 B29 0 IO GND --- GND - GND VCCO --- VCCO_0 0 VCCO_0 VCCINT --- B28 - VCCINT PAD17 R1C9 D26 0 IO_VREF_0 PAD18 R1C9 C27 0 IO PAD19 R1C10 E25 0 IO PAD20 R1C10 A28 0 IO PAD21 R1C11 A27 0 IO PAD22 R1C11 D25 0 IO PAD23 R1C12 C26 0 IO GND --- GND - GND VCCO --- VCCO_0 0 VCCO_0 PAD24 R1C12 E24 0 IO PAD25 R1C13 B26 0 IO PAD26 R1C13 C25 0 IO PAD27 R1C14 D24 0 IO PAD28 R1C14 B25 0 IO PAD29 R1C15 E23 0 IO_VREF_0 PAD30 R1C15 A25 0 IO GND --- GND - GND VCCO --- VCCO_0 0 VCCO_0 VCCINT --- C24 - VCCINT PAD31 R1C16 D23 0 IO PAD32 R1C16 B24 0 IO PAD34 R1C17 E22 0 IO PAD35 R1C18 C23 0 IO PAD37 R1C19 A23 0 IO PAD38 R1C19 D22 0 IO GND --- GND - GND VCCO --- VCCO_0 0 NOPAD VCCINT --- C22 - VCCINT PAD39 R1C20 E21 0 IO PAD40 R1C20 B22 0 IO PAD42 R1C21 D21 0 IO PAD43 R1C22 C21 0 IO PAD45 R1C23 B21 0 IO PAD46 R1C23 E20 0 IO GND --- GND - GND VCCO --- VCCO_0 0 VCCO_0 VCCINT --- A21 - VCCINT PAD47 R1C24 D20 0 IO_VREF_0 PAD48 R1C24 C20 0 IO PAD49 R1C25 B20 0 IO PAD50 R1C25 E19 0 IO PAD52 R1C26 D19 0 IO PAD53 R1C27 C19 0 IO GND --- GND - GND VCCO --- VCCO_0 0 NOPAD PAD54 R1C27 A19 0 IO_VREF_0 PAD55 R1C28 D18 0 IO PAD56 R1C28 E18 0 IO PAD57 R1C29 C18 0 IO VCCINT --- B18 - VCCINT GCLKPAD3 --- A17 0 GCK3 VCCO --- VCCO_0 0 VCCO_0 VCCO --- VCCO_1 1 VCCO_1 GND --- GND - GND GCLKPAD2 --- D17 1 GCK2 PAD62 R1C31 E17 1 IO PAD64 R1C32 C17 1 IO PAD65 R1C33 B17 1 IO PAD66 R1C33 B16 1 IO PAD67 R1C34 D16 1 IO_VREF_1 VCCO --- VCCO_1 1 NOPAD GND --- GND - GND PAD68 R1C34 E16 1 IO PAD69 R1C35 C16 1 IO PAD71 R1C36 A15 1 IO PAD72 R1C36 C15 1 IO PAD73 R1C37 D15 1 IO PAD74 R1C37 E15 1 IO_VREF_1 VCCINT --- B14 - VCCINT VCCO --- VCCO_1 1 VCCO_1 GND --- GND - GND PAD75 R1C38 C14 1 IO PAD76 R1C38 D14 1 IO PAD78 R1C39 A13 1 IO PAD79 R1C40 E14 1 IO PAD81 R1C41 C13 1 IO PAD82 R1C41 D13 1 IO VCCINT --- B12 - VCCINT VCCO --- VCCO_1 1 NOPAD GND --- GND - GND PAD83 R1C42 C12 1 IO PAD84 R1C42 E13 1 IO PAD86 R1C43 A11 1 IO PAD87 R1C44 D12 1 IO PAD89 R1C45 B11 1 IO PAD90 R1C45 C11 1 IO VCCINT --- E12 - VCCINT VCCO --- VCCO_1 1 VCCO_1 GND --- GND - GND PAD91 R1C46 B10 1 IO PAD92 R1C46 D11 1 IO_VREF_1 PAD93 R1C47 C10 1 IO PAD94 R1C47 A9 1 IO PAD95 R1C48 E11 1 IO PAD96 R1C48 C9 1 IO PAD97 R1C49 D10 1 IO VCCO --- VCCO_1 1 VCCO_1 GND --- GND - GND PAD98 R1C49 A8 1 IO PAD99 R1C50 B8 1 IO PAD100 R1C50 E10 1 IO PAD101 R1C51 C8 1 IO PAD102 R1C51 D9 1 IO PAD103 R1C52 B7 1 IO PAD104 R1C52 A6 1 IO_VREF_1 VCCINT --- E9 - VCCINT VCCO --- VCCO_1 1 VCCO_1 GND --- GND - GND PAD105 R1C53 C7 1 IO PAD106 R1C53 D8 1 IO PAD107 R1C54 A5 1 IO PAD108 R1C54 B5 1 IO PAD109 R1C55 E8 1 IO PAD111 R1C56 C6 1 IO PAD112 R1C56 D7 1 IO_VREF_1 VCCO --- VCCO_1 1 VCCO_1 GND --- GND - GND PAD113 R1C57 A4 1 IO PAD114 R1C57 B4 1 IO PAD115 R1C58 C5 1 IO PAD116 R1C58 E7 1 IO PAD117 R1C59 A3 1 IO PAD119 R1C60 D6 1 IO_WRITE PAD120 R1C60 A2 1 IO_CS TDI --- D5 - TDI GND --- GND - GND TDO --- E6 - TDO VCCO --- VCCO_1 1 VCCO_1 VCCO --- VCCO_2 2 VCCO_2 CCLK --- C4 - CCLK PAD121 R1C60-0 D4 2 IO_DOUT_BUSY PAD122 R1C60-0 E4 2 IO_DIN_D0 PAD124 R2C60-0 F5 2 IO PAD125 R2C60-0 B3 2 IO PAD126 R2C60-0 D3 2 IO PAD127 R3C60-0 F4 2 IO PAD128 R3C60-0 C1 2 IO GND --- GND - GND VCCO --- VCCO_2 2 VCCO_2 PAD129 R3C60-0 G5 2 IO_VREF_2 PAD130 R4C60-0 E3 2 IO PAD132 R4C60-0 D2 2 IO PAD133 R5C60-1 G4 2 IO PAD134 R5C60-1 F3 2 IO GND --- GND - GND PAD135 R5C60-1 H5 2 IO PAD136 R6C60-1 E2 2 IO GND --- GND - GND VCCO --- VCCO_2 2 VCCO_2 VCCINT --- F2 - VCCINT PAD137 R6C60-1 H4 2 IO_VREF_2 PAD138 R6C60-1 G3 2 IO PAD139 R7C60-1 J5 2 IO PAD140 R7C60-1 F1 2 IO PAD141 R7C60-1 G1 2 IO PAD142 R8C60-1 J4 2 IO PAD143 R8C60-1 H3 2 IO GND --- GND - GND VCCO --- VCCO_2 2 VCCO_2 PAD144 R8C60-1 K5 2 IO PAD145 R9C60-2 H2 2 IO PAD146 R9C60-2 J3 2 IO PAD147 R9C60-2 K4 2 IO PAD148 R10C60-2 J2 2 IO PAD149 R10C60-2 L5 2 IO_VREF_2 PAD150 R10C60-2 K3 2 IO_D1 GND --- GND - GND VCCO --- VCCO_2 2 VCCO_2 VCCINT --- J1 - VCCINT PAD151 R11C60-2 L4 2 IO_D2 PAD152 R11C60-2 K2 2 IO PAD154 R12C60-2 M5 2 IO PAD155 R12C60-2 L3 2 IO PAD157 R13C60-3 L1 2 IO PAD158 R13C60-3 M4 2 IO GND --- GND - GND VCCO --- VCCO_2 2 NOPAD VCCINT --- M3 - VCCINT PAD159 R13C60-3 N5 2 IO PAD160 R14C60-3 M2 2 IO PAD162 R14C60-3 N4 2 IO PAD163 R15C60-3 N3 2 IO GND --- GND - GND PAD165 R15C60-3 N2 2 IO PAD166 R16C60-3 P5 2 IO GND --- GND - GND VCCO --- VCCO_2 2 VCCO_2 VCCINT --- N1 - VCCINT PAD167 R16C60-3 P4 2 IO_VREF_2 PAD168 R16C60-3 P3 2 IO_D3 PAD169 R17C60-4 P2 2 IO PAD170 R17C60-4 R5 2 IO PAD172 R18C60-4 R4 2 IO PAD173 R18C60-4 R3 2 IO GND --- GND - GND VCCO --- VCCO_2 2 NOPAD PAD174 R18C60-4 R1 2 IO_VREF_2 PAD175 R19C60-4 T4 2 IO PAD176 R19C60-4 T5 2 IO PAD177 R19C60-4 T3 2 IO PAD179 R20C60-4 T2 2 IO PAD180 R20C60-4 U3 2 IO_IRDY GND --- GND - GND VCCO --- VCCO_2 2 VCCO_2 VCCO --- VCCO_3 3 VCCO_3 PAD181 R21C60-5 U4 3 IO_TRDY VCCINT --- U5 - VCCINT PAD184 R22C60-5 U1 3 IO PAD185 R22C60-5 U2 3 IO PAD186 R22C60-5 V2 3 IO PAD187 R23C60-5 V4 3 IO_VREF_3 VCCO --- VCCO_3 3 NOPAD GND --- GND - GND PAD188 R23C60-5 V5 3 IO PAD189 R23C60-5 V3 3 IO PAD191 R24C60-5 W1 3 IO PAD192 R24C60-5 W3 3 IO PAD193 R25C60-6 W4 3 IO_D4 PAD194 R25C60-6 W5 3 IO_VREF_3 VCCINT --- Y2 - VCCINT VCCO --- VCCO_3 3 VCCO_3 GND --- GND - GND PAD195 R25C60-6 Y3 3 IO PAD196 R26C60-6 Y4 3 IO GND --- GND - GND PAD198 R26C60-6 AA1 3 IO PAD199 R27C60-6 Y5 3 IO PAD201 R27C60-6 AA3 3 IO PAD202 R28C60-6 AA4 3 IO VCCINT --- AB2 - VCCINT VCCO --- VCCO_3 3 NOPAD GND --- GND - GND PAD203 R28C60-6 AB3 3 IO PAD204 R28C60-6 AA5 3 IO PAD206 R29C60-7 AC1 3 IO PAD207 R29C60-7 AB4 3 IO PAD209 R30C60-7 AC3 3 IO PAD210 R30C60-7 AB5 3 IO_D5 VCCINT --- AD2 - VCCINT VCCO --- VCCO_3 3 VCCO_3 GND --- GND - GND PAD211 R31C60-7 AC4 3 IO_D6 PAD212 R31C60-7 AD3 3 IO_VREF_3 PAD213 R31C60-7 AE1 3 IO PAD214 R32C60-7 AC5 3 IO PAD215 R32C60-7 AE3 3 IO PAD216 R32C60-7 AD4 3 IO PAD217 R33C60-8 AF1 3 IO VCCO --- VCCO_3 3 VCCO_3 GND --- GND - GND PAD218 R33C60-8 AF2 3 IO PAD219 R33C60-8 AD5 3 IO PAD220 R34C60-8 AG2 3 IO PAD221 R34C60-8 AE4 3 IO PAD222 R34C60-8 AF3 3 IO PAD223 R35C60-8 AH1 3 IO PAD224 R35C60-8 AE5 3 IO_VREF_3 VCCINT --- AG3 - VCCINT VCCO --- VCCO_3 3 VCCO_3 GND --- GND - GND PAD225 R35C60-8 AF4 3 IO PAD226 R36C60-8 AJ1 3 IO GND --- GND - GND PAD227 R36C60-8 AJ2 3 IO PAD228 R36C60-8 AF5 3 IO PAD229 R37C60-9 AH3 3 IO PAD231 R37C60-9 AG4 3 IO PAD232 R38C60-9 AK2 3 IO_VREF_3 VCCO --- VCCO_3 3 VCCO_3 GND --- GND - GND PAD233 R38C60-9 AJ3 3 IO PAD234 R38C60-9 AG5 3 IO PAD235 R39C60-9 AL1 3 IO PAD236 R39C60-9 AH4 3 IO PAD237 R39C60-9 AK3 3 IO PAD239 R40C60-9 AJ4 3 IO_D7 PAD240 R40C60-9 AH5 3 IO_INIT PROGRAM --- AM1 - PROGRAM VCCO --- VCCO_3 3 VCCO_3 VCCO --- VCCO_4 4 VCCO_4 DONE --- AJ5 - DONE GND --- GND - GND PAD241 R40C60 AL4 4 IO PAD242 R40C60 AJ6 4 IO PAD244 R40C59 AK5 4 IO PAD245 R40C58 AN3 4 IO PAD246 R40C58 AK6 4 IO PAD247 R40C57 AL5 4 IO PAD248 R40C57 AJ7 4 IO GND --- GND - GND VCCO --- VCCO_4 4 VCCO_4 PAD249 R40C56 AM4 4 IO_VREF_4 PAD250 R40C56 AM5 4 IO PAD252 R40C55 AK7 4 IO PAD253 R40C54 AL6 4 IO PAD254 R40C54 AJ8 4 IO PAD255 R40C53 AM6 4 IO PAD256 R40C53 AN6 4 IO GND --- GND - GND VCCO --- VCCO_4 4 VCCO_4 VCCINT --- AK8 - VCCINT PAD257 R40C52 AL7 4 IO_VREF_4 PAD258 R40C52 AJ9 4 IO PAD259 R40C51 AN7 4 IO PAD260 R40C51 AL8 4 IO PAD261 R40C50 AK9 4 IO PAD262 R40C50 AM8 4 IO PAD263 R40C49 AJ10 4 IO GND --- GND - GND VCCO --- VCCO_4 4 VCCO_4 PAD264 R40C49 AL9 4 IO PAD265 R40C48 AM9 4 IO PAD266 R40C48 AK10 4 IO PAD267 R40C47 AN9 4 IO PAD268 R40C47 AJ11 4 IO PAD269 R40C46 AL10 4 IO_VREF_4 PAD270 R40C46 AM10 4 IO GND --- GND - GND VCCO --- VCCO_4 4 VCCO_4 VCCINT --- AK11 - VCCINT PAD271 R40C45 AL11 4 IO PAD272 R40C45 AJ12 4 IO PAD274 R40C44 AN11 4 IO PAD275 R40C43 AK12 4 IO PAD277 R40C42 AL12 4 IO PAD278 R40C42 AM12 4 IO GND --- GND - GND VCCO --- VCCO_4 4 NOPAD VCCINT --- AJ13 - VCCINT PAD279 R40C41 AK13 4 IO PAD280 R40C41 AL13 4 IO PAD282 R40C40 AM13 4 IO PAD283 R40C39 AN13 4 IO PAD285 R40C38 AJ14 4 IO PAD286 R40C38 AK14 4 IO GND --- GND - GND VCCO --- VCCO_4 4 VCCO_4 VCCINT --- AL14 - VCCINT PAD287 R40C37 AM14 4 IO_VREF_4 PAD288 R40C37 AN15 4 IO PAD289 R40C36 AJ15 4 IO PAD290 R40C36 AK15 4 IO PAD292 R40C35 AL15 4 IO PAD293 R40C34 AM16 4 IO GND --- GND - GND VCCO --- VCCO_4 4 NOPAD PAD294 R40C34 AL16 4 IO_VREF_4 PAD295 R40C33 AJ16 4 IO PAD296 R40C33 AK16 4 IO PAD297 R40C32 AN17 4 IO PAD299 R40C31 AM17 4 IO GCLKPAD0 --- AL17 4 GCK0 GND --- GND - GND VCCO --- VCCO_4 4 VCCO_4 VCCO --- VCCO_5 5 VCCO_5 GCLKPAD1 --- AJ17 5 GCK1 VCCINT --- AK17 - VCCINT PAD304 R40C29 AM18 5 IO PAD305 R40C28 AL18 5 IO PAD306 R40C28 AK18 5 IO PAD307 R40C27 AJ18 5 IO_VREF_5 VCCO --- VCCO_5 5 NOPAD GND --- GND - GND PAD308 R40C27 AN19 5 IO PAD309 R40C26 AL19 5 IO PAD311 R40C25 AK19 5 IO PAD312 R40C25 AM20 5 IO PAD313 R40C24 AJ19 5 IO PAD314 R40C24 AL20 5 IO_VREF_5 VCCINT --- AK20 - VCCINT VCCO --- VCCO_5 5 VCCO_5 GND --- GND - GND PAD315 R40C23 AN21 5 IO PAD316 R40C23 AL21 5 IO PAD318 R40C22 AJ20 5 IO PAD319 R40C21 AM22 5 IO PAD321 R40C20 AK21 5 IO PAD322 R40C20 AN23 5 IO VCCINT --- AL22 - VCCINT VCCO --- VCCO_5 5 NOPAD GND --- GND - GND PAD323 R40C19 AJ21 5 IO PAD324 R40C19 AM23 5 IO PAD326 R40C18 AK22 5 IO PAD327 R40C17 AM24 5 IO PAD329 R40C16 AL23 5 IO PAD330 R40C16 AJ22 5 IO VCCINT --- AN25 - VCCINT VCCO --- VCCO_5 5 VCCO_5 GND --- GND - GND PAD331 R40C15 AK23 5 IO PAD332 R40C15 AL24 5 IO_VREF_5 PAD333 R40C14 AN26 5 IO PAD334 R40C14 AJ23 5 IO PAD335 R40C13 AL25 5 IO PAD336 R40C13 AK24 5 IO PAD337 R40C12 AM26 5 IO VCCO --- VCCO_5 5 VCCO_5 GND --- GND - GND PAD338 R40C12 AM27 5 IO PAD339 R40C11 AJ24 5 IO PAD340 R40C11 AL26 5 IO PAD341 R40C10 AK25 5 IO PAD342 R40C10 AN28 5 IO PAD343 R40C9 AN29 5 IO PAD344 R40C9 AJ25 5 IO_VREF_5 VCCINT --- AL27 - VCCINT VCCO --- VCCO_5 5 VCCO_5 GND --- GND - GND PAD345 R40C8 AK26 5 IO PAD346 R40C8 AM29 5 IO PAD347 R40C7 AM30 5 IO PAD348 R40C7 AJ26 5 IO PAD349 R40C6 AL28 5 IO PAD351 R40C5 AK27 5 IO PAD352 R40C5 AL29 5 IO_VREF_5 VCCO --- VCCO_5 5 VCCO_5 GND --- GND - GND PAD353 R40C4 AN31 5 IO PAD354 R40C4 AJ27 5 IO PAD355 R40C3 AM31 5 IO PAD356 R40C3 AK28 5 IO PAD357 R40C2 AL30 5 IO DXN --- AK29 - DXN DXP --- AJ28 - DXP M2 --- AN32 - M2 VCCO --- VCCO_5 5 VCCO_5 VCCO --- VCCO_6 6 VCCO_6 M0 --- AJ29 - M0 GND --- GND - GND M1 --- AK30 - M1 PAD361 R40C1-9 AH29 6 IO PAD362 R40C1-9 AJ30 6 IO PAD364 R39C1-9 AK31 6 IO PAD365 R39C1-9 AH30 6 IO PAD366 R39C1-9 AL33 6 IO PAD367 R38C1-9 AG29 6 IO PAD368 R38C1-9 AJ31 6 IO GND --- GND - GND VCCO --- VCCO_6 6 VCCO_6 PAD369 R38C1-9 AK32 6 IO_VREF_6 PAD370 R37C1-9 AG30 6 IO PAD372 R37C1-9 AH31 6 IO PAD373 R36C1-8 AF29 6 IO PAD374 R36C1-8 AJ32 6 IO GND --- GND - GND PAD375 R36C1-8 AH32 6 IO PAD376 R35C1-8 AF30 6 IO GND --- GND - GND VCCO --- VCCO_6 6 VCCO_6 VCCINT --- AG31 - VCCINT PAD377 R35C1-8 AE29 6 IO_VREF_6 PAD378 R35C1-8 AH33 6 IO PAD379 R34C1-8 AG33 6 IO PAD380 R34C1-8 AE30 6 IO PAD381 R34C1-8 AF31 6 IO PAD382 R33C1-8 AD29 6 IO PAD383 R33C1-8 AF32 6 IO GND --- GND - GND VCCO --- VCCO_6 6 VCCO_6 PAD384 R33C1-8 AE31 6 IO PAD385 R32C1-7 AD30 6 IO PAD386 R32C1-7 AE32 6 IO PAD387 R32C1-7 AC29 6 IO PAD388 R31C1-7 AE33 6 IO PAD389 R31C1-7 AD31 6 IO_VREF_6 PAD390 R31C1-7 AC30 6 IO GND --- GND - GND VCCO --- VCCO_6 6 VCCO_6 VCCINT --- AD32 - VCCINT PAD391 R30C1-7 AB29 6 IO PAD392 R30C1-7 AC31 6 IO PAD394 R29C1-7 AC33 6 IO PAD395 R29C1-7 AB30 6 IO PAD397 R28C1-6 AB31 6 IO PAD398 R28C1-6 AA29 6 IO GND --- GND - GND VCCO --- VCCO_6 6 NOPAD VCCINT --- AB32 - VCCINT PAD399 R28C1-6 AA30 6 IO PAD400 R27C1-6 AA31 6 IO PAD402 R27C1-6 AA32 6 IO PAD403 R26C1-6 Y29 6 IO GND --- GND - GND PAD405 R26C1-6 AA33 6 IO PAD406 R25C1-6 Y30 6 IO GND --- GND - GND VCCO --- VCCO_6 6 VCCO_6 VCCINT --- Y31 - VCCINT PAD407 R25C1-6 Y32 6 IO_VREF_6 PAD408 R25C1-6 W29 6 IO PAD409 R24C1-5 W30 6 IO PAD410 R24C1-5 W31 6 IO PAD412 R23C1-5 W33 6 IO PAD413 R23C1-5 V30 6 IO GND --- GND - GND VCCO --- VCCO_6 6 NOPAD PAD414 R23C1-5 V29 6 IO_VREF_6 PAD415 R22C1-5 V31 6 IO PAD416 R22C1-5 V32 6 IO PAD417 R22C1-5 U33 6 IO VCCINT --- U30 - VCCINT PAD420 R21C1-5 U29 6 IO_TRDY VCCO --- VCCO_6 6 VCCO_6 VCCO --- VCCO_7 7 VCCO_7 GND --- GND - GND PAD421 R20C1-4 U31 7 IO_IRDY PAD422 R20C1-4 U32 7 IO PAD424 R19C1-4 T32 7 IO PAD425 R19C1-4 T30 7 IO PAD426 R19C1-4 T29 7 IO PAD427 R18C1-4 T31 7 IO_VREF_7 VCCO --- VCCO_7 7 NOPAD GND --- GND - GND PAD428 R18C1-4 R33 7 IO PAD429 R18C1-4 R31 7 IO PAD431 R17C1-4 R30 7 IO PAD432 R17C1-4 R29 7 IO PAD433 R16C1-3 P32 7 IO PAD434 R16C1-3 P31 7 IO_VREF_7 VCCINT --- N33 - VCCINT VCCO --- VCCO_7 7 VCCO_7 GND --- GND - GND PAD435 R16C1-3 P30 7 IO PAD436 R15C1-3 P29 7 IO GND --- GND - GND PAD438 R15C1-3 M32 7 IO PAD439 R14C1-3 N31 7 IO PAD441 R14C1-3 N30 7 IO PAD442 R13C1-3 L33 7 IO VCCINT --- N29 - VCCINT VCCO --- VCCO_7 7 NOPAD GND --- GND - GND PAD443 R13C1-3 M31 7 IO PAD444 R13C1-3 L32 7 IO PAD446 R12C1-2 M30 7 IO PAD447 R12C1-2 L31 7 IO PAD449 R11C1-2 M29 7 IO PAD450 R11C1-2 J33 7 IO VCCINT --- K32 - VCCINT VCCO --- VCCO_7 7 VCCO_7 GND --- GND - GND PAD451 R10C1-2 L30 7 IO PAD452 R10C1-2 K31 7 IO_VREF_7 PAD453 R10C1-2 L29 7 IO PAD454 R9C1-2 H33 7 IO PAD455 R9C1-2 K30 7 IO PAD456 R9C1-2 J31 7 IO PAD457 R8C1-1 H32 7 IO VCCO --- VCCO_7 7 VCCO_7 GND --- GND - GND PAD458 R8C1-1 K29 7 IO PAD459 R8C1-1 H31 7 IO PAD460 R7C1-1 J30 7 IO PAD461 R7C1-1 G32 7 IO PAD462 R7C1-1 F33 7 IO PAD463 R6C1-1 J29 7 IO PAD464 R6C1-1 G31 7 IO_VREF_7 VCCINT --- H30 - VCCINT VCCO --- VCCO_7 7 VCCO_7 GND --- GND - GND PAD465 R6C1-1 E33 7 IO PAD466 R5C1-1 E32 7 IO GND --- GND - GND PAD467 R5C1-1 H29 7 IO PAD468 R5C1-1 F31 7 IO PAD469 R4C1-0 G30 7 IO PAD471 R4C1-0 D32 7 IO PAD472 R3C1-0 E31 7 IO_VREF_7 VCCO --- VCCO_7 7 VCCO_7 GND --- GND - GND PAD473 R3C1-0 G29 7 IO PAD474 R3C1-0 C33 7 IO PAD475 R2C1-0 F30 7 IO PAD476 R2C1-0 D31 7 IO PAD477 R2C1-0 E30 7 IO PAD479 R1C1-0 F29 7 IO TMS --- B33 - TMS GND --- GND - GND NC --- AL3 - NC NC --- AC2 - NC NC --- AK4 - NC NC --- C31 - NC VCCO_7 --- T33 - VCCO_7 VCCO_7 --- N32 - VCCO_7 VCCO_7 --- K33 - VCCO_7 VCCO_7 --- D33 - VCCO_7 VCCO_7 --- C32 - VCCO_7 VCCO_6 --- AM32 - VCCO_6 VCCO_6 --- AK33 - VCCO_6 VCCO_6 --- AF33 - VCCO_6 VCCO_6 --- AB33 - VCCO_6 VCCO_6 --- W32 - VCCO_6 VCCO_5 --- AN30 - VCCO_5 VCCO_5 --- AN24 - VCCO_5 VCCO_5 --- AN18 - VCCO_5 VCCO_5 --- AM21 - VCCO_5 VCCO_5 --- AL31 - VCCO_5 VCCO_4 --- AM15 - VCCO_4 VCCO_4 --- AN12 - VCCO_4 VCCO_4 --- AN8 - VCCO_4 VCCO_4 --- AN4 - VCCO_4 VCCO_4 --- AM2 - VCCO_4 VCCO_3 --- AL2 - VCCO_3 VCCO_3 --- AK1 - VCCO_3 VCCO_3 --- AD1 - VCCO_3 VCCO_3 --- AA2 - VCCO_3 VCCO_3 --- V1 - VCCO_3 VCCO_2 --- R2 - VCCO_2 VCCO_2 --- M1 - VCCO_2 VCCO_2 --- H1 - VCCO_2 VCCO_2 --- D1 - VCCO_2 VCCO_2 --- B2 - VCCO_2 VCCO_1 --- E5 - VCCO_1 VCCO_1 --- C3 - VCCO_1 VCCO_1 --- B13 - VCCO_1 VCCO_1 --- A16 - VCCO_1 VCCO_1 --- A10 - VCCO_1 VCCO_0 --- B32 - VCCO_0 VCCO_0 --- B19 - VCCO_0 VCCO_0 --- A30 - VCCO_0 VCCO_0 --- A26 - VCCO_0 VCCO_0 --- A22 - VCCO_0 GND --- AN33 - GND GND --- AN1 - GND GND --- A33 - GND GND --- A1 - GND GND --- AN27 - GND GND --- AN22 - GND GND --- AN20 - GND GND --- AN16 - GND GND --- AN14 - GND GND --- AN10 - GND GND --- AN5 - GND GND --- AN2 - GND GND --- AM7 - GND GND --- AM33 - GND GND --- AM28 - GND GND --- AM25 - GND GND --- AM19 - GND GND --- AM11 - GND GND --- AM3 - GND GND --- AL32 - GND GND --- AJ33 - GND GND --- AH2 - GND GND --- AG32 - GND GND --- AG1 - GND GND --- AE2 - GND GND --- AD33 - GND GND --- AC32 - GND GND --- AB1 - GND GND --- Y33 - GND GND --- Y1 - GND GND --- W2 - GND GND --- V33 - GND GND --- T1 - GND GND --- R32 - GND GND --- P33 - GND GND --- P1 - GND GND --- M33 - GND GND --- L2 - GND GND --- K1 - GND GND --- J32 - GND GND --- G33 - GND GND --- G2 - GND GND --- F32 - GND GND --- E1 - GND GND --- C2 - GND GND --- B31 - GND GND --- B27 - GND GND --- B23 - GND GND --- B15 - GND GND --- B9 - GND GND --- B6 - GND GND --- B1 - GND GND --- A32 - GND GND --- A29 - GND GND --- A24 - GND GND --- A20 - GND GND --- A18 - GND GND --- A14 - GND GND --- A12 - GND GND --- A7 - GND --------------262029F309552194B3AD5103--Article: 27714
On Mon, 04 Dec 2000 17:35:34 +0000, Nial Stewart <nials@sqf.hp.com> wrote: >> If you want your pins to be tri-stated in Altera (at least Flex 10K), >> you can put them in the ACF. If they are missing from the design EDF, >> Max+Plus2 will tri-state them. > >Are you _sure_ about that? I'm sure I've seen unassigned Flex 10K >pins driven out. I'm almost defenite I've seen it on a Max7000 device. As I said my experience is limited to Flex 10K but the critical bit was that you HAVE TO put the name of the pin (or any dummy name) into the ACF. This I remember very clearly because we had a tri-state bus which we didn't connect anymore. Removing it from the EDF & ACF caused them to be driven zero. ........ Now I remember; putting it into ACF doesn't help. You need to insert a line into the EDF and not have any drive to that pin. I am sure that adding a pin to EDF and not driving it causes Max+plus2 to tri-state it. This was the solution to our conflicting bus. Muzaffer FPGA DSP Consulting http://www.dspia.comArticle: 27715
Peter Alfke wrote: > Let me address the two concerns: > > SpartanII availability through distribution is limited because these > devices are being snapped up by the major customers at a faster rate than > we expected. Xilinx will ship about a million SpartanII devices this > quarter, so these are not sample quantities. They just don't make in onto > the distributor shelves in sufficient numbers. This may not help you much, > but it shows that there really is no fundamental problem. It's "just" > excessive demand... ... so if you have enough clout to get them straight from Xilinx you're o.k. otherwise forget it ?! Personally I'd call lead times of > 16 weeks with no sign of improvement over the last 6-9 months ``fundamental''. Has anyone at Xilinx actually heard of time-to-market? On at least 4 occasions recently I've been in the position of advising people not to design in SpartanII if they want to get products out the door in time to earn money on them. This also seems to be happening to the XC95K series where the XV and higher speeds of the XL families seem to be ``doing a Spartan II''. This lack of progress [In my view due to an excessive concentration on the macho, show-off G-gate devices] is now making me, die hard Xilinx fan though I am, start considering other families.Article: 27716
<john_stiekema@my-deja.com> wrote: > I have a similar problem. I would like to change a table in EEPROM and > still have the CRC verify correctly. > It should be possible to provide an additional dummy table with some > "CRC correction bytes", which would bring the CRC back to the original > value, so that the table data could be modified as desired, provided > that the appropriate "correction bytes" are also modified. You're right, this is possible. Normally, inverting a given data bit results in the modulo-2 addition of a constant value to the CRC. The constant value depends on the bit position. In general the CRC polynomial generates a particular Galois field, and it is possible to represent successive bit positions as consecutive integers, such that the desired constant for a position j is alpha**j, for some primitive field element alpha. This is computationally much simpler than the inverse problem of finding j given alpha**j, which for very large fields has been used as a "hard" problem in cryptology. SteveArticle: 27717
Peter Alfke wrote: > > Let me address the two concerns: > > SpartanII availability through distribution is limited because these > devices are being snapped up by the major customers at a faster rate than > we expected. Xilinx will ship about a million SpartanII devices this > quarter, so these are not sample quantities. They just don't make in onto > the distributor shelves in sufficient numbers. This may not help you much, > but it shows that there really is no fundamental problem. It's "just" > excessive demand... So, those of us who fall into the category of "minor customer" (I know my place on the food chain) are essentially outta luck? -- a ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d u "It is better to be silent and thought a fool, than to send an e-mail to the entire company and remove all doubt."Article: 27718
Well after reading all the negative press in Deja News about Orcad I
feel I may be the only one on the planet trying to do FPGAs and CPLDs with
Express. I have 9.2, which we bought 1 year ago, right before Cadence
bought Orcad. Orcad shipped me Synplify form Synplicity to replace Express.
I had used their schematic capture sw and it was pretty good for the price.
A year ago I didn't have a PLD design to work on and now I have 2 - one
simple GAL6002 from Lattice and the second will probably be a Xylinx Virtex
or maybe one of the older XC4000 chips. I am new to VHDL but have used
ABEL.
Well getting the simple GAL design to work has been a challenge. I
decided to check out Orcad's hierarchical design methods using a mixed VHDL
and schematic capture method. I down loaded Lattice's ISP expert starter
kit to do the place and route of the GAL.
Well I got bit on a number of issues right off the bat. The PLD project
wizard for Orcad did not include the GALs so I had to use a SPLD (Simple
PLD ) implementation. Well there is a library called spld.olb which
contained some simple macros for counters, buffers, etc. which Orcad pulled
nicely into the hierarchical block as schematic elements. I had one
hierarchical block which contained simple combinational logic which I
implemented as a VHDL module.
The compile passed ok and I had can do a functional simulation and
everything looked ok. Then I tried to take the edif file to the Lattice
tools and found it couldn't handle a hierarchical edif file. I tried a flat
edif file from orcad too, but the Lattice tool didn't like it, I can't
remember why. Anyhow I exported a vhdl netlist out of orcad and used that
in the IspExpert tools. The Lattice tools are almost as confusing as Orcad.
Anyhow it eventually compiled but I had to go into the OrCAD spld.vhd file
which has vhdl code for the spld macros used in the schematics) and cut
and past the components used in the spld macros into separate vhd files
which I then imported into my ISPExpert project. Sounds desperate doesn't
it!!!
Well the design compiled in IspExpert but again the functional
simulation runs but I used 2 cascaded 4 bit counters (tff1-8) which totally
do not work in the timing simulation. NOT even Close. It looks like the
2nd counter does not count and the first stops after maxing out instead of
rolling over? Do I trust this result, no! From what I can tell the
structure of device seems right but there are a lot of nodes with weird
names which I haven't a clue what they are. It is not easy to trace them
down.
To get to the point - Is anyone out there using ORCAD Epress. If so we
should start our own email support group or something. Does anyone know if
the Syplicity tools work better with vendor PAR sw? If I am having this
much trouble with a simple gal what will happen in the fpga!! I really like
the hierarchical method using some schematic some vhdl and keeping the
details down in the blocks. That part of Orcad seemed to work ok. If I go
to Xilinx design sw does it have this capability and how much does this all
cost?
Article: 27719
Hello everyone,
I was wondering if any of you has ever had any porblem in getting
near 100% timing path coverage due to some paths like these, that
are reported as uncovered by trce -u:
Delay: 2.051ns video_clock_in to afifo_a/WRITE_ADDR<2>
Path video_clock_in to afifo_a/WRITE_ADDR<2> contains 2 levels of logic:
Path starting from Comp: P213.PAD
To Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- --------
P213.GCLKOUT Tgpio 0.650R video_clock_in
video_clock_in.PAD
pdll/clkpad1
GCLKBUF3.IN net (fanout=1) 0.006R pdll/clkin1_w
GCLKBUF3.OUT Tgio 0.679R pdll/clk1g
pdll/clk1g
CLB_R42C9.S1.CLK net (fanout=43) 0.716R video_clock
-------------------------------------------------
Total (1.329ns logic, 0.722ns route) 2.051ns
(64.8% logic, 35.2% route)
Delay: 0.049ns dot_clock_in to DAC_PIX<8>
Path dot_clock_in to DAC_PIX<8> contains 3 levels of logic:
Path starting from Comp: P92.PAD
To Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- --------
P92.GCLKOUT Tgpio 0.650R dot_clock_in
dot_clock_in.PAD
pdll/clkpad2
DLL0.CLKIN net (fanout=2) 0.006R pdll/clkin2_w
DLL0.CLK0 Tdllino -2.021R pdll/dll2x
pdll/dll2x
GCLKBUF1.IN net (fanout=1) 0.000R pdll/clk2_dll
GCLKBUF1.OUT Tgio 0.679R pdll/clk2g
pdll/clk2g
P189.CLK net (fanout=653) 0.735R mem_clock
-------------------------------------------------
Total (-0.692ns logic, 0.741ns route) 0.049ns
These paths start from an input clock pin and go through a BUFG to
the CLK clock inputs. Both clocks are covered by the PERIOD
constraints. I know that this constraint will only cover paths from
register to register, however there should be no need to contraint
them, right?
-Arrigo
--
Dr. Arrigo Benedetti e-mail: arrigo@vision.caltech.edu
Caltech, MS 136-93 phone: (626) 395-3129
Pasadena, CA 91125 fax: (626) 795-8649
Article: 27720> If I managed to read your Verilog, you use the GSR as a regular async > reset? I prefer to use sync reset, to assure that all FFs sees the > reset go away on the same clock pulse. [I botched this area many years ago. It's still one of my hot buttons.] I think using GSR as a sync reset requires 2 things to make sense: The source must be clocked on the same clock. This means that GSR (in sync mode) can only work with 1 clock (and multiples) and that if you use DLLs you have to make sure they are locked when GSR goes away. The other requirement is that you can meet the setup time. GSR has a reputation for being slow. But maybe it's fast enough for some applications. The IOB section in the data sheet has numbers for SR to IQ and GSR to IQ. Subtracting that should give a rough idea of the GSR prop time. For a VirtexE-6 (Nov-2000 data sheet) that's 9.7-1.4 or 8.7 ns. That path needs 1 ns of setup so that's 9.7 ns of cycle time. Call it 100 MHz so it's probably fast enough for a lot of designs. Now that I think about it, this brings up an interesting can of worms. Where is that measured? I'd guess at the GSR input to the Startup block in the upper-left corner when using FPGA Editor. Maybe inside the block if it makes sense to use the internal clock. But how does GSR get into an IOB or CLB? The FPGA Editor doesn't show any options on the MUX in the SR path. Does one of the 1/0 inputs really connect to GSR? Or is there some routing path I haven't found yet. I didn't see anything coming out of the Startup block so I assume the GSR net is hidden. [I guess I'll make a test case and see what the Timing Analyzer says. ... When I run out of other things to do.] -- These are my opinions, not necessarily my employers. I hate spam.Article: 27721
GSR is a dedicated net that doesn't show up on the editor. I don't recall seeing specs for the propagation time from the startup to IOBs or CLBs. IIRC it is quite a bit slower than 10ns. 20-30 ns seems to be the number I've seen bandied about here when virtex first came out (Peter?). In any event, I give it plenty of time to come out of reset before kicking any statemachince off. Hal Murray wrote: > > > If I managed to read your Verilog, you use the GSR as a regular async > > reset? I prefer to use sync reset, to assure that all FFs sees the > > reset go away on the same clock pulse. > > [I botched this area many years ago. It's still one of my > hot buttons.] > > I think using GSR as a sync reset requires 2 things to make sense: > > The source must be clocked on the same clock. This means that > GSR (in sync mode) can only work with 1 clock (and multiples) > and that if you use DLLs you have to make sure they are locked > when GSR goes away. > > The other requirement is that you can meet the setup time. GSR > has a reputation for being slow. But maybe it's fast enough > for some applications. > > The IOB section in the data sheet has numbers for SR to IQ and GSR to > IQ. Subtracting that should give a rough idea of the GSR prop time. > For a VirtexE-6 (Nov-2000 data sheet) that's 9.7-1.4 or 8.7 ns. That > path needs 1 ns of setup so that's 9.7 ns of cycle time. Call it > 100 MHz so it's probably fast enough for a lot of designs. > > Now that I think about it, this brings up an interesting can of worms. > > Where is that measured? I'd guess at the GSR input to the Startup > block in the upper-left corner when using FPGA Editor. Maybe inside > the block if it makes sense to use the internal clock. > > But how does GSR get into an IOB or CLB? The FPGA Editor doesn't > show any options on the MUX in the SR path. Does one of the 1/0 inputs > really connect to GSR? > > Or is there some routing path I haven't found yet. I didn't see anything > coming out of the Startup block so I assume the GSR net is hidden. > > [I guess I'll make a test case and see what the Timing Analyzer says. > ... When I run out of other things to do.] > > -- > These are my opinions, not necessarily my employers. I hate spam. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 27722
I am wondering if it really is a good managment decision to sell 100K Parts to one customer instead fo selling 100 Parts each to 1K customers. Xilinx will loose big customers to gate array manufactures and small customers to Altera. But of course, a small customer will not sue them. (May one should :-) Kolja In article <3A2BD51E.8F0FAA1E@xilinx.com>, peter.alfke@xilinx.com wrote: > Let me address the two concerns: > > SpartanII availability through distribution is limited because these > devices are being snapped up by the major customers at a faster rate than > we expected. Xilinx will ship about a million SpartanII devices this > quarter, so these are not sample quantities. They just don't make in onto > the distributor shelves in sufficient numbers. This may not help you much, > but it shows that there really is no fundamental problem. It's "just" > excessive demand... > > Start-up current at low temperatures is higher than we and you like it to > be, but remember: There is no reliability issue here. The current is widely > distributed on the chip, and lasts for milliseconds only. So neither heat > nor metal migration are an issue. You "just" have to design the power > supply and regulator appropriately. > > I thought you might appreciate a straight answer... > > Peter Alfke, Xilinx Applications > ============================= > Rick Collins wrote: Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27723
just test Sent via Deja.com http://www.deja.com/ Before you buy.Article: 27724
In article <90gj7t$2ivb$1@noao.edu>, Andy Peters <"apeters <"@> n o a o [.] e d u> wrote: > gazit@my-deja.com wrote: > > > > Hi, > > I am working on a new design , using XCV400-BG560. > > How can I find out (except looking at the Pin-out symbol diagram) > > which > > I/O pin belongs to each of the banks ? > > The data sheet for the part will tell you. No it doesn't (as far as I could see); The only way to extract which I/O pin belongs to each of the banks from the data sheet is to observe its relative location in the BG560 PIN Function Diagram. > > Is there a source for Orcad symbols for Virtex family parts or do I > > need to generate my own ?. > > I always generate my own FPGA symbols. Instead of one big block with > 560 pins, I break the symbol up into multiple logical symbols (SDRAM > controller, local interface, clocks/reset/power, test points, etc.) > It's much easier to read. I agree, but it is always easier to start from existing symbol and modify it to your needs instead of starting from scratch. ---------------------------------------------------------- Rotem Gazit System & Architecture MystiCom Ltd. rotemg [at] mysticom dot com http://www.mysticom.com ---------------------------------------------------------- > > -- a > ---------------------------- > Andy Peters > Sr. Electrical Engineer > National Optical Astronomy Observatory > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) n o a o [dot] e d u > > "It is better to be silent and thought a fool, > than to send an e-mail to the entire company > and remove all doubt." > Sent via Deja.com http://www.deja.com/ Before you buy.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z