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 4 helmi, 11:47, John Adair <g...@enterpoint.co.uk> wrote:
> We have a range of solutions but a lot depends on what sort of drive
> you want and how that is going to be implemented. For low cost board
> look athttp://www.enterpoint.co.uk/polmaddie/polmaddie3.html. 60 3V3
> I/O there and the 3 headers are on 0.1"/2.54mm grid so you can make
> stripboard lash-ups to add on.
>
> John Adair
> Enterpoint Ltd.
>
> On Feb 3, 4:07=A0pm, LM <sala.n...@mail.com> wrote:
>
> > I would like to see what kind PWM LED control I could do with FPGA and
> > of course just play with the kit to see what else I can do with it. A
> > FPGA (kit)with plenty of pins and low price is good.
>
> > I am not willing to re invent all the the wheels there is and
> > programming some PC interface, so the kit or FPGA should have some
> > communication port built in. There are plenty of LED controllers
> > already, so that wheel I am happy to reinvent.
I guess I did not put a question here. But you guessed correctly, a
starter kit pointer or name is what I want. It seems I'll know a good
starter kit, when I dont need them any more. 29.9$ is surely a good
price. I am willing to pay a little more though. That board 3 from
Enterpoint is surely one alternative.
Some more info of what I have in mind. A decent ("centipede") cpu has
about 40 free IO pins. That means it could PWM drive that much LEDs. I
am thinking a very simple way, just controlling one LED with one pin.
Programming may become difficult because of timing and so on. I think
I could better describe a PWM control with logic, and timing seems to
be easier.
I need also a bus to get data from PC. What the bus is, is not
important now. Of course, if I have to program it my self, it should
be simple.
Many pins, heh, more than 18. Basic logic outputs, Cmos levels and
speed. I am not going to drive LEDS with FPGA outputs directly. What
is there in the kit is a different matter, but buffers are easy to
build.
With thanks
Leif M
Article: 153351VTC has been developed for very long time. It has been used in many projects and proven to be useful. It should have been available for you long time ago. But I have to spend many years to study laws alone to face to the lawyers from leading EDA, because the counsel fee is too expensive for me. Not long ago, finally my patent was judged to be valid. So I have time to build this website to show some of my ideas. http://www.veriloghdl.org Thanks.Article: 153352
I have an adder: module adder( input [1:0] add1, input [1:0] add2, output [2:0] addout ); assign addout = add1 + add2; endmodule The input is: add1 = 2'bx0; add2 = 2'b00; The RTL simulation result is: addout = 3'bxxx; The Timing simulation result is: addout = 3'b0x0; and this is what I expected. How can I solve the mismatch in RTL simulation?Article: 153353
On 04/02/2012 12:14, Arne Pagel wrote: > did anybody hear something about the availability about the Xilinx > Artix-7 series? > > Especially I am interested in the XC7A8 or XC7A15 in the FTG256 Package. > Are those devices still going to be offered? The latest datasheet has the smallest Artix device as the XC7A100T, which is larger than the smallest Kintex device.Article: 153354
The whole ISE project (VHDL) can be found here: http://www.mediafire.com/?wvvvcjrjl67lcnr Besides ISE project, it also contains two print-screen GIFs, behavioral.gif and post-route.gif. behavioral.gif shows @40ns : start = 1, data = AAAA at next rising CLK edge CS goes LOW then, SDI serially transmits data (101010...) finally, CS goes HIGH (215ns) That is exactly what I would expect from the VHDL code. But the post-route.gif shows something completely different, and I don't know why. What am I doing wrong?Article: 153355
>did anybody hear something about the availability about the Xilinx Artix-7 series? > >Especially I am interested in the XC7A8 or XC7A15 in the FTG256 Package. > > >regards > Arne Sign a Non-Disclosure Agreement with Xilinx, and I'm fairly sure that you will be told... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153356
The "timing" simulation is probably on a post synthesis or post fit netlist= , where the "+" has been converted to a proper adder in whatever logic is a= ppropriate for your application. Describe a complete adder out of plain gat= es and you will get what you want. (i.e. describe a ripple-carry adder or s= ome other architecture) Moreover, why do you care about the details of the output of an adder with = an X input? ChrisArticle: 153357
http://img826.imageshack.us/img826/3067/designp.gif This GIF shows how I actually start the simulator. If I select "tb - behavior (tb.vhd)" in the upper section (and double click Simulate Behavioral Model below) I get the results of behavioral.gif If I select "uut - DAC_STATE...so on" i get all signals as U, but, as a bonus, I do get internal signals in the list, which I don't get otherwise. Really annoying..Article: 153358
As Gabor suggested (in the Xilinx forums), post-route requires 100ns delay for the GSR. After changing the first line to "wait for 140 ns;" it now works. Thanks Gabor, once again. As for the internal signals, that is for another thread.Article: 153359
Ok, if someone else has problems with internal signals, this is how I do it now: in this GIF http://img826.imageshack.us/img826/3067/designp.gif use "tb - behavior (tb.vhd)", NOT "uut - DAC_STATE...so on.." to view internal signals, open Instances and processes panel (and Objects, of course) open "tb", and click on "uut" to see internal signals, as shown here http://img834.imageshack.us/img834/4431/inernalbehavioral.gif drag signals and click on Re-launch. I'm not saying this is the way to go, but I'm using it now.Article: 153360
On Feb 2, 6:48=A0pm, Alan Fitch <a...@invalid.invalid> wrote: > On 03/02/12 00:16, Alan Fitch wrote: > > > > > > > On 02/02/12 16:47, Andy wrote: > >> On Feb 1, 5:08 pm, Alan Fitch <a...@invalid.invalid> wrote: > > <snip> > > >>> I believe it is a bug in Isim. > > >>> I'm basing this on reading section 8.1 of the VHDL 2002 standard "wai= t > >>> statement" where it says there is an implicit sensitivity list derive= d from > > >>> - A function call, apply this rule to every actual designator in ever= y > >>> parameter association > > >>> and > > >>> =97 An indexed name whose prefix denotes a signal, add the longest st= atic > >>> prefix of the name to the > >>> sensitivity set and apply this rule to all expressions in the indexed= name > > >>> As you're using vec(1), the longest static prefix is behavioural.vec(= 1), > >>> so vec(1) should trigger the wait until whenever it changes. > > >> I believe that is not correct. The LSP is ...vec (the whole vector). > >> So processes that appear to be sensitive to one bit of a vector are > >> also sensitive to other bits in the vector, but the > >> rising_edge(vec(1)) function invoked by the wait statement is only > >> looking at vec(1). > > > Hi Andy, > > =A0I was (perhaps foolishly) assuming that because 1 is a constant, the > > slice could be statically determined - but you could well be correct, I > > really need to go away and read the definition of longest static prefix > > again > > Ok, here's the text from 1076-2002 > > "Furthermore, a name is said to be a locally static name if and only if > one of the following conditions hold: > > ... > > =97 The name is an indexed name whose prefix is a locally static name, an= d > every expression that appears as part of the name is a locally static > expression. > > =97 The name is a slice name whose prefix is a locally static name and > whose discrete range is a locally static discrete range. > > A static signal name is a static name that denotes a signal. The longest > static prefix of a signal name is the name itself, if the name is a > static signal name; otherwise, it is the longest prefix of the name that > is a static signal name. Similarly, a static variable name is a static > name that denotes a variable, and the longest static prefix of a > variable name is the name itself, if the name is a static variable name; > otherwise, it is the longest prefix of the name that is a static > variable name. > > Examples: > S(C,2) --A static name: C is a static constant. > R(J to 16) --A nonstatic name: J is a signal. > --R is the longest static prefix of R(J to 16). > T(n) --A static name; n is a generic constant. > T(2) --A locally static name." > " > > So I think I was right, > > regards > Alan > > -- > Alan Fitch- Hide quoted text - > > - Show quoted text - I will have to go back and read the definition of LSP. I agree with your assessment that these are locally static names; the question is "what is the relation between a locally static name for an element or slice of an aggregate, and the longest static prefix for than element or slice?" It was my understanding that if there is a named aggregate that contains the object referred to by the locally static name, then the aggregate is still the LSP, not the locally static name. It likely has to do with whether events are tracked separately on inidividual elements of a named aggregate signal, or whether they are only tracked at the aggregate level. And I may be entirely wrong... Thanks for the discussion, AndyArticle: 153361
On Feb 6, 8:42=A0am, Chris Maryan <kmar...@gmail.com> wrote:
>
> Moreover, why do you care about the details of the output of an adder wit=
h an X input?
>
> Chris
Because the actual behavior of the HW is implementation dependent, the
RTL operator does not attempt to define its behavior for inputs
containing meta-values, beyond the whole result being 'unknown'.
To compare the results, I would take the RTL outputs, run them through
a 'X' to '-' ('unknown' to 'dont care') conversion (probably need to
write your own function), and then use std_match() to compare the RTL
vs gate level outputs.
This in effect says that for verification, if the output of the RTL is
not known, then the output of the gate level sim is of no consequence.
Andy
Article: 153362On Feb 3, 5:43=A0am, n...@puntnl.niks (Nico Coesel) wrote: > Record bundles can be bi-directional in VHDL! That's the problem; every element of a VHDL bidirectional record port is bidirectional. You have to use resolved types for each element, and remember to assign benign driven values to elements you want to be input only. It can be done, but it gets ugly. Sometimes (especially testbenches) it is worth the work, but it would be worth even more to be able to define custom record modes for record port types (e.g. master, slave, observer, etc modes for a record port representing a bus interface, each defining different individual in/ out/inout/etc modes on individual record elements). AndyArticle: 153363
On Feb 3, 4:37=A0am, Petter Gustad <newsmailco...@gustad.com> wrote: > Andy <jonesa...@comcast.net> writes: > > For verification, SV is indeed really nice. However, a new open source > > VHDL Verification Methodology (VVM) library of VHDL packages has > > emerged that provides VHDL with some of the capabilities of SV with > > OVM/UVM. > > I took a link at some of the links posted here previously, it looks > nice and it's an improvement. But as far as I could tell it lacked > polymorphism and inheritance. Actually, being built around VHDL protected types, it has some amount of both. Not nearly as clean or capable as SV though. AndyArticle: 153364
It takes some bit manipulation to handle unknowns exactly. That takes programmer time and CPU time (I've done it). Most likely they traded off exactness for speed. Usually, you don’t care about the result unless it is totally defined. As someone else suggested, you might need to write your own model if you want exactness. Gary "Haiwen" wrote in message news:3d0b033f-3994-43d5-a1e6-0fb463b0a86f@n8g2000pbc.googlegroups.com... I have an adder: module adder( input [1:0] add1, input [1:0] add2, output [2:0] addout ); assign addout = add1 + add2; endmodule The input is: add1 = 2'bx0; add2 = 2'b00; The RTL simulation result is: addout = 3'bxxx; The Timing simulation result is: addout = 3'b0x0; and this is what I expected. How can I solve the mismatch in RTL simulation?Article: 153365
This is a multi-part message in MIME format.
--------------010406050703000003000604
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
If you know and love XDL or XDLRC, and if you believe that the research
community's access to these tools provides a benefit to Xilinx, this is
your opportunity to speak up. The xdl tool will no longer be available
as of ISE 14, and unofficial word is that Xilinx does not intend to
provide equivalent capability. We don't believe they're deliberately
trying to withhold that capability: We simply think they see it as a
distraction that provides no benefit for them.
/For those who may be unfamiliar with these tools, XDL is a format that
can be converted to or from mapped NCD, allowing the user to modify any
part of their circuit or its placement or routing, or to perform
arbitrary placement and routing of their own. XDLRC provides all of the
logic and interconnect data for real Xilinx devices, and enables
research into CAD algorithms for real devices.
/
A colleague from BYU (representing RapidSmith) and I (representing Torc)
are scheduled to meet with the Xilinx software folks in two weeks to
discuss this matter, and to appeal for continued functionality
equivalent to XDL and XDLRC. We have no wish to barrage or pressure
them in any way. The data is theirs to do with as they think best. But
to the extent that our community's access to XDL benefits them, we would
like to present that case to them.
I am collecting and framing our arguments, and am open to any
contributions from the comp.arch.fpga community. Any of the following
would be helpful to our cause, in rough decreasing order of importance.
And I relax the strict meaning of XDL here to include capabilities and
low-level device knowledge enabled by XDL:
* Evidence that XDL is used by Xilinx paying customers.
* Evidence that XDL is used by real companies or in real products (or
anything in orbit or beyond).
* Evidence that XDL enables truly novel research and helps
differentiate Xilinx from competitors.
* Evidence that XDL has encouraged universities to adopt Xilinx tools
in classes.
* Evidence that work from the research community based on access to
Xilinx data has benefited research or development at Xilinx.
* Evidence that XDL has helped researchers win funding.
* Evidence that access to Xilinx data has resulted in a good pool of
candidates for Xilinx to hire from.
We do not believe the community's mere desire for access to XDL and
XDLRC carries any weight with Xilinx. But Xilinx is a commercial
company, and anything that aligns with their business model or
objectives, or increases their sales and market share, is likely to
catch their attention.
XDL and related capabilities have been central to my research for the
past ten years, so I am well aware of what we stand to lose. There are
some sympathetic voices within Xilinx, but we probably should not ask
them to make the case for us: We need to do so ourselves. If you have
good suggestions, feel free to respond here, but please also copy me at
mailto:neil.steiner@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions.
Regards,
--------------010406050703000003000604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
If you know and love XDL or XDLRC, and if you believe that the
research community's access to these tools provides a benefit to
Xilinx, this is your opportunity to speak up. The xdl tool will no
longer be available as of ISE 14, and unofficial word is that Xilinx
does not intend to provide equivalent capability. We don't believe
they're deliberately trying to withhold that capability: We simply
think they see it as a distraction that provides no benefit for
them.<br>
<br>
<i>For those who may be unfamiliar with these tools, XDL is a format
that can be converted to or from mapped NCD, allowing the user to
modify any part of their circuit or its placement or routing, or
to perform arbitrary placement and routing of their own. XDLRC
provides all of the logic and interconnect data for real Xilinx
devices, and enables research into CAD algorithms for real
devices.<br>
</i><br>
A colleague from BYU (representing RapidSmith) and I (representing
Torc) are scheduled to meet with the Xilinx software folks in two
weeks to discuss this matter, and to appeal for continued
functionality equivalent to XDL and XDLRC. We have no wish to
barrage or pressure them in any way. The data is theirs to do with
as they think best. But to the extent that our community's access
to XDL benefits them, we would like to present that case to them.<br>
<br>
I am collecting and framing our arguments, and am open to any
contributions from the comp.arch.fpga community. Any of the
following would be helpful to our cause, in rough decreasing order
of importance. And I relax the strict meaning of XDL here to
include capabilities and low-level device knowledge enabled by XDL:<br>
<ul>
<li>Evidence that XDL is used by Xilinx paying customers.</li>
<li>Evidence that XDL is used by real companies or in real
products (or anything in orbit or beyond).</li>
<li>Evidence that XDL enables truly novel research and helps
differentiate Xilinx from competitors.</li>
<li>Evidence that XDL has encouraged universities to adopt Xilinx
tools in classes.<br>
</li>
<li>Evidence that work from the research community based on access
to Xilinx data has benefited research or development at Xilinx.<br>
</li>
<li>Evidence that XDL has helped researchers win funding.</li>
<li>Evidence that access to Xilinx data has resulted in a good
pool of candidates for Xilinx to hire from.<br>
</li>
</ul>
<p>We do not believe the community's mere desire for access to XDL
and XDLRC carries any weight with Xilinx. But Xilinx is a
commercial company, and anything that aligns with their business
model or objectives, or increases their sales and market share, is
likely to catch their attention.<br>
</p>
<p>XDL and related capabilities have been central to my research for
the past ten years, so I am well aware of what we stand to lose.
There are some sympathetic voices within Xilinx, but we probably
should not ask them to make the case for us: We need to do so
ourselves. If you have good suggestions, feel free to respond
here, but please also copy me at <a
href="mailto:neil.steiner@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions">mailto:neil.steiner@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions</a>.<br>
</p>
<p>Regards,<br>
</p>
</body>
</html>
--------------010406050703000003000604--
Article: 153366Andy <jonesandy@comcast.net> wrote: >On Feb 3, 5:43=A0am, n...@puntnl.niks (Nico Coesel) wrote: >> Record bundles can be bi-directional in VHDL! > >That's the problem; every element of a VHDL bidirectional record port >is bidirectional. You have to use resolved types for each element, and >remember to assign benign driven values to elements you want to be >input only. It can be done, but it gets ugly. I never had that problem when synthesizing for Xilinx devices. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153367
On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > I never had that problem when synthesizing for Xilinx devices. Did you simulate your RTL using bidirectional ports? That's where the default driver problem arises, on inout ports that are only read (from the inside). Synthesis can take a lot of liberty with your RTL description because of the static nature of the analysis of the code, and the fact that unknowns are don't cares in synthesis, which means the synthesis tool can do as it pleases, which is usually what pleases the most customers most of the time. AndyArticle: 153368
Andy <jonesandy@comcast.net> wrote: >On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote: >> I never had that problem when synthesizing for Xilinx devices. > >Did you simulate your RTL using bidirectional ports? That's where the >default driver problem arises, on inout ports that are only read (from >the inside). I didn't simulate that particular code. It was back in the days that simulation software wasn't available if you wanted to keep your arms and legs. >Synthesis can take a lot of liberty with your RTL description because >of the static nature of the analysis of the code, and the fact that >unknowns are don't cares in synthesis, which means the synthesis tool >can do as it pleases, which is usually what pleases the most customers >most of the time. AFAIK: for RTL to synthesize each signal needs one driver. Even if it would drive the signal tristate. It probably depends on the tools. My experience is limited to Xilinx. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153369
I'm creating a dual-port ROM, both sides are the same: 7-bit address, 32-bit data. Very simple ISE 13.3 project can be downloaded from here: http://www.mediafire.com/?xmf55vwdb14qvbf =EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF Both Implementing and Generating the bit file gives warning like this one: PhysDesignRules:812 - Dangling pin <DIA0> all the way from DIA0 to DIA31. I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm but am not sure if that applies here. Am I doing something wrong here? Testing on XC3S50A.Article: 153370
AFAIC, this is a bug and should be fixed. I'm creating a ROM, not a RAM.Article: 153371
On 2012-02-10 11:41, aleksa wrote: > I'm creating a dual-port ROM, both sides are the same: 7-bit address, > 32-bit data. > Very simple ISE 13.3 project can be downloaded from here: > http://www.mediafire.com/?xmf55vwdb14qvbf > > Both Implementing and Generating the bit file gives warning like this > one: > PhysDesignRules:812 - Dangling pin<DIA0> > all the way from DIA0 to DIA31. > > I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm > but am not sure if that applies here. > > Am I doing something wrong here? > > Testing on XC3S50A. I think this is probably OK. Have you simulated your design and/or seen that it works as you expect in hardware? I have often seen similar warnings for unused address lines on block RAMs for Microblaze or PPC designs. The ROM and RAM are made from the same Block RAM primitives, so the same connection lines are there, even if not implemented. Maybe somebody else will chime in with a more concrete answer though. SteveArticle: 153372
On Feb 9, 3:32=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > Andy <jonesa...@comcast.net> wrote: > >On Feb 7, 3:14=3DA0pm, n...@puntnl.niks (Nico Coesel) wrote: > >> I never had that problem when synthesizing for Xilinx devices. > > >Did you simulate your RTL using bidirectional ports? That's where the > >default driver problem arises, on inout ports that are only read (from > >the inside). > > I didn't simulate that particular code. It was back in the days that > simulation software wasn't available if you wanted to keep your arms > and legs. > > >Synthesis can take a lot of liberty with your RTL description because > >of the static nature of the analysis of the code, and the fact that > >unknowns are don't cares in synthesis, which means the synthesis tool > >can do as it pleases, which is usually what pleases the most customers > >most of the time. > > AFAIK: for RTL to synthesize each signal needs one driver. Even if it > would drive the signal tristate. It probably depends on the tools. My > experience is limited to Xilinx. > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > nico@nctdevpuntnl (punt=3D.) > -------------------------------------------------------------- Most synthesis tools will convert multiple tri-state drivers on a signal into multiplexers, since most FPGAs do not support internal tri- state busses any more. They assume that the various tri-state enables are mutually exlusive (how else would the tri-state bus have worked?), so a prioritlyless multiplexer is constructed. This can be a handy way of specifying a distributed priorityless mux. Most synthesis tools will convert default 'U' drivers to "undriven" (nothing), which is different behavior from the SL resolution function in simulation (they issue a warning about that). AndyArticle: 153373
On Feb 10, 1:33=C2=A0pm, sbattazzo <sbatta...@gmail.com> wrote: > On 2012-02-10 11:41, aleksa wrote: > > > > > > > I'm creating a dual-port ROM, both sides are the same: 7-bit address, > > 32-bit data. > > Very simple ISE 13.3 project can be downloaded from here: > >http://www.mediafire.com/?xmf55vwdb14qvbf > > =EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB= =BF > > Both Implementing and Generating the bit file gives warning like this > > one: > > PhysDesignRules:812 - Dangling pin<DIA0> > > all the way from DIA0 to DIA31. > > > I'm aware of this page:http://www.xilinx.com/support/answers/31378.htm > > but am not sure if that applies here. > > > Am I doing something wrong here? > > > Testing on XC3S50A. > > I think this is probably OK. Have you simulated your design and/or seen > that it works as you expect in hardware? No, I haven't simulated it, it is too simple. (did you get the file?) And I haven't tested it with real hardware, bc that was just a test. Maybe someone has 13.4 and has time to test it there? (synthesize and implement) > I have often seen similar warnings for unused address lines on block > RAMs for Microblaze or PPC designs. The ROM and RAM are made from the > same Block RAM primitives, so the same connection lines are there, even > if not implemented. > > Maybe somebody else will chime in with a more concrete answer though. > > SteveArticle: 153374
aleksa <aleksazr@gmail.com> wrote: >I'm creating a dual-port ROM, both sides are the same: 7-bit address, >32-bit data. >Very simple ISE 13.3 project can be downloaded from here: >http://www.mediafire.com/?xmf55vwdb14qvbf >=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF=EF=BB=BF >Both Implementing and Generating the bit file gives warning like this >one: >PhysDesignRules:812 - Dangling pin <DIA0> >all the way from DIA0 to DIA31. > >I'm aware of this page: http://www.xilinx.com/support/answers/31378.htm >but am not sure if that applies here. > >Am I doing something wrong here? No. Open pins should generate a warning. Just tie them to '0'. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
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