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
hi ,
I have the xilinx package for sun.
I did not have the flor planner but i heard i can have it free as
a sun user.
does anybody know from where i can take the flor planner files
and how i use it ?
thanks
--
Maya Reuveni Tel: 972-9-986976
Manager of Hardware Department Fax: 972-9-986980
HaTaasiya 9, Raanana 43100, Israel. E-mail: maya@asp.co.il
Article: 2201In article <465mt8$igu@neptune.myri.com>, wen-king@myri.com (Wen-King Su) wrote: >In my current project I need to design a PCI interface using FPGA. I >have the official PCI spec book, but I need more information on the actual >implementations that are out there. For example, what is the maximum >"cache line size" that people actually use in their machine. It will >have an effect on how complicated the FPGA code will be. Do I need a >cache line size computation circuit on the whole 8 bits for the write >line and invalide operation? Also what is the maximum DMA throughput >between device and memory I can expect on a real system under each transfer >type. Any info or pointers to info will be appreciated. Thanks. You might be interested in xilinx own PCI-complient interface. The link is http://www.xilinx.com/products/appsweb.htm#PCI Sincerely, Tore torela@idt.unit.noArticle: 2202
In article <DH2nzv.6Kt@emr1.emr.ca> methot@ccrs.emr.ca (Simon Méthot) writes: > second. Presently having a hard time writing and reading the flash memory > 29C512. This morning I could read the first 64 byte no problem. Then I > went to write mode, was never successful in writng a location and > reading back the proper info. By afternoon I got deeper in the hole now > cannot read back successfully a lot of the bytes being read are FF. Any > help would be appreciated. Even AMCC nvbuild program is not successful > in writing to the flash memory everytime. We also had some problems with the AMCC development board. The documentation is simply wrong in several places, most notably the C code fragment to access the NVRAM (page A-13 in the Spring 1995 manual). I *was* eventually able to program the serial device by using 16-bit accesses to the high half of the MCSR to set both the command bits and the NVRAM data simultaneously. Unfortunately, first you must dig yourself out of the hole created by the corrupted NVRAM. The way to do that is to remove the device from the board and reprogram it on a standard PROM burner (e.g. DataIO) using the data file from the AMCC installation disk. -jeff ------ Jeffrey Arnold IDA Center for Computing Sciences (formerly the Supercomputing Research Center) 17100 Science Dr. Bowie, MD 20715 email: jma@super.orgArticle: 2203
In <HAMMAMI.95Oct29205005@pross113.u-aizu.ac.jp> hammami@u-aizu.ac.jp (Omar Hammami) writes: >Dear Netters: > >Does anyone have ever tried to implement a small superscalar >processor design using FPGAs ? I would like to have an idea of >the gate complexity level for say a 16 bits superscalar with >roughly 3 FP units and 2 Int units and a limited number of >instructions. Great question! It is surely possible, but it might not be the best fit of architecture to implementation technology... First, let's talk functional units. Integer ALUs are easy to implement, you simply need an adder, logic unit, and multiplexor of some sort. Ripple carry adders will do, given vendors' dedicated carry chain hardware. Decent performance FPUs would be more difficult. An FP add/sub will require renormalization which requires a barrel shifter (bad: lots of wires!) or several iterative cycles of fewer bit shifts. A multiplier of managable size will also take several cycles, although at 16-bit FP (1 bit sign + 5 bit exp + 10 bit mantissa?) you might only need at 10x10->20 bit multiplier. (This is an invitation for you FP in FPGA veterans to chime in with your experiences.) Moving on, the register file could well be your critical path. If you hope to sustain an average of even one and a half integer instructions per clock you will have to fetch three or four operands per clock and retire two. A 3-read-2-write register file in which the two write back values are retired before you read the three new operands will take at least 2 SRAM write cycles on embedded dual ported SRAMs and up to 4 cycles on embedded non-dual ported synchronous SRAMs, depending upon how many copies of the register file you keep. (See Xilinx 4000E, Altera Max10K, Actel 3200DX?.) For instance, on the new Xilinx 40xxE-3 parts, you are talking at least 2-, 3-, or 4- ~15 ns sync-SRAM cycles best case. This design would hardly be competitive with a single-issue one which could sustain one instruction per clock at twice the clock rate. Once again the "speed demons" whip the "brainiacs"! And if you hope to retire 3 or 4 results (peak) per clock, your basic cycle time is even worse. Your only hope might be to lobby the FPGA architects for multi-multi-ported SRAMs (2-write, 2-read quad ported synchronous SRAMs, anyone? :-) A VLIW like architecture could be a better architectural choice because much of the register file, and its multiple write back liability, could be spread about the functional units with limited degrees of communication between units, achieving only one register file write back operation each clock per unit. (I have some "paper" VLIW datapath floorplans that satisfactorily fit in large existing FPGAs.) For instance, you could easily distribute 64 16-bit registers and four ALUs about as 4 units each of 16x16-bit register file+ALU, assuming instruction operand constraints that a given instruction segment for one unit could only read operands from that unit or (in a limited way) from adjacent units, and could only write back results to that unit. Then you could keep the register file result write back cycle time down to one or two sync-SRAM or dual port SRAM write and readback cycles no matter how wide your machine grows. But, I'd hate to have to write your compiler's code generator. Another comment. Superscalar microarchitectures typically demand many operand busses to route lots of operands and results to lots of functional units. Unfortunately, wires are relatively much more expensive in FPGAs than in custom designs (where they are already plenty expensive). The datapath of my (now working!) 32-bit pipelined RISC (half an XC4010) has just barely enough wiring resources to implement a single issue microarchitecture. Unless you are a wizard at time multiplexing different operands and results on the same wires, say at 10 ns intervals, without incurring killer delays, I think you would find today's FPGAs unacceptably wire limiting. But by all means give it a try! Sounds like a great push-the-envelope project. >Any pointers on books, TRs and projects descriptions for >undergraduates and graduates will be appreciated. Very highly recommended reference: Mike Johnson's book, Superscalar Microprocessor Design, Prentice Hall, 1991, ISBN 0-13-875634-1. "Tired: superscalar; Wired: VLIW and multithread," Jan Gray Redmond, WAArticle: 2204
(Reposted: Netcom brilliantly expired the first copy of this message the very same night it was posted. Apologies if duplicated.) In <HAMMAMI.95Oct29205005@pross113.u-aizu.ac.jp> hammami@u-aizu.ac.jp (Omar Hammami) writes: >Dear Netters: > >Does anyone have ever tried to implement a small superscalar >processor design using FPGAs ? I would like to have an idea of >the gate complexity level for say a 16 bits superscalar with >roughly 3 FP units and 2 Int units and a limited number of >instructions. Great question! It is surely possible, but it might not be the best fit of architecture to implementation technology... First, let's talk functional units. Integer ALUs are easy to implement, you simply need an adder, logic unit, and multiplexor of some sort. Ripple carry adders will do, given vendors' dedicated carry chain hardware. Decent performance FPUs would be more difficult. An FP add/sub will require renormalization which requires a barrel shifter (bad: lots of wires!) or several iterative cycles of fewer bit shifts. A multiplier of managable size will also take several cycles, although at 16-bit FP (1 bit sign + 5 bit exp + 10 bit mantissa?) you might only need at 10x10->20 bit multiplier. (This is an invitation for you FP in FPGA veterans to chime in with your experiences.) Moving on, the register file could well be your critical path. If you hope to sustain an average of even one and a half integer instructions per clock you will have to fetch three or four operands per clock and retire two. A 3-read-2-write register file in which the two write back values are retired before you read the three new operands will take at least 2 SRAM write cycles on embedded dual ported SRAMs and up to 4 cycles on embedded non-dual ported synchronous SRAMs, depending upon how many copies of the register file you keep. (See Xilinx 4000E, Altera Max10K, Actel 3200DX?.) For instance, on the new Xilinx 40xxE-3 parts, you are talking at least 2-, 3-, or 4- ~15 ns sync-SRAM cycles best case. This design would hardly be competitive with a single-issue one which could sustain one instruction per clock at twice the clock rate. Once again the "speed demons" whip the "brainiacs"! And if you hope to retire 3 or 4 results (peak) per clock, your basic cycle time is even worse. Your only hope might be to lobby the FPGA architects for multi-multi-ported SRAMs (2-write, 2-read quad ported synchronous SRAMs, anyone? :-) A VLIW like architecture could be a better architectural choice because much of the register file, and its multiple write back liability, could be spread about the functional units with limited degrees of communication between units, achieving only one register file write back operation each clock per unit. (I have some "paper" VLIW datapath floorplans that satisfactorily fit in large existing FPGAs.) For instance, you could easily distribute 64 16-bit registers and four ALUs about as 4 units each of 16x16-bit register file+ALU, assuming instruction operand constraints that a given instruction segment for one unit could only read operands from that unit or (in a limited way) from adjacent units, and could only write back results to that unit. Then you could keep the register file result write back cycle time down to one or two sync-SRAM or dual port SRAM write and readback cycles no matter how wide your machine grows. But, I'd hate to have to write your compiler's code generator. Another comment. Superscalar microarchitectures typically demand many operand busses to route lots of operands and results to lots of functional units. Unfortunately, wires are relatively much more expensive in FPGAs than in custom designs (where they are already plenty expensive). The datapath of my (now working!) 32-bit pipelined RISC (half an XC4010) has just barely enough wiring resources to implement a single issue microarchitecture. Unless you are a wizard at time multiplexing different operands and results on the same wires, say at 10 ns intervals, without incurring killer delays, I think you would find today's FPGAs unacceptably wire limiting. But by all means give it a try! Sounds like a great push-the-envelope project. >Any pointers on books, TRs and projects descriptions for >undergraduates and graduates will be appreciated. Very highly recommended reference: Mike Johnson's book, Superscalar Microprocessor Design, Prentice Hall, 1991, ISBN 0-13-875634-1. "Tired: superscalar; Wired: VLIW and multithread," Jan Gray Redmond, WAArticle: 2205
Christian Grebe wrote: > being a Xilinx user I experienced routing problems with the 4025 while using > the part in a rapid prototyping project. Having a very high connectivity in my > design there was an upper bound of about 50% utilization, which is quite > realistic with this part. The design needed intensive manual floorplanning. If you have massive production or need extra CLB's, try to place some of the CLB manually. > When timing is too tight the router will run forever while building subnets on > large and slow nets to speed up signals, making the routing problem worse. This is why some CLB need to be placed manually. NeoCad (better) or XACT are no expert system and there is nothing like a human being to solve common sense problems. > It is no secret that Xilinx is aware of this problems. They claim that the new > XC4000E series will overcome this problem, having more routing ressources while > being pin compatible. I'm not sure, but according to the 4000E specs, there is nothing more in the 4000E series than dual port RAM or synchronous RAM. They don't talk about more ressources. Bitstream & pin compatibles yes, but no extra routing ressources.Article: 2206
Get the hell off this page. It's for programmable logic users.Article: 2207
ANNOUNCING THE RELEASE OF ASC's VHDL to Verilog TRANSLATOR, VHDL2verilog(TM) ---------------------------------------------------------------------------- VHDL2verilog translates hierarchical VHDL to functionally equivalent Verilog HDL. All structural VHDL constructs, as well as a large subset of RTL VHDL constructs are supported by VHDL2verilog. Both IEEE Standard 1076-1987 and 1076-1993 compliant VHDL are processed by the tool. Output Verilog follows the proposed IEEE-1364 standard, and is easy to understand. Product description can be found at http://www.ascinc.com/vhdl2v. VHDL2verilog can also be obtained with an object-oriented Software Procedural Interface (SPI) to access the output HDL and is currently available for SunOS 4.1.x platform. An immediate demo is available at http://www.ascinc.com/vhdl2v. All enquiries to: ---------------- Jon Clancy Alternative System Concepts, Inc. PO Box 128 Windham NH 03087 Ph:(603)437-2234 Fax: (603)437-2722 email: info@ASCinc.com -- * Sashi Obilisetty * * Alternative System Concepts, Inc. * * PO Box 128 Windham NH 03087 * * tel (603) 437-2234 fax (603) 437-ASC2 URL http://www.ascinc.com *Article: 2208
> being a Xilinx user I experienced routing problems with the 4025 while using > the part in a rapid prototyping project. Having a very high connectivity in my > design there was an upper bound of about 50% utilization, which is quite > realistic with this part. The design needed intensive manual floorplanning. You might want to try and place logic AWAY from the center. Placement algorithms tend to place logic as close together as possible and this causes congestion. When there used to be channeled gate arrays and they started to get large many vendors made the channels larger near the center. To do this with a FPGA try and place logic near the edges to free up the center which can then be used for routing. Steve CasselmanArticle: 2209
I am currently using version 5.0.0 XACT software which runs on a UNIX based operating system. As far as I am aware I have a full set of manuals for XACT but Xilinx have recently refered me to a manual entitled The XSI FPGA User Guide. This I do not have, has anyone else used this manual, is it a new manual that comes with the latest release of XACT ? Thanks, Steven Acock ----------------- Electronic Labs, University of Kent, Canterbury, Kent, United Kingdom. -----------------Article: 2210
In article <DGn77M.F9s@tumlis.lis.e-technik.tu-muenchen.de>
news@tumlis.lis.e-technik.tu-muenchen.de writes:
> Hi all,
>
> is there anyone, who has tried to hack the internal configuration memory
> structure of Xilinx FPGA's?
>
>
>
> Thanks
>
I tried this once a number of years ago - back in the Xilinx 3090 era. There
was a specific pattern matching application I had in mind, where the pattern
was encoded in the logic and the database streamed by it. To encode the
pattern required changing the logic.
In truth, though, all I really wanted to change was the truth tables - the
routing remained exactly the same each time. As others have noted, it's silly
to keep paying the price for placement and routing when none of this is
changing. (In my case, each place & route cycle was taking about 40 minutes.)
It was pretty easy to figure out which bits in the bit stream file corresponded
to which bits in the truth tables. None of this required a NDA from Xilinx.
(The routing resources are much more complicated, though - I wouldn't have
tried to figure those out.)
I was actually able to "twiddle" various bits directly in the bit stream file
and change the programming of the FPGA. I didn't take this particular
application beyond the exploratory phase, though - just confirmed that it could
be done.
Again, this was back in the 3090 days - things may have changed since then.
Dan
Article: 2211In article <472r2v$amu@aurns1.aur.alcatel.com> wolf@aur.alcatel.com writes: >1. An open-architecture FPGA. I am all for this. While I am not >surprised Xilinx chooses to protect their architecture, I am a >little surprised that some other vendor hasn't pushed an open >architecture with partners to get a foothold in the business... In fairness, there is one tricky problem: customers who want to make their products reverse-engineering-proof. This is hard to do with the Xilinx approach, in which the bit stream to program the FPGA *must* come from an external source and hence is easily tapped. To handle this in the context of an open architecture, the chip needs to have either encryption hardware or on-chip nonvolatile memory, neither of which is trivial. -- The problem is, every time something goes wrong, | Henry Spencer the paperwork is found in order... -Walker on NASA | henry@zoo.toronto.eduArticle: 2212
I am using Altera EPS448 (WSI 5AM 448) in a horizontal (parallel) mode of operation. The two chip tend to lose synchronization with each other. Anybody ever have this problem? Any solutions? Altera claims this isn't a problem. Note nReset pin as a resync is not an option in this design Thanks!Article: 2213
I am in need of RTL circuit descriptions in Verilog or VHDL that may be synthesized by Synopsys for use in a multi-FPGA synthesis study. Any datapath circuits or FPGA compute applications would be especially welcome. The larger the circuit the better. I have several RTL Verilog circuit descriptions to offer in trade. Thank you Russ Tessier MIT Lab for Computer ScienceArticle: 2214
In article <12915@eagle.ukc.ac.uk>, sjba@ukc.ac.uk (S.J.B.Acock) wrote: >Xilinx have recently refered me to > a manual entitled The XSI FPGA User Guide. This I do not have, > Steven, the XSI ( Synopsys ) FPGA User Guide should have been shipped to you with any XSI update received after Dec. '94. Since you are still using 5.0.0, you may not have the latest revision of the software. Contact your distributor who supplies your updates, or if you are on the University Program, contact jason.feinsmith@xilinx.com. Hope this helps, Peter Alfke, Xilinx ApplicationsArticle: 2215
Not a manual I've seen <FX: quickly scans data book shelves>.... not even with 5.1.1 (PC) - mind you, that's the version that doesn't work with Windows95 or NT :-( Regards Andy GulliverArticle: 2216
In article <47b0ak$ait@ixnews5.ix.netcom.com> dne_tech@ix.netcom.com (Wayne Addy ) writes: > I am using Altera EPS448 (WSI 5AM 448) in a horizontal (parallel) mode >of operation. The two chip tend to lose synchronization with each >other. Anybody ever have this problem? Any solutions? Altera claims >this isn't a problem. Note nReset pin as a resync is not an option in >this design Thanks! The Altera SAM448 ( a device designed at Altera to compete with devices that I designed at AMD (29CPL151,'152, '154, ...) ), has some interesting positives and negatives with respect to the 29CPLxxx parts. In particular, the multiway branching was quite superior, while the restriction to having it only work on the last 64 locations of 256 was (I'll be nice here) silly. I personally believe the 29CPLxxx parts had a better instruction set. A significant difference was also the input register for the test inputs. The 29CPL parts have one, and the SAM does not. I am fairly sure that this is the root of your problem. If the two chips start out synchronized, and have identical uPrograms ( for the instruction section. output section can be different), and have all their test inputs tied together, and are on the same clock, then you are half way to having these parts slaved together. The other half is that test inputs MUST ALWAYS meet the setup time requirements which is quite long for the SAM, due to the lack of the input register. Any test input that is asynchronous to the clock, or fails to meet the setup AND hold requirements (MIN 0ns) will cause the behaviour you are seeing, even if you have done all the things in the previous paragraph. If your input signals are asynchronous, then a single input register is not enough because of metastability, and you need to use at least a two stage synchronizer, and then both SAMs need to take their test inputs from the same second stage. Independent synchronizers for each SAM (or the 29CPLxxx parts for that matter) will not work for the same reasons. My rumor mill has told me that AMD no longer builds 'my' 29CPLxxx products, and Altera no longer makes the SAM parts. Does WSI still make the SAM? So that this article has some news group relevance, let me comment that these days I build structures like the SAM448/29CPLxxx all the time, and I do it in Xilinx XC4000 and XC4000E FPGAs. A particulary nice side effect is that I get to build custom versions that are more finely tuned to the application, than the standard parts ever were, and the current reprogrammable designs are faster than the older custom parts were. Hope this is sufficient to get you statemachine to agree on the sequence they should be following. Philip Freidin.Article: 2217
In article <30950B5E.541E@cybersecure.com> Patrick Drolet <pdrolet@cybersecure.com> writes: >Stan Hodge wrote: >> >> Hi. I am currently evualuating a new FPGA technologies for our >> next generation product. I have looked at Xilinx and AT&T. The >> new Xilinx software seem a bit more polished and easer to use >> than the AT&T neo stuff. However, it seems that the part >> architecture from AT&T is much better. > >Actually, Xilinx tools seems better only if you wish to use their >old parts: forget XC4000E series, or XC5200 series. Their >XACT 5.1.1 tools cannot merge a function generator with a flip- >flop in the same CLB! The Xilinx 5.1.1 software is the same as the quite stable and (for Xilinx at least) relatively bug fre version 5.1 The only major difference is that the 5.1.1 release included the newer Viewlogic Pro-Series, which is the windows base version of their schematic and simulation software. Pro-Series is an extreme step backwards, and I don't use it, and continue to use the older DOS version called workview. For customers that want to use the newer products like the XC4000E and XC5200, it is fairly simple to ask Xilinx to be a beta site for the software. I've done this and have been using the XC4000E since it was first announced, and have COMPLETED over 100 designs. I have also done a few designs with the XC5200 products. Your recomendation to 'forget' these new products makes no sense to me. > >The "neo stuff" you are refering to is NeoCad. AT&T use it. >Actually, it is so good that Xilinx bought NeoCad a couple of >months ago. Unfortunately, an despites of what Xilinx says, the >next version of XACT (6.0) won't be out until a year. If you're >ready to wait that long for good tools, choice is yours! I suspect the reality is that V6.0 is much closer than a year away. Philip FreidinArticle: 2218
(Philip Freidin) fliptron@netcom.com wrote: > The Xilinx 5.1.1 software is the same as the quite stable and > (for Xilinx at least) relatively bug fre version 5.1 > The only major difference is that the 5.1.1 release included the > newer Viewlogic Pro-Series, which is the windows base version of > their schematic and simulation software. Pro-Series is an extreme > step backwards, and I don't use it, and continue to use the older > DOS version called workview. I prefer the pro-series to the older workview. It's much more pleasant to use, and works well with Windows 3.1 (but NOT win95). It doesn't require goofy memory managers and mice. Since I use mostly NeoCad/ORCA now instead of Xilinx, I can stay in windows all the time, and switch back and forth from schematic to layout. I dont use the simulation software so I don't know how pro-sim and view-sim compare.Article: 2219
What do you mean the design is different ? You can do anything with an FPGA that discrete ICs can do. DerekArticle: 2220
I have been asked to locate vendors who can take an FPGA-based design (Xilinx, specifically), and migrate it to an ASIC for economy in large volumes. I know of Xilinx' own Hardwire service, and Orbit Semiconductor. What other sources would anyone recommend? TIA David R. Brooks <daveb@iinet.net.au> Tel/fax. +61 9 434 4280Article: 2221
Customer focus is the key to the R.K.B. Opto-Electronics
environment; we develop and manufacture high-performance quality-
assurance systems used in the paper industry. These systems are
equipped with CCD, IR or UV sensors.
We currently have the following positions available.
Service Engineer
This is an opportunity for an individual with an Associate
Degree in Electrical Engineering.
Requires knowledge of digital and analog circuits, good
communication and interpersonal skills.
Hardware / Software Engineer
This is an excellent opportunity for an individual with a
Bachelor's Degree plus a few years' experience, or a Master's
Degree, in Electrical Engineering or Computer Science.
Requires knowledge of Visual C++, DOS and Windows platform,
Digital and Analog circuit design, Complex Programmable Logic
Design, Field Programmable Gate Array, good communication and
interpersonal skills. Some knowledge of Printed Circuit Board
design, Graphical User Interfacing, Object-Oriented
Programming, Digital Signal Processing, Ultra Violet-, Infra
Red-, Charge Coupled Device- sensors, would be a plus.
All positions require some or frequent national and international
travel.
R.K.B. Opto-Electronics Inc. provides a supportive, cutting-edge
workplace in central New York, which offers an ideal climate (4
seasons), and endless recreational activities. Join us in our
growing success.
If you qualify, please forward your resume to:
Bas Evers
R.K.B. Opto-Electronics Inc.
P.O. Box 157
Syracuse, NY 13211
Fax: (315) 455 8216
E-Mail: BASEVERS@IX.NETCOM.COM
We look forward to hearing from you soon.
Article: 2222Don Husby (husby@fnal.gov) wrote: : I prefer the pro-series to the older workview. It's much more pleasant to : use, and works well with Windows 3.1 (but NOT win95). It doesn't require goofy : memory managers and mice. Since I use mostly NeoCad/ORCA now instead of : Xilinx, I can stay in windows all the time, and switch back and forth from : schematic to layout. I dont use the simulation software so I don't know how : pro-sim and view-sim compare. I think there is NO difference between DOS WorkView and the PROseries. They even have the same bugs since ViewLogic never has enough time to fix them (they release new products with the new bugs instead). It applies both to schematic entry and simulation. Talking about Xilinx I can only tell that now I am using beta-release software for 5200 series and it runs OK in a DOS window so I can easily switch between schematic and layout. Probably this is the only advantage of the PROseries.Article: 2223
Something of a quandry, folks If i do a PLDShell design, then simulate it, i get a .hst file which i can view as w set of waveforms, expand, contract, swap position & generally do what i want with...great stuff. If i do a MACHXL design, i also get a .hst file which i cannot expand, contract, swap etc when viewing...not so great stuff. If i try to view the MACHXL generated file with the PLDSHELL viewer, no dice. Q : does there exist a more tractible viewer for MACHXL, or are there commands not referenced in the doco that do what i want. cheers MikeArticle: 2224
Wanted motorola fpga mpa1036 I'm looking for: 1 mpa1036 160 pin pqfp package 1 mpa1036 84 pin PLCC package Email me price including shipment to the Netherlands (west Europe) and method of payment. These devices are difficult to obtain over here. Thanks in advance, Nico Coesel
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