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 Thursday, December 4, 2014 7:17:19 PM UTC-5, rickman wrote: > > It was free. I ordered it as a sample. > Why would you *order* a chip that isn't on a board? I have lots of > "sample" chips I've never used because they aren't on a board. I liked the API and documentation. It's a beautiful product. If I ever create my own mainboard, I'll probably use two or three of that component for those reasons. Best regards, Rick C. HodginArticle: 157426
On 12/4/2014 7:24 PM, Rick C. Hodgin wrote: > On Thursday, December 4, 2014 7:17:19 PM UTC-5, rickman wrote: >>> It was free. I ordered it as a sample. >> Why would you *order* a chip that isn't on a board? I have lots of >> "sample" chips I've never used because they aren't on a board. > > I liked the API and documentation. It's a beautiful product. If I > ever create my own mainboard, I'll probably use two or three of that > component for those reasons. I can't say I follow your reasoning. You are using this chip which requires you to find a board to mount it on... but just for a few weeks. Then you will use the "PHY" that you have ordered. Then at a latter time you will use this chip again? Why not just stick with this chip? Once you figure out how to mount it where's the down side? -- RickArticle: 157427
rickman writes: > I can't say I follow your reasoning. You are > using this chip which requires you to find a > board to mount it on... but just for a few > weeks. Then you will use the "PHY" that you > have ordered. Then at a latter time you will > use this chip again? Why not just stick with > this chip? Once you figure out how to mount > it where's the down side? You misunderstand because we're not having a conversation, but only back-and-forth across a written form where assumption and guesswork enter in. And you already seem to have either a natural bias against me, or are having difficulties in understanding me, or both. Don't worry about it though. It will all work out. Best regards, Rick C. HodginArticle: 157428
On 12/4/2014 7:59 PM, Rick C. Hodgin wrote: > rickman writes: >> I can't say I follow your reasoning. You are >> using this chip which requires you to find a >> board to mount it on... but just for a few >> weeks. Then you will use the "PHY" that you >> have ordered. Then at a latter time you will >> use this chip again? Why not just stick with >> this chip? Once you figure out how to mount >> it where's the down side? > > You misunderstand because we're not having a > conversation, but only back-and-forth across a > written form where assumption and guesswork > enter in. And you already seem to have either a > natural bias against me, or are having difficulties > in understanding me, or both. I don't have any bias. I read what you write. If that is not clear I ask questions. But like this time you often don't answer them. So I am left not knowing what is in your mind. This part of the conversation was so disjointed that I reviewed the messages you wrote, so I'm pretty sure I am reading it correctly. If you don't want to discuss this with me, that's fine. If you don't respond I'll stop asking. :) -- RickArticle: 157429
Theo Markettos wrotes: > There are two Altera components that might > be useful... Theo, a lot of useful information. Thank you very much. Best regards, Rick C. HodginArticle: 157430
On 04/12/2014 23:00, Rick C. Hodgin wrote: > On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote: >> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote: >>> I ended up ordering this board: >>> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=830 >>> >>> If anyone has advice on how to get communication running most easily >>> on this board, I would appreciate it. Thank you in advance. >> >> Doesn't look like you have a lot of options on this board. UART serial >> to USB is the one comms choice. I thought you were going to use >> Ethernet. > > I plan to. I won't receive the PHY board I bought until the end of > December though. If there's another option I'll use that in the time > in-between, and possible after that. > > I have one of the Silicon Labs chips arriving this week, but I'll need > to get a converter from its TQFP48 form factor to something usable by > human beings. I may go ahead and do that anyway. The Silicon Labs API > is very clean and straight-forward. > > http://www.silabs.com/products/interface/ethernetcontrollers/Pages/default.aspx > I would look at Microchip's 28j60 controller, you only need a few wires to talk to it (SPI) and there are lots of low cost eval boards available on eBay and other places. http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9 Hans www.ht-lab.com >> That seems to be another $250, wow, more than the FPGA board. >> I guess you can add one via the Arduino interface for next to >> nothing. > > Best regards, > Rick C. Hodgin >Article: 157431
On Friday, December 5, 2014 5:40:46 AM UTC-5, HT-Lab wrote: > I would look at Microchip's 28j60 controller, you only need a few wires > to talk to it (SPI) and there are lots of low cost eval boards available > on eBay and other places. > > http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9 > > Hans > www.ht-lab.com Thank you, Hans. Best regards, Rick C. HodginArticle: 157432
>On 04/12/2014 23:00, Rick C. Hodgin wrote: >> On Thursday, December 4, 2014 5:28:25 PM UTC-5, rickman wrote: >>> On 12/4/2014 12:25 PM, Rick C. Hodgin wrote: <snip> > >I would look at Microchip's 28j60 controller, you only need a few wires >to talk to it (SPI) and there are lots of low cost eval boards available >on eBay and other places. > >http://www.ebay.co.uk/itm/Mini-ENC28J60-Ethernet-Network-Module-For-51-AVR-STM32-LPC-3-3V-/131299274169?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1e920bedb9 > >Hans >www.ht-lab.com > > One issue to note on the ENC28J60 is that it does not do autonegotiation.. Thus if you want/need full duplex you need to manually set the speed and duplex on the receiving port or you will get duplex mismatch and difficult to debug problems. You can not manually set the ports on most cheap network switches and they will (as the standard requires) usually default to 10 half duplex. This is pointed out in the ENC28J60 data sheet but the implications to duplex mismatch may not be obvious to a non network person. Using one to connect to a PC isn't a problem as you can manually set the speed and duplex on the PC port to match that of the ENC28J60 and run 100 full duplex (modulo spi speed of course, I think max spi speed is 25 megabits or so on the ENC28J60) on both ends. None the less a very cheap simple ethernet solution if you pay attention to its limitations. Peter Van Epp --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157433
I was aware that the ICE40 devices have some limitations compared to other devices that are not so cost and power constrained. Until now the apparent lack of LUT RAM escaped me. I guess it is one of those features that is so ingrained in my mind that I never noticed they don't talk about it. The LP family has a very low end member with only 384 LUTs and *no* block RAM, so I was considering what I might do with the LUT RAM. Not much. They don't mention the LUT RAM anywhere and barely mention the LUTs as ROM only peripherally, but I'm pretty sure that is available since it is the same as logic. Wow, the 384 LUT part has no RAM at all, so it ends up being incredibly limited. -- RickArticle: 157434
On Fri, 05 Dec 2014 15:16:03 -0500 rickman <gnuarm@gmail.com> wrote: > I was aware that the ICE40 devices have some limitations compared to > other devices that are not so cost and power constrained. Until now the > apparent lack of LUT RAM escaped me. I guess it is one of those > features that is so ingrained in my mind that I never noticed they don't > talk about it. The LP family has a very low end member with only 384 > LUTs and *no* block RAM, so I was considering what I might do with the > LUT RAM. Not much. They don't mention the LUT RAM anywhere and barely > mention the LUTs as ROM only peripherally, but I'm pretty sure that is > available since it is the same as logic. > > Wow, the 384 LUT part has no RAM at all, so it ends up being incredibly > limited. > > -- > > Rick At that point it's basically just a CPLD killer. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157435
On 12/5/2014 3:54 PM, Rob Gaddi wrote: > On Fri, 05 Dec 2014 15:16:03 -0500 > rickman <gnuarm@gmail.com> wrote: > >> I was aware that the ICE40 devices have some limitations compared to >> other devices that are not so cost and power constrained. Until now the >> apparent lack of LUT RAM escaped me. I guess it is one of those >> features that is so ingrained in my mind that I never noticed they don't >> talk about it. The LP family has a very low end member with only 384 >> LUTs and *no* block RAM, so I was considering what I might do with the >> LUT RAM. Not much. They don't mention the LUT RAM anywhere and barely >> mention the LUTs as ROM only peripherally, but I'm pretty sure that is >> available since it is the same as logic. >> >> Wow, the 384 LUT part has no RAM at all, so it ends up being incredibly >> limited. >> >> -- >> >> Rick > > At that point it's basically just a CPLD killer. Yes, you are exactly right. Lowest possible price. They have an ICE40LM line that only uses configuration RAM with no internal configuration storage. Funny how you can read the data sheet looking for the raison d'etre of a part but can't see it because of the marketing crap. I've seen this sub family for a while now and always thought it was about the hard cores (I2C, SPI, etc). It is about the lowest possible cost meaning no config storage. I guess the assumption is the configuration is stored elsewhere for pennies. -- RickArticle: 157436
The board has arrived! The board has arrived! Shout from the roofs, "The board has arrived!" :-) Best regards, Rick C. HodginArticle: 157437
Hello,
I know this topic is beaten to death but I am a bit unlcear some things.
I've recently encountered metastability issues that caused my FPGA to do
unpredictable things. Someone suggested that I synchronize my inputs to
the clock domain and that seemed to solve the issue. Googling this topic
showed that a two stage Flip Flop is sufficient to increase MTBF for
metastability. My question is do I need to do this for all input signals?
How would one do this with a design containing 30 to 40 input signals?
Which types of inputs can I get away with not using two stage FF?
So in the sample code below, both INA or INB can change state while the clk
is transitioning and this could lead to metastability. Synchronizing INA
and INB would help, but what about INC and IND?
Would the experts just synchronize everything and forget about it?
-----------------------------------------------------------------------------------------
-- Sample code with asynchronous inputs
-----------------------------------------------------------------------------------------
entity blackbox is
port (
Clk : in std_logic;
RST : in std_logic;
INA : in std_logic;
INB : in std_logic;
INC : in std_logic;
IND : in std_logic;
Out : out std_logic
);
end blackbox;
architecture Behavioral of blackboxis
begin
BB: process(Clk, RST) is
begin
if(RST = '1') then
Out <= '0';
elsif(Clk'event and Clk = '1') then
if(INA = '1' and INB = '1') then
Out <= INC;
else
Out <= IND;
end if;
end if;
end process BB;
-----------------------------------------------------------------------------------------
Any feedback is much appreciated.
Thanks
HV.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 157438On Tue, 09 Dec 2014 18:22:41 -0600 "hvo" <91991@embeddedrelated> wrote: > Hello, > > I know this topic is beaten to death but I am a bit unlcear some things. > > I've recently encountered metastability issues that caused my FPGA to do > unpredictable things. Someone suggested that I synchronize my inputs to > the clock domain and that seemed to solve the issue. Googling this topic > showed that a two stage Flip Flop is sufficient to increase MTBF for > metastability. My question is do I need to do this for all input signals? > How would one do this with a design containing 30 to 40 input signals? > Which types of inputs can I get away with not using two stage FF? > > So in the sample code below, both INA or INB can change state while the clk > is transitioning and this could lead to metastability. Synchronizing INA > and INB would help, but what about INC and IND? > > Would the experts just synchronize everything and forget about it? > > ----------------------------------------------------------------------------------------- > -- Sample code with asynchronous inputs > ----------------------------------------------------------------------------------------- > entity blackbox is > port ( > Clk : in std_logic; > RST : in std_logic; > INA : in std_logic; > INB : in std_logic; > INC : in std_logic; > IND : in std_logic; > Out : out std_logic > ); > end blackbox; > > architecture Behavioral of blackboxis > begin > > BB: process(Clk, RST) is > begin > > if(RST = '1') then > Out <= '0'; > elsif(Clk'event and Clk = '1') then > if(INA = '1' and INB = '1') then > Out <= INC; > else > Out <= IND; > end if; > end if; > end process BB; > ----------------------------------------------------------------------------------------- > > Any feedback is much appreciated. > Thanks > HV. > > > --------------------------------------- > Posted through http://www.FPGARelated.com Congratulations, you're asking a fundamentally difficult question. Expect to struggle with this answer. What you're looking for is what I call a "single point" of clock domain crossing. What that means is that, for any set of signals that are theoretically time-aligned, you need to have a single point (i.e. one flip-flop) where those signals all neck down to, then all fan back out from in your internal logic. Take a UART receiver. You've got several things inside of the state machine that all need to have the same simultaneous opinion of the state of the RX line. So you resynchronize the RX line with a dual flop synchronizer, and everything inside of your synchronous state machine works off of this synchronized version. If your clock rate is, for instance, 100 MHz, then everything on your synchronous side knows that whatever state the sync_rx signal is in, it'll be constant for 10 ns after each clock. Since everyone is only looking at that signal at the clock edge, and the timing analysis tools make sure that the signal is settled at each destination in under 10 ns, you're guaranteed that everything using sync_rx believes it's got the same state. Now let's say you hadn't resynchronized it. RX can change any time it likes, let's say 5 ns before your clock edge. If it takes 3 ns to get to point A in your state machine, point A will see the new value when the clock edge hits. But if it takes 6 ns to get to point B, it will still see the old value. You've violated the fundamental rule of synchronous design, which is that come the clock edge all data signals are static, and as a result your circuit will behave unpredictably, and unsimulateably. So, given your example, you don't need to resynchronize any of that necessarily. However, given two copies of your example and the desire to have them always have the same output, you would need to resynchronize those inputs, then split the resyncronized signals off to be the inputs to your logic. Though keep in mind that your reset is asynchronous as well. For all the same reasons that any other asynchronous signal can be squirrely around the clock edges, you may well find that one of your two copies of that logic comes out of reset one clock cycle before the other does. Does that matter? That's fundamentally a question of your application. But it's why you see people generate reset signals that are asynchronous on their assertion, but synchronous on their deassertion. There's a lot more to the topic than just this, but that's at least a quick introduction to the sorts of things that come up. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 157439
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: > On Tue, 09 Dec 2014 18:22:41 -0600 > "hvo" <91991@embeddedrelated> wrote: (snip) >> I've recently encountered metastability issues that caused my FPGA to do >> unpredictable things. (snip) > Congratulations, you're asking a fundamentally difficult question. > Expect to struggle with this answer. > What you're looking for is what I call a "single point" of clock domain > crossing. What that means is that, for any set of signals that are > theoretically time-aligned, you need to have a single point (i.e. one > flip-flop) where those signals all neck down to, then all fan back out > from in your internal logic. Yes. While metastability can be a problem, much more common is the multiple signals crossing time domains without appropriate synchronization. > Take a UART receiver. You've got several things inside of the state > machine that all need to have the same simultaneous opinion of the > state of the RX line. So you resynchronize the RX line with a dual > flop synchronizer, and everything inside of your synchronous state > machine works off of this synchronized version. If your clock rate is, > for instance, 100 MHz, then everything on your synchronous side knows > that whatever state the sync_rx signal is in, it'll be constant for 10 > ns after each clock. Since everyone is only looking at that signal at > the clock edge, and the timing analysis tools make sure that the signal > is settled at each destination in under 10 ns, you're guaranteed that > everything using sync_rx believes it's got the same state. Also, metastability decreases exponentially with decreasing clock rate. Multiple signal crossing a time domain can fail easily even at low clock rates. > Now let's say you hadn't resynchronized it. RX can change any time it > likes, let's say 5 ns before your clock edge. If it takes 3 ns to get > to point A in your state machine, point A will see the new value when > the clock edge hits. But if it takes 6 ns to get to point B, it will > still see the old value. You've violated the fundamental rule of > synchronous design, which is that come the clock edge all data signals > are static, and as a result your circuit will behave unpredictably, and > unsimulateably. > So, given your example, you don't need to resynchronize any of that > necessarily. However, given two copies of your example and the desire > to have them always have the same output, you would need to > resynchronize those inputs, then split the resyncronized signals off to > be the inputs to your logic. There is also the case when multiple signals have to cross a clock domain and remain consistent. One favorite case is the counter for a RAM based FIFO. Converting to gray code (or counting in gray code) means that only one signal changes at any count transition. Either the before or after value will be seen on the other side, but not any other miscombination of bits. > Though keep in mind that your reset is asynchronous as well. For all > the same reasons that any other asynchronous signal can be squirrely > around the clock edges, you may well find that one of your two copies > of that logic comes out of reset one clock cycle before the other > does. Does that matter? That's fundamentally a question of your > application. But it's why you see people generate reset signals that > are asynchronous on their assertion, but synchronous on their > deassertion. > There's a lot more to the topic than just this, but that's at least a > quick introduction to the sorts of things that come up. -- glenArticle: 157440
This is an old thread, but I had the same errors. Turns out I didn't have the hardware configured correctly. When I finally did a clean build on my project, the BSP didn't compile and threw an error telling me that I didn't have the interrupt enabled on the ethernet controller. tl;dr Try doing a clean build and checking errors.Article: 157441
I had the same error of not having the correctly included files. Turns out I had an error while compiling the BSP. I didn't have the interrupt checkbox enabled on the ethernet controller, causing the error. Do a clean build and it will be easier to spot any errors.Article: 157442
On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote: > > Also, metastability decreases exponentially with decreasing clock rate. Can you explain this claim? I can't think of any reason why metastability would be anything but linear with clock rate if the same slack time is available. -- RickArticle: 157443
On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote: > On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote: >> >> Also, metastability decreases exponentially with decreasing clock rate. > > Can you explain this claim? I can't think of any reason why > metastability would be anything but linear with clock rate if the same > slack time is available. http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf Note the straight lines on the log/linear graph in Figure 2. For this particular family (V2P) the constants are such that with only a modest number of ns slack, the probability of failure drops to less than once in the lifetime of the universe. Regards, AllanArticle: 157444
On 12/10/2014 5:30 AM, Allan Herriman wrote: > On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote: > >> On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote: >>> >>> Also, metastability decreases exponentially with decreasing clock rate. >> >> Can you explain this claim? I can't think of any reason why >> metastability would be anything but linear with clock rate if the same >> slack time is available. > > > http://www.xilinx.com/support/documentation/application_notes/xapp094.pdf > > Note the straight lines on the log/linear graph in Figure 2. > > For this particular family (V2P) the constants are such that with only a > modest number of ns slack, the probability of failure drops to less than > once in the lifetime of the universe. That's what I thought. You are confusing the time allowed for the metastable event to settle with clock speed. The two are not the same thing at all. I can lay out a circuit with a design goal of 100 MHz and end up with 2 ns slack on the critical route while I lay it out with a design goal of 50 MHz and end up with 1 ns slack on the critical path. The *only* thing that is important is the slack time where the output has time to settle. It is interesting that the labeling of the two graphs and the text in the body of the document all describe this data differently and *none* of them can be interpreted as "slack" time by what I am reading. But I'm sure that is what they mean. "Metastable measurement results are listed in Table 1 and are plotted in Figure 2. The time plotted on the horizontal axis includes the clock-to-out delay of QA, plus a short interconnect delay, plus the setup time at the input of the QC flip-flop" "Cloc-to-Q + Setup + Metastable Delay (ns)" "Cloc-to-Q + Setup Metastable Delay (ns)" I expect the label in Figure 3 is just a typo. But given that the label doesn't make sense either way I'm not sure I care. -- RickArticle: 157445
On Tuesday, December 9, 2014 7:22:46 PM UTC-5, hvo wrote: > Hello, >=20 > I know this topic is beaten to death but I am a bit unlcear some things. >=20 > I've recently encountered metastability issues that caused my FPGA to do > unpredictable things. Someone suggested that I synchronize my inputs to > the clock domain and that seemed to solve the issue. Actually, it is much more likely that the problem you saw has absolutely no= thing to do with metastability. What you described and how you fixed it so= unds like either a clock domain crossing or possibly clock skew between the= part generating the input signal and your internal design clock...in short= it is a setup/hold time problem. What you added to fix your design sounds= like a single flip flop per input signal, then that also suggests the prob= lem is not metastability. The point here is not to belabor terminology, bu= t to help you understand it. Any of your inputs that lead through logic that ends in a flip flop (which = will be every input signal in nearly any design) will have setup and hold t= ime requirements that must be met. To find out what your requirements are = review the timing analysis report for your design where the setup and hold = time requirements for each input will be listed. Those timing requirements= are relative to some clock signal in your design. Do those signals actual= ly get generated in the same clock domain? If so, is Tco + PCB prop delay = + Setup time requirement + Clock Skew less than the clock period? If those= signals are not generated in the same clock domain, then ask yourself how = is that input going to be able to meet the setup and hold time requirements= ? (Hint: The answer is that it will not). This is the situation where yo= u are crossing clock domains and the synchronizing flip flop that you added= is needed. The setup/hold time requirements will still not be met at the input to that= flip flop but that is 'OK', since the rest of your design uses the output = of the flip flop, not the input. Now that synchronizing flip flop might mi= sbehave (i.e. take a longer than normal time to settle) because the inputs = did not meet the setup/hold time requirements, so the solution there is to = add a second flip flop and then the rest of your design uses the output of = the second flip flop. The first flip flop 'misbehavior' is what is called = metastability. Generally, a two flip flop chain is all that is required to= cross the clock domain and reduce metastability to an acceptably low numbe= r. The short answer to your question though is that whenever an input signal d= oes not meet the setup and hold time requirements of your design, you will = need to synchronize it first before using it elsewhere in your design. Kevin JenningsArticle: 157446
On Wed, 10 Dec 2014 02:17:59 -0500, rickman wrote: > On 12/10/2014 1:55 AM, glen herrmannsfeldt wrote: >> >> Also, metastability decreases exponentially with decreasing clock rate. > > Can you explain this claim? I can't think of any reason why > metastability would be anything but linear with clock rate if the same > slack time is available. If you clock a FF at time t, and you don't use the result until time t + Ts (Ts being your clock period), then the FF has that whole Ts-long period to resolve the metastability one way or another. That part will be exponential with Ts. But yes, you would expect a linear part, too. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157447
On Tue, 09 Dec 2014 18:22:41 -0600, hvo wrote: > Hello, > > I know this topic is beaten to death but I am a bit unlcear some things. > > I've recently encountered metastability issues that caused my FPGA to do > unpredictable things. Someone suggested that I synchronize my inputs to > the clock domain and that seemed to solve the issue. Googling this > topic showed that a two stage Flip Flop is sufficient to increase MTBF > for metastability. My question is do I need to do this for all input > signals? > How would one do this with a design containing 30 to 40 input signals? By having lots of such inputs -- but see the other, more detailed answers for a better idea. > Which types of inputs can I get away with not using two stage FF? Any input that is guaranteed to be settled when you clock it in. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157448
> > It's up to Him though. I've been working on this project for over > 28 months. I haven't found anyone to help me yet, though several > people have been interested at various times, none of them had the > necessary C/C++ coding skills to contribute. I've contacted > Christian universities, posted on forums, etc. But, I am hopeful. > :-) > > Best regards, > Rick C. Hodgin Perhaps Terry Davis would be interested in your project. http://www.templeos.org/Wb/Doc/Charter.htmlArticle: 157449
He's been suggested before at various times. The Temple OS guy records responses he says came from God when asked. His skills are most adequate, but his general relationship with God is keeping me at a distance. Best regards, Rick C. Hodgin
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