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
"eric" <erixx@gmx.net> wrote > There is another simple possibility to speed up calculations. > Do you know that the GPU on a modern graphics card can do matrix > calculations a lot times faster than a CPU? There are several > SDKs and you wont need special Hardware for that. > > Xilinx and Altera stuff takes a lot of time and a high risk > because if you really have a problem to solve the engineers from there > say: "This is not supported"... You get only help if you a buying in large > quantaties. > > And in scientific computing you never have a large quantatie. > > > So use alternativly a GPU for fast calculations like FFT and Sorting. > > My favorite SDK is BrookGPU > (http://graphics.stanford.edu/projects/brookgpu/). > Easy to use and a lot of out oft the box runnig examples. It works with > every modern 3d Accellertor because it uses OpenGL and DirectX. > > You will implement the stuff in a week or two. In VHDL you'll need half a > year for the simulation and timig stuff for the same result. > > Think about it! GPU have a lot of limitations like single precision FP, memory bandwitdh/latency and organization, computation model, etc. Well it's the old ASIC(fixed) vs FPGA topic ;-) MarcArticle: 111576
hallo everyone, I know that global clocks allow distributing the clock signal all over the FPGA with a low skew, but what happens, when i feed the clock e.g. my_clk into FPGA through a normal user I/O pin? I have set XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the error in Xilinx ISE, my interest ist: what will happen with my_clk? Goes it after the input buffer still to the global clock buffer, or wires will be routed to all the flip-flops, which my_clk connectecd to? or somehow else? Thanks for your answer Regard, ChengArticle: 111577
radarman wrote: > martstev@gmail.com wrote: > > I am using Altera Stratix II FPGA and also power supervisor circuit > > which generates reset which it tied to nCONFIG for configuration of > > the FPGA. Now, I'd like to generate RESET for the FPGA after the > > configuration and Initialization is complete everytime. I can't find a > > part that can do that..any suggetions? > > If you are reconfiguring the part on reset, why do you want to reset > the design again? The design will come up in the "reset" state after > configuration. Perhaps I'm missing something, but it seems redundant to > async reset an FPGA right after configuration? One case might be when you want the reset behaviour to set a flip flop to '1' instead of '0' (like in a one hot state machine encoding) and the synthesis tool/target device combo doesn't happen to support this. If you have this, then the problem is with the synthesis tool (so open a service request and raise your beef) but in the mean time you need a work around. So if you happen to have that particular scenario, but your device globally clears all flip flops to 0 then you could use the "reset to 0 coming out of configuration" to create an internal reset signal for the rest of the design. Then you use that internal reset signal to put the entire design into the state that you want as specified by your HDL instead of as specified by the device manufacturer. KJArticle: 111578
Tommy Thorn wrote: > lancepickens@gmail.com wrote: > > Hi, > > Coming from a scientific computing standpoint (with no hardware > > experience). > > I was wondering if you can improve any dedicated tasks by designing a > > special > > purpose chips ala FPGA to run your code? Does anyone have any > > experience > > with this? Tommy, There is a lot of papers around about software to FPGA migration projects. (The highest speed-up factor I found there is 6000.) A few of them are referenced in: http://xputers.informatik.uni-kl.de/staff/hartenstein/lot/HartensteinWRCE06.pdf Rainier > > Yes. > > TommyArticle: 111579
Hi everyone, I am trying to add a USB 480Mbps interface to my fpga design which will stream data in one direction only from the FPGA to PC. The avnet evaluation board I have has the Cypress 68013 chip. Can anybody point me in the right direction of where to start (or which is the most suitable application note on the cypress website), and if there is any sample cores to embed on the fpga. Thanks very much, AlArticle: 111580
"al99999" <alastairlynch@gmail.com> wrote in message news:1162822979.389980.211390@h54g2000cwb.googlegroups.com... > > The avnet evaluation board I have has the Cypress 68013 chip. > > Can anybody point me in the right direction of where to start (or which > is the most suitable application note on the cypress website), and if > there is any sample cores to embed on the fpga. Use the 'slave fifo' interface of the 68013. Use it in one of its synchronous modes. (I tend to clock the FPGA off the 48MHz clock from the 68013). After that, it's really simple, provided you've set the 68013 up correctly - you watch the appropriate 'fifo-full' flag from the 68013 and drive data in accordingly. You need the technical reference manual for the 68013 (FX2), not just the datasheet. (Both from Cypress' TERRIBLE website) You will probably find that the PC is a bottleneck, particularly if you don't make an effort to keep lots of overlapped reads queued on to the USB driver. If you've never done anything with USB or device drivers before, start with the Cypress "USB developer uStudio" or whatever they call it (CY4604) - the CyUSB.sys generic driver. I can never find it on their TERRIBLE website, but it's there somewhere. The FPGA -> FX2 link is trivial. The rest of the development might be harder. WillArticle: 111581
Hi KJ,
>>> Tell me what prevents everyone from standardizing on an interface to
>>> their components in a manner similar to what LPM attempts to do? The
>>> chip guys do it for their parts, the FPGA vendors don't seem to want to
>>> do anything similar on the IP core side.
>> I don't think anything prevents it, other than whatever all-pervading
>> force there is in the universe which prevents people from agreeing about
>> things. :-)
> But it's not really an all-pervading force. If it were we wouldn't have
> any standards like PCI, I2C, PCI Express, DDR....on and on and on. So
> where is the list of interface standards for inside the chip?
I wish I could be that idealistic! :-) Here are two questions to which I
don't have precise answers:
(1) How many DDR SDRAM chips were sold worldwide in 2005?
(2) How many FPGA IP cores were sold worldwide in 2005?
With or without actually finding the answers, now speculate as to the
relative importance of standardization for these two application areas.
> Wishbone is about it for FPGAs...and it needs some work but it's not bad.
It's not one-size-fits-all though; in fact, nothing really is. That is half
of the problem. Many of the more interesting IP cores use variable and/or
non-standard word sizes, have non-obvious flow control requirements stemming
from extensive pipelining and buffering, and so on.
If every FPGA user just wanted to build SoCs based around a microprocessor
with a big old local bus with all the peripherals hanging off it, then life
would be much easier. As it is, we try to provide the most flexible
interfacing options possible, so that no-one is prevented from using a
particular core just because their system is wired together in a way that we
hadn't thought of.
> So do the big guys all support Wishbone? Build it into their system
> design tools? Ummmm....well....no....what do they support? Well, here is
> the Brand A 'standard', brand X standard etc.
In an embedded system-builder context, brand A have their proprietary bus,
whereas brand X's bus structure did at least come from IBM (which in my mind
makes it "somewhat more standard"; you may of course disagree).
When it comes to "raw" IP blocks, the basic, pervasive idioms of two-wire
synchronous handshakes and simple flow-controlling pulses are simple to
comprehend and use. The names and exact timings may be different but if you
go and compare the datasheet-specified interface for a brand X Turbo Encoder
and the brand A equivalent, you'll probably find there's very little
difference.
> Choosing a standard based on features and performance that are relevant is
> exactly the right thing. That's not what you're basing your decision on
> between 'X' and 'A'.
I would respectfully disagree, certainly as far as embedded processing is
concerned. Sure, there are many other important factors, and many people do
treat - or try to treat - FPGAs as commodity products, but I would certainly
not make a big A vs X purchasing decision without making a diligent study of
the relative merits of the microprocessor interfaces favoured by each
vendor.
Cheers,
-Ben-
Article: 111582KJ wrote: > One case might be when you want the reset behaviour to set a flip flop > to '1' instead of '0' (like in a one hot state machine encoding) and > the synthesis tool/target device combo doesn't happen to support this. > If you have this, then the problem is with the synthesis tool (so open > a service request and raise your beef) but in the mean time you need a > work around. So if you happen to have that particular scenario, but > your device globally clears all flip flops to 0 then you could use the > "reset to 0 coming out of configuration" to create an internal reset > signal for the rest of the design. Then you use that internal reset > signal to put the entire design into the state that you want as > specified by your HDL instead of as specified by the device > manufacturer. > > KJ > Or just invert the inputs and outputs of the ff you need initialized to a '1'.Article: 111583
Martin Thompson wrote: > Maybe I'll regret jumping in here, but here's my take :-) > > We designers want standard interfaces to FPGA bits and bobs. <snip> It's nice to hear another opinion, but.... I have a software guy that wants us FPGA designers to standardize on 16550 UARTs for our embedded designs. WTF?! This device is from a quarter century ago and made to work with serial links that are quite a bit worse than the embedded applications I have today. WHY is a standard interface desired when much of what "was" there can become completely superfluous? Personally - and this is opinion as it is with the other posts - I want to get the best performance/cost/size balance I can strike. Why should I burden my design with bloated code to pacify others who want to blow my performance, increase my cost, or bloat the size? If you want a standard interface, make one. PLEASE don't force me to use silicon with hard-coded features that are much less than what they could be all for the sake of conformance. The only time I would care to see a standard interface pursued is if there is ZERO impact to my engineering tradeoffs. - John_HArticle: 111584
Hi Tim,
"Tim" <gueneysu@crypto.rub.de> wrote in message
news:1162575331.736771.230780@h48g2000cwc.googlegroups.com...
> Sorry for my unclear explanation. Using your simplification with 64
> bits my goal is to do the following chain of full 64 additions (for
> example 3 operations a 64 bit):
>
> BA [DSP #1; A:B ]
> + DC [DSP #1; C]
> + FE [DSP #2, A:B] <<--- takes PCIN from DSP #1
> + HG [DSP #3, A:B] <<--- takes PCIN from DSP #2
> --------
> (Z)YX [3, P]
Ah, I see, you're doing a 256-bit accumulation. In this case, I'm not sure
that there's much that can be done within an architecture like that, because
as you say, the "dummy" top bits of the result will be changed depending on
the carry and there's no way to mask them out when you feed back the P
output value for further accumulation.
Personally, I would structure the computation as a fully-parallel adder tree
(assuming you really do have four inputs, and not some nasty number). That
does require moving the intermediate results through the fabric, but it's
not too hard to pipeline it - you'll probably need to introduce some
registers to balance the latency anyway. I'd also consider using more than
just 32 bits out of each DSP slice; why use 8 DSP blocks when you could use
just 6?
At least it sounds like you have a good handle on what you're trying to do,
so good luck!
Cheers,
-Ben-
Article: 111585Cheng, I am in the middle of a Virtex4 design myself and have gone back and forth with Xilinx about clock routing. The documentation is very poor, particularly with respect to the regional clock boundaries. As I understand it, yes you can drive a BUFG from anywhere in the FPGA fabric if you want, however the routing is not ideal. So, while you still have no skew problems within the FPGA, because everything is on the global clock net, you could have skew problems with any other system synchronous devices in the design. (i.e. sync. srams, etc... ddr sdrams will be source syncronous, so there is no problem here)... To confirm this though... I would run ISE with your design and follow the routing in FPGA Editor just to be POSITIVE that everything routed as you wanted. This is just what I recall. uvbaz wrote: > hallo everyone, > > I know that global clocks allow distributing the clock signal all over > the FPGA with a low skew, but what happens, when i feed the clock e.g. > my_clk into FPGA through a normal user I/O pin? > > I have set XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the > error in Xilinx ISE, my interest ist: what will happen with my_clk? > > Goes it after the input buffer still to the global clock buffer, or > wires will be routed to all the flip-flops, which my_clk connectecd to? > or somehow else? > > Thanks for your answer > > Regard, > ChengArticle: 111586
>
> Or just invert the inputs and outputs of the ff you need initialized to
> a '1'.
That can work in certain instances, but you'll have difficulty
'inverting' an enumerated type signal that gets encoded via a one hot
(or any other) encoding. See the following code snippet below for a
good example. Generating the reset signal itself is much cleaner and
puts the device into a state as defined by the HDL code itself and not
in some arbitrary (but useful) predefined state that has been defined
by the FPGA/CPLD vendor.
type t_FOO is (Init, Idle, Do_Something, Do_Something_Else,
Phone_Home);
signal My_State_Variable: t_FOO;
...
process(Clock)
begin
if rising_edge(Clock) then
if (Reset = '1') then
My_State_Variable <= Init;
else
......
KJ
Article: 111587"ALuPin@web.de" <ALuPin@web.de> writes: > No. > > := (others=>'0'); > > in signal declarations are not synthesizable. > That depends on your synthesiser. If you are initalising to some constant value that the synth can figure out, XST can do it and I think Synplify does it as well. About time too, given that the hardware has been able to use it for years (or even decades!) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 111588
On 2006-11-06, slkjas@gmail.com <slkjas@gmail.com> wrote: > Hi > > Im trying to design a high speed data capture card. Im using a Lattice > ECP2M-50 FPGA with the one-board SERDES units (MGBT in Xilinx > dtasheets). Im using a MSPS Nation ADC. This dual ADC has a output of > 1Gb/s and thus the combined x4 lane PCIe will match this rate. HOWEVER, > if there is latency on the PCIe bus more than 100us then my RAM inside > the FPGA will overflow. I need to know bus latency between TLP's > because i need to know if I require external RAM or if the design in > possible! First of all, this post assumes you mean Gigabyte/s (GB/s) since you are talking about matching the rate with a 4 lane PCIe configuration. I see at least one real problem here: PCIe has a link speed of 2.5 GHz per lane. After 8B/10B decoding you will have 250 MB/s. With 4 lanes you will get 1000 MB/s. (Exactly what you need.) Unfortunately you will have protocol overhead. This means that you will not even theoretically be able to push data in the speed required by your application (Assuming that you truly need 1 GB/s and not say for example 950 MB/s.) Perhaps you can design the card so that in case of emergency (your PCIe host cannot accept your packets fast enough) you will reduce the precision of your samples from 8 bits (which I assume you use) to 4 bits and somehow tell your application that the precision is not enough. But quite a lot depends on your application. For example: 1. Do you just want to store as much data as you can fit into your main memory? 2. Do you intend to do some sort of real time processing on the data in your host? 3. As mentioned earlier, do you truly need exactly 1GB/s? In that case, you will need more than 4 lanes... If 1, perhaps you can use 7 bits / sample instead to reduce the required bandwidth. If 2, perhaps you can do some processing on the data in the FPGA to reduce the bandwidth. As for latency, my guess is that the latency should be far less than 100us. But personally I would not feel very safe unless I had some guarantee from the host system that a certain bandwidth to main memory was reserved for my PCIe card. (At least if the required bandwidth is very close to the theoretical maximum when using maximum sized packets.) I guess your google skills are as good as mine, but I could point out http://nowlab.cse.ohio-state.edu/publications/journal-papers/2005/liuj-ieeemicro05.pdf where the latency and bandwidth of PCI express based Infiniband HCA:s are tested. The latency of a small message is around 3.8 us in this case so from that point of view, 100us should be more than enough. /AndreasArticle: 111589
hallo everyone, I am here again, :) I have download my program to my Xilinx Virtex-4 FPGA, and connect the Oscilloscope to the output. But the output seems to be strange, i have the Bild uploaded to the URL: http://homepage.ruhr-uni-bochum.de/Qian.Tang-2/cheng/D012.jpg Thanks for your answer, ;) Regards, ChengArticle: 111590
On 3 Nov 2006 13:04:07 -0800, "radarman" <jshamlet@gmail.com> wrote: >If you are reconfiguring the part on reset, why do you want to reset >the design again? The design will come up in the "reset" state after >configuration. Perhaps I'm missing something, but it seems redundant to >async reset an FPGA right after configuration? Don't know about Stratix, but I guess there may be timing problems with the configuration reset, so you might want to do a proper timed reset afterwards. [OT for Altera...] Many Xilinx devices will let you set a F/F to one level on GSR, and the opposite level on a 'normal' reset, by setting SRHIGH(LOW) differently from INIT1(0). What's the point of that? Beats me. Curiously, in the Spartan-3 you get an INIT attribute to set SRHIGH/SRLOW, but no attribute to set INIT1/INIT0. To set those you have to manually instantiate an FDSE/FDPE or an FDRE/FDCE component. Did Xilinx give us the wrong attribute? If we had something to set INIT1/0 instead, then SRHIGH/LOW would automatically default "correctly", and you wouldn't need to manually select a set or a reset F/F. And how about a sync/async attribute? I can't find one of those either. EvanArticle: 111591
Hi Goran, Is there any way to instruct the platgen not to use RLOC for the microblaze? It is just that now (after doing what you suggested above) my mapping went well but the PAR fails - It says that a certain core (xilinx reed-solomon decoder) cannot be placed. I figured out that maybe the RLOCs of the microblaze causes this problem (my chip utilization is under 50%). Thanks in advance, Mordehay. error snippet from par log file : ---------------------------------------------------------------------------= ----------------------------------------------- Starting Placer Phase 1.1 ERROR:Place:346 - The components related to The RPM "CORE/RFEC_i/rs_dec_i/rs_docoder_i/rs_dec/dec/sy/nig1/ffo1/r1" can not be placed in the required relative placement form The following components are part of this structure: SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N207 SLICEL CORE/RFEC_i/rs_dec_i/rs_docoder_i/N19412 SLICEL CORE/RFEC_i/rs_dec_i/rs_docoder_i/N19411 SLICEL CORE/RFEC_i/rs_dec_i/rs_docoder_i/N19409 SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N208 SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N204 SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N202 The reason for this issue is the following: This logic may be too large or of too irregular shape to fit on the device. ---------------------------------------------------------------------------= -----------------------------------------------Article: 111592
uvbaz wrote: > hallo everyone, > > I know that global clocks allow distributing the clock signal all over > the FPGA with a low skew, but what happens, when i feed the clock e.g. > my_clk into FPGA through a normal user I/O pin? > > I have set XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the > error in Xilinx ISE, my interest ist: what will happen with my_clk? > > Goes it after the input buffer still to the global clock buffer, or > wires will be routed to all the flip-flops, which my_clk connectecd to? > or somehow else? > > Thanks for your answer > > Regard, > Cheng > You should instantiate a bufg on your clock net to make sure it gets onto the global routing. Not all synthesis tools automatically insert that buffer, and without it, you won't get on the global clock net. Assuming you do have that buffer, the clock that is distributed in the FPGA will have low skew, but there will be a sizable offset from the external clock. That may cause problems with communicating with devices external to the FPGA.Article: 111593
On 6 Nov 2006 07:51:38 -0800, "uvbaz" <uvbaz@stud.uni-karlsruhe.de> wrote: >http://homepage.ruhr-uni-bochum.de/Qian.Tang-2/cheng/D012.jpg I hope this is not insulting... have you checked that your 'scope probe is correctly compensated? Try looking at a known good square wave, for example the oscilloscope's calibration output. Also, check that the scope's ground wire is properly connected. -- 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: 111594
On 6 Nov 2006 02:02:38 -0800, "tsemer" <tsemertzidis@gmail.com> wrote: >I need a fast fpga because the signal will be proccessed @ near 800Mhz. Don't forget: one bit at 800MHz can be processed as eight bits at 100MHz, or sixteen bits at 50MHz. Maybe you don't need such a fast FPGA after all, but only some ingenuity about how you handle the inputs. What is the signal? -- 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: 111595
I couldn't agree more, John. I have no use for primitives, or IP for that matter, that has been crippled or bloated in order to comply with some arbitrary "standard" that is not likely to match my needs anyway. Much more important is complete, concise, and clear documentation, visibility into the guts of the IP, and tools that work properly.Article: 111596
Ray Andraka wrote: > uvbaz wrote: > > I know that global clocks allow distributing the clock signal all over > > the FPGA with a low skew, but what happens, when i feed the clock e.g. > > my_clk into FPGA through a normal user I/O pin? > > You should instantiate a bufg on your clock net to make sure it gets > onto the global routing. Not all synthesis tools automatically insert > that buffer, and without it, you won't get on the global clock net. > Assuming you do have that buffer, the clock that is distributed in the > FPGA will have low skew, but there will be a sizable offset from the > external clock. That may cause problems with communicating with devices > external to the FPGA. Also, the sizable offset will probably change every time you recompile the project. Alan NishiokaArticle: 111597
KJ wrote: >>Or just invert the inputs and outputs of the ff you need initialized to >>a '1'. > > > That can work in certain instances, but you'll have difficulty > 'inverting' an enumerated type signal that gets encoded via a one hot > (or any other) encoding. See the following code snippet below for a > good example. Generating the reset signal itself is much cleaner and > puts the device into a state as defined by the HDL code itself and not > in some arbitrary (but useful) predefined state that has been defined > by the FPGA/CPLD vendor. > > type t_FOO is (Init, Idle, Do_Something, Do_Something_Else, > Phone_Home); > signal My_State_Variable: t_FOO; > ... > process(Clock) > begin > if rising_edge(Clock) then > if (Reset = '1') then > My_State_Variable <= Init; > else > ...... > > KJ > But in that case, you don't care what the encoding is, so you don't need to be specifying a particular flip flop get set to '1'. For the xilinx devices, you can use the ROC primitive to generate a power on reset in your HDL code. The tools pull it out, but in the process in guarantees the setting of the initial values to the states you want them in. POR: roc port map(O => power_on_reset); process(clk,power_on_reset) begin if power_on_reset = '1' then <initial values for any type of signal> elsif rising_edge(clk) thenArticle: 111598
Hi Jonathan, No, it is not insulting at all. Auctually there is an Agilent Softtouch Probes on the FPGA Board(for Logic Analyser), i connected the oscilloscope to the end auf the Agilent Cable, and got the stranger picture. There is another connector direct on the Board, i've just reconfigure the FPGA, so that the FPGA put the output onto this connector, and then i've got the right square wave. It is likely that, this Agilent Cable caused the Problem. Thanks! You have right. But how come you to the point, that the problem there is? Thanks again. Regards, Cheng Jonathan Bromley schrieb: > On 6 Nov 2006 07:51:38 -0800, "uvbaz" > <uvbaz@stud.uni-karlsruhe.de> wrote: > > >http://homepage.ruhr-uni-bochum.de/Qian.Tang-2/cheng/D012.jpg > > I hope this is not insulting... > > have you checked that your 'scope probe is correctly compensated? > Try looking at a known good square wave, for example the > oscilloscope's calibration output. Also, check that the scope's > ground wire is properly connected. > -- > 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: 111599
^_^ ^_^ Yes, i will try it. Regards, Cheng MM schrieb: > "uvbaz" <uvbaz@stud.uni-karlsruhe.de> wrote in message > news:1162831203.738143.159650@h54g2000cwb.googlegroups.com... > > > > i connected the oscilloscope to the end auf the > > Agilent Cable, and got the stranger picture. > > Try longer cable and the picture will be even "stranger"... > > > /Mikhail
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