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
On Wed, 24 Oct 2007 13:06:34 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Processor speed has increased somewhat faster than DRAM speed. Indeed so; a fair point. And you could perhaps also argue that the cost of row access, as a fraction of a data access, has increased quite dramatically over that time. >> A DRAM row is effectively a cache. When you access a row, >> you read the whole row into the DRAM's row buffer as a free >> side-effect, and can then make very fast column accesses >> to anly location in the row. It's preposterous to throw >> away that massive free bandwidth just to save yourself >> some refresh effort - unless you're trying to design >> a $80 home computer/toy in the early 1980s. > >When RAM cycle time was faster than processor cycle time. That too is an interesting point. My own experience of that sort of video controller was that they typically caused lots of processor stalling while video data was being fetched, but it may have been different for other designs. >If you address it such that sequential characters are >in different rows then it is refreshed much faster than >the frame rate. True, but then you are *really* wasting bandwidth by doing more row accesses than necessary. I guess you could, by juggling the use of address bits sufficiently cunningly, arrange that row accesses by video scan would *just* provide enough refresh to satisfy the data sheet spec. I've seen many different variants on this: block refresh during frame blanking, for example. They all seemed pretty unpleasant to me at the time, and still seem so now - although, of course, no-one needs to do that sort of dirty trick any more (do they? please?) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 125401
Jonathan Bromley wrote: (snip) > Yes, and it's a completely ridiculous way to do it. The > added cost of making frequent additional row accesses is > far greater than the cost of the necessary refresh. Processor speed has increased somewhat faster than DRAM speed. > A DRAM row is effectively a cache. When you access a row, > you read the whole row into the DRAM's row buffer as a free > side-effect, and can then make very fast column accesses > to anly location in the row. It's preposterous to throw > away that massive free bandwidth just to save yourself > some refresh effort - unless you're trying to design > a $80 home computer/toy in the early 1980s. When RAM cycle time was faster than processor cycle time. > In those days, the video buffer was a sufficiently > large fraction of the overall DRAM that it was > reasonable to lay out the video memory so that > every row was automatically visited by the video > scan, giving a refresh cycle every 20ms (16.7ms > in the USA). That was out-of-spec for many DRAMs > of the day (8ms refresh cycle) but in practice it > worked in almost all cases - and the manufacturers > of those computers had a shoddy enough warranty > policy that they weren't going to worry about a > handful of customers complaining about occasional > mysterious memory corruption on a hot day. Any access to the row will refresh the whole row. If you address it such that sequential characters are in different rows then it is refreshed much faster than the frame rate. -- glenArticle: 125402
I am using the MPMC2 to implement a PLB and NPI port config. The PLB port works as expected. However, I am simulating my design and the NPI isn't working as I expect. I have created a small NPI interface that I use to control the write/read requests to the NPI bus. I have read both the user guide and the release notes for the MPMC2 (not enough information provided in my opinion). I am using a 64-bit memory and wish to do double-word (and word) writes and reads. >From the User Guide: When using a double-word write transfer with a 64-bit memory: The write data push must occur a minimum of one cycle after the address acknowledge. All write data pushes for previous transfers must be completed before asserting the address request. And from the release notes: When using the NPI, please ensure that all write data is in the write data path FIFOs before the memory requires it. This is particularly important to pay attention to when using 64-bit memories or when the custom NPI PIM has a slower clock than MPMC2_0_Clk0. For safest operation assert MPMC2_PIM_<Port_Num>_AddrReq after all MPMC2_PIM_<Port_Num>_WrFIFO_Push's. So I want to do one 64-bit write to the memory. I present the data, data BE, and RNW to the NPI bus and pulse the FIFO Push signal for one clock cycle. Then the very next clock cycle later I assert the ADDR REQ signal. The next clock cycle the ADD ACK goes high. I lower the ADDR REQ on the next cycle. This is according to the timing diagrams and descriptions in the user guide. For some reason the timing diagram presents the ADDR REQ before the DATA PUSH, but the descriptions say to do the opposite. Anyways, the controller does perform the write correctly to the DDR. I thought that I would see the WrFIFO Empty signal go high (it should have written all the data I put in there). But it stays low...meaning data must be in there. Now, lets say I execute another write following the first write described above. I do this about 50 clock cycles after the first request. In fact, the controller writes the first data to the DDR before the second request is even made. This second 64-bits of data is not written correctly. It is all 0's. I've dug WAY WAY down into the MPMC2 files in simulation. I am not about to try to figure out everything they are doing. But is does appear that some internal FIFO/ Memory is 128-bits wide. I could understand the FIFO not going empty if it contains an extra 64-bits of 0. And that may explain why the second write is all 0's. I just can't figure out why the core is behaving like this. All documentation says "BE CAREFUL" when using 64-bit wide memory, but it doesn't explain enough. I thought I was following the recommendations. I am putting data in the FIFO before I request the transfer. And if I try to do word writes (by masking the data pushed into the FIFO with the BE signal) it still doesn't work. Anyone with experience with this port? Any advice would be great. I saw some posts from a little over a year ago so I am hoping.....Article: 125403
On Oct 23, 4:04 pm, CBFalconer <cbfalco...@yahoo.com> wrote: > Since the only purpose of the refresh circuitry is to avoid the > memory dropping bits, it should already be running at the slowest > possible rate, and speed reduction will be harmful, while speed > increase will do no good. So this is not a good idea. I disagree (softly), having designed several memory controllers, I always found it easier to just insert a READ DATA command into the DRAM when a refresh was needed, rather than insert a refresh command. The timing differences between refresh and a loosly coupled string of READS is such that one can refresh ahead with READs easier and then be in a position to absorb a longer string of demand requests by not using the REFRESH commands. Thus while running at the slowest overall rate, one can bunch and distribute the refresh mechanics to better interleave same with the demand memory requests and gain something. But I will state the overall performance differences are a fraction of the refresh overhead anyways. > What are you trying to do? That is the real question.Article: 125404
In comp.arch.fpga, Antti <Antti.Lukats@googlemail.com> wrote: > On 24 Okt., 14:18, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> > wrote: >> >> Is there a posibility to program arbitrary binary files in a dataflash >> with the impact tool and xilinx download cable? > > yes. > > just use your own tools to prepare the HEX file (MCS) and use it. > impact doesnt care what inside the file. > I use impact as "general purpose SPI programmer sometimes OK, thanks. Silly me, thought the MCS and EXO formats where some xilinx format. Have never seen MCS as the extension for intel hex files, most tools I have used, use .hex or .ihex. So adding an extra objcopy with ihex output to my makefile (after linking the CPU code with the xilinx bitstream) should be enough. Can't wait to test it on the prototype (will be a while though). -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)Article: 125405
"motty" <mottoblatto@yahoo.com> wrote in message news:1193261586.795093.327150@i13g2000prf.googlegroups.com... > > Anyone with experience with this port? Any advice would be great. I > saw some posts from a little over a year ago so I am hoping..... > One of the things to watch is memory alignment requirement. I don't remember the exact details, it's somewhere in the manual, but you should be safe if you align your buffer to 128 bytes I believe. /MikhailArticle: 125406
Jonathan Bromley wrote: > On Wed, 24 Oct 2007 11:29:29 -0700, Peter Alfke <peter@xilinx.com> > wrote: > > >>Jonathan, why so aggressive? > > > Ooh, I can be much more aggressive than that! And it > certainly wasn't directed at you. > > >>I was just pointing out that certain applications naturally perform >>sufficient refresh operations in their normal addressing sequence. I >>can't see why this is "completely ridiculuous"... > > > Nor is it; the absurdity comes from bending the addressing > so that only a small part of each row is sequentially accessed, > thereby wasting the massive increase in memory bandwidth that > can be achieved for sequential-access applications by using > the row buffer as a cache. My spleen was being vented at some > designers of old computers (as alluded to by Antti, not you) > who used video scan to access every row of DRAM on each video > field, thereby unnecessarily burning-up memory bandwidth > (which was in short enough supply on such machines) in order > to save the trouble of doing refresh properly... The bandwidth is there for the designer to use how they wish. It also only actually matters, if that bandwidth is the bottleneck in the total design. eg I have done designs using interleaved video access, which removes flicker, and makes the system appear to be dual-port. On your yardstick, because the bandwidth is not 100% used, this is a bad design ? -jgArticle: 125407
Peter Alfke wrote: > > For certain addressing patterns, the refresh can be eliminated > alltogether, when the addressing sequence is such that all (used) > memory cells are naturally being read, and thus refreshed, within the > required time. > Peter Alfke > Such as for a video processor. I've done several that used no refresh.Article: 125408
Peter Alfke wrote: > Jonathan, why so aggressive? > I was just pointing out that certain applications naturally perform > sufficient refresh operations in their normal addressing sequence. I > can't see why this is "completely ridiculuous"... > Peter Alfke > > On Oct 24, 12:40 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: > >>Yes, and it's a completely ridiculous way to do it. The >>added cost of making frequent additional row accesses is >>far greater than the cost of the necessary refresh. >> >> And by not having to perform explicit refreshes, the bandwidth is slightly higher and latency is more predictable. If your application is one that always addresses all the memory that it uses (no need to refresh rows you are not using) within the minimum refresh interval, then this can sometimes be used to simplify the system. There are still plenty of FPGA applications that, for example, use the DRAM only for a video frame buffer.Article: 125409
HI, I'm new in FPGA, I have to build a SPI interface (in VHDL) to let an fpga read and write a flash memory. The fpga is a Xilinx Spartan3E, while the memory is an ST M25P16 (serial I/O). Do you know if is there any built vhdl core to start with? Thanks in advance GiulioArticle: 125410
techG wrote: > Do you know if is there any built vhdl core to start with? <http://www.opencores.org> <http://www.opencores.org/projects.cgi/web/simple_spi/overview> Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 125411
Initially I also had similar problem. For double-word write transfer with a 64-bit memory the user guide information is correct: When using a double-word write transfer with a 64-bit memory: The write data push must occur a minimum of one cycle after the address acknowledge.Article: 125412
On Wed, 24 Oct 2007 14:39:16 -0700, MitchAlsup <MitchAlsup@aol.com> wrote: >On Oct 23, 4:04 pm, CBFalconer <cbfalco...@yahoo.com> wrote: >> Since the only purpose of the refresh circuitry is to avoid the >> memory dropping bits, it should already be running at the slowest >> possible rate, and speed reduction will be harmful, while speed >> increase will do no good. So this is not a good idea. >But I will state the overall performance differences are a fraction of >the refresh overhead anyways. > >> What are you trying to do? > >That is the real question. If the idea is to reduce the refresh overhead on a busy bus, reducing the relatively slow refresh rate does not make much sense. However, if the memory content is to be maintained for a long time without any data access in a battery powered device, it would make sense to reduce the refresh rate at low ambient temperatures. The high refresh rates are needed at the top end of the temperature range, but at lower temperatures, a slower refresh rate would be sufficient, which reduces the power consumption and increase battery life. Unfortunately, refresh rate figures are seldom available for lower temperatures. PaulArticle: 125413
Hi Mikhail, Thanks.. Yeah.. Managed to get simulation bug out of the way.. The problem was GT_custom, GT_aurora simulation libraries wasn't there in the modelsim. I downloaded the simulation libraries from Xilinx site. But it didn't include the those libraries. I used modelsim tocompile necessary libraries and load it in. Regarding initialization, was reading that chapter...One question I have is, does the 1st MGT(sender for example) need to be linked to 2nd MGT(receiver for example) to be initialized. There must be some sort of handshaking mechanism there..So if i remove the 2nd MGT, what would happen to the link at the start...was trying to see the behavior in simulation.. Thanks, Regards, Shakith On Oct 25, 2:11 am, "MM" <mb...@yahoo.com> wrote: > Shakith, > > On simulation issue you need to have support for swift models in your > simulator, although personally I think there is very little value in > simulating MGTs if you are going to use one of the standard cores such as > Aurora. > > WRT initialization, read carefully the chapter on Simplex Initialization in > the Aurora User Guide. The easiest to initialize are full-duplex channels. > Simplex channels require either a back channel or tricks with using timers. > I used the former method in my design. > > /Mikhail > > <shakith.ferna...@gmail.com> wrote in message > > news:1193234536.652408.171350@z24g2000prh.googlegroups.com... > > > Hi all, > > > I am trying to use a Aurora Core and MGT transceiver to get high Speed > > serial transmission signal out. > > I have run into several problems.. > > > One problem is getting the Aurora Core simulated... > > I generated a core using the core generator with the following > > settings. Streaming, Simplex -Both directions. > > I tried to simulate the design using the given tb and the do scripts. > > The clocks are toggling..but there is not data being transferred.. I > > tried several versions of the aurora 2.4, 2.6, 2.7, 2.7.1.. Still the > > same issue.. Do_CC is also not asserted. so idle signals are not being > > sent... Is there something I am missing... > > > Also I need to send the high speed signal out to to RF unit... > > So there is no initialization signals being sent back.. And > > tx_d_ready signal from the receiver. > > The initialization can be probabaly set by the sender side.. but how > > does the tx_d_ready signal assrted from the GT_Aurora primitve. > > FPGA Board - Xupv2p > > FPGA - XC2VP30 > > My setup is ISE 9.1i Sp3. > > > Thanks, > > > Cheers > > ShakithArticle: 125414
I'm about to place an SPI flash for spartan 3e but I'm a bit disapointed in having to place another header to program it via impact. It would seem that a fairly simple piece of code could configure the FPGA via the jtag header which would then program the flash with data it gets "chipscope style" Does anyone know whether such a solution is in the pipeline? ColinArticle: 125415
Paul Keinanen wrote: > However, if the memory content is to be maintained for a long time > without any data access in a battery powered device, it would make > sense to reduce the refresh rate at low ambient temperatures. The high > refresh rates are needed at the top end of the temperature range, but > at lower temperatures, a slower refresh rate would be sufficient, > which reduces the power consumption and increase battery life. > Unfortunately, refresh rate figures are seldom available for lower > temperatures. If you were really aiming for long run time on battery power, I suppose you'd just use DRAM devices specifically made for such an application. Mobile SDRAM devices often have a temperature compensated self refresh feature. You just enter a special suspend mode and the device does the refresh itself, and only as often as required according to the current temperature. You can also tell it to just refresh a part of the memory array, in case you don't use it all. This is usually way better than anything one could do on his/her own. So, the question still stands: What does the OP really want to do? cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 125416
On 25 Okt., 10:15, colin <colin_toog...@yahoo.com> wrote: > I'm about to place an SPI flash for spartan 3e but I'm a bit > disapointed in having to place another header to program it via > impact. > > It would seem that a fairly simple piece of code could configure the > FPGA via the jtag header which would then program the flash with data > it gets "chipscope style" > > Does anyone know whether such a solution is in the pipeline? > > Colin it is supported for S3A-V5 only ASFAIK so I use my own tools for cross-platform SPI indirect programming AnttiArticle: 125417
>HI, I'm new in FPGA, I have to build a SPI interface (in VHDL) to let >an fpga read and write a flash memory. >The fpga is a Xilinx Spartan3E, while the memory is an ST M25P16 >(serial I/O). >Do you know if is there any built vhdl core to start with? > >Thanks in advance >Giulio The problem with SPI is that it comes in a near-infinity of different flavours, so IP designed for 1 flavour might be difficult to adapt for a different flavour. Good luck! (You will need it)Article: 125418
In comp.arch.fpga, colin <colin_toogood@yahoo.com> wrote: > I'm about to place an SPI flash for spartan 3e but I'm a bit > disapointed in having to place another header to program it via > impact. What will you use the JTAG for? If it's only for testing/debugging your prototype, you can consider placing only a few solder pads for the JTAG connection. The little extra hassle is not a problem for debugging and production will only use the SPI connector. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)Article: 125419
On Oct 24, 11:33 pm, motty <mottobla...@yahoo.com> wrote: > I am using the MPMC2 to implement a PLB and NPI port config. The PLB > port works as expected. However, I am simulating my design and the > NPI isn't working as I expect. I have created a small NPI interface > that I use to control the write/read requests to the NPI bus. I have > read both the user guide and the release notes for the MPMC2 (not > enough information provided in my opinion). > > I am using a 64-bit memory and wish to do double-word (and word) > writes and reads. > > >From the User Guide: > > When using a double-word write transfer with a 64-bit memory: The > write data push must occur a minimum of one cycle after the address > acknowledge. > > All write data pushes for previous transfers must be completed before > asserting > the address request. > > And from the release notes: > When using the NPI, please ensure that all write data is in the write > data path FIFOs before the > memory requires it. This is particularly important to pay attention > to when using 64-bit memories > or when the custom NPI PIM has a slower clock than MPMC2_0_Clk0. For > safest operation > assert MPMC2_PIM_<Port_Num>_AddrReq after all > MPMC2_PIM_<Port_Num>_WrFIFO_Push's. > > So I want to do one 64-bit write to the memory. I present the data, > data BE, and RNW to the NPI bus and pulse the FIFO Push signal for one > clock cycle. Then the very next clock cycle later I assert the ADDR > REQ signal. The next clock cycle the ADD ACK goes high. I lower the > ADDR REQ on the next cycle. This is according to the timing diagrams > and descriptions in the user guide. For some reason the timing > diagram presents the ADDR REQ before the DATA PUSH, but the > descriptions say to do the opposite. Anyways, the controller does > perform the write correctly to the DDR. I thought that I would see > the WrFIFO Empty signal go high (it should have written all the data I > put in there). But it stays low...meaning data must be in there. > > Now, lets say I execute another write following the first write > described above. I do this about 50 clock cycles after the first > request. In fact, the controller writes the first data to the DDR > before the second request is even made. This second 64-bits of data > is not written correctly. It is all 0's. I've dug WAY WAY down into > the MPMC2 files in simulation. I am not about to try to figure out > everything they are doing. But is does appear that some internal FIFO/ > Memory is 128-bits wide. I could understand the FIFO not going empty > if it contains an extra 64-bits of 0. And that may explain why the > second write is all 0's. > > I just can't figure out why the core is behaving like this. All > documentation says "BE CAREFUL" when using 64-bit wide memory, but it > doesn't explain enough. I thought I was following the > recommendations. I am putting data in the FIFO before I request the > transfer. And if I try to do word writes (by masking the data pushed > into the FIFO with the BE signal) it still doesn't work. > > Anyone with experience with this port? Any advice would be great. I > saw some posts from a little over a year ago so I am hoping..... The safest way is to put the data in the NPI FIFO before you put the address. It is important that all the data is in the FIFO before you commence the transmission (by putting the address), especially if you do multiple 64bit transfers at the time. Be careful about the byte position: 1234 is transferred as 4321 GuruArticle: 125420
paragon.john@gmail.com writes: > Can anyone point me to a good general purpose paper about selecting > appropriate bit-widths for a fixed point implementation of a signal > processing algorithm? I've looked around and haven't found anything > that describes a general methodology to use. Here is also some Matlab based toolbox, I used http://users.ece.utexas.edu/~bevans/projects/wordlength/converter/index.html . Not very usefull for me, because it didnt convert automaticly / and sqrt, and so I also started manual transformation. >From Washington came the Precise Framework, look for it here: http://fsweb.olin.edu/%7Emchang/publications/mchang_dissertation.pdf And if I remember right, there was a chapter about word length optimization in a book from some of the Lononder Imperial College (...some google-seconds later...): George Constantinides, Peter Cheung und Wayne Luk "Synthesis and Optimization of DSP Algorithms" FlorianArticle: 125421
On 25 Okt., 11:33, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote: > In comp.arch.fpga, > > colin <colin_toog...@yahoo.com> wrote: > > I'm about to place an SPI flash for spartan 3e but I'm a bit > > disapointed in having to place another header to program it via > > impact. > > What will you use the JTAG for? If it's only for testing/debugging > your prototype, you can consider placing only a few solder pads for > the JTAG connection. The little extra hassle is not a problem for > debugging and production will only use the SPI connector. > > -- > Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) the OP is right being disappointed! really he has. i you have JTAG connector or testpads, but can not not use indirect jtag configuration for the SPI programming then its really PITA to add separate SPI header, just because impact doesnt handle indirect SPI for S3e then same way it handles it for S3A AnttiArticle: 125422
Hi so far I hear that "Altera tools are getting better" - now I wonder how long should one wait til they become useable? Q II 7.1, very small design for smallex MAX2 Quartus will self-terminate every few hours, the PC has 2GB RAM, isnt that enought for the ultimate smallest MAX2 !? also the UFM block simulation doesnt want to work at all, well maybe i am doing something wrong yet, but I havent seen the UFM content ever been shifter out in the simulation :( AnttiArticle: 125423
In comp.arch.fpga, Antti <Antti.Lukats@googlemail.com> wrote: > On 25 Okt., 11:33, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> > wrote: >> In comp.arch.fpga, >> >> colin <colin_toog...@yahoo.com> wrote: >> > I'm about to place an SPI flash for spartan 3e but I'm a bit >> > disapointed in having to place another header to program it via >> > impact. >> >> What will you use the JTAG for? If it's only for testing/debugging >> your prototype, you can consider placing only a few solder pads for >> the JTAG connection. The little extra hassle is not a problem for >> debugging and production will only use the SPI connector. > > the OP is right being disappointed! really he has. > > i you have JTAG connector or testpads, but can not not use indirect > jtag configuration for the SPI programming then its really PITA to add > separate SPI header, just because impact doesnt handle indirect SPI > for S3e then same way it handles it for S3A Oh yes, I was disappointed as well. And I didn't even know things are different with the S3A! But I have to get on with my schematics and layout, so I decided to add some pads for the JTAG and a header for the SPI (hope I can find the space for it :-) ). -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)Article: 125424
On Oct 24, 8:44 pm, DialTone <DialT...@faked.com> wrote: > > Hi, > > thanks a lot for reply. I also got idea that it's a great board, > > mainly from others. I have just started and have not find any detailed > > examples how to move forward learning this. > > There are many materials on Xilinx's Web Site but > > all these are mainly about advanced > > programming and there is almost nothing for beginners. > > Hi, > > I'm very new to VHDL/FPGA myself and also have a S3E (the smaller > XC4S500) board. Bought from digilent, it came with no software or manuals > (the manuals are all available from xilinx web site though, of course). > > Not sure if you mean the reference designs athttp://www.xilinx.com/products/boards/s3estarter/reference_designs.htm > > They're certainly quite detailed and complex - I really only looked at > the Rotary Encoder example as this gave quite a simple VHDL design to > experiment with, plus it showed how to read the Rotary thingamajig. > > What I _did_ find really useful to look at (besides the web-based > tutorials and suchlike that you can find with google), was the FPGA > Arcade projecthttp://www.fpgaarcade.com. Both PACMAN and Space Invaders > have been ported to the S3E board, and of course full source is provided. > I also looked at John Kent's excellent FPGA page athttp://members.optushome.com.au/jekent/FPGA.htm- In particular the > System09 project interested me: although there's no version specifically > for the S3E board, there is an S3 version which (although not close > enough to use unmodified) is an interesting insight into VHDL for me. > > I guess it all depends what exactly you want to do with the FPGA, but > perhaps those sites might be useful? > > Good Luck > DT Thanks for update! The sites are just what I look for. :)
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