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
"Pablo Bleyer" <pbleyerN@SPAMembedded.cl> wrote in message news:<4010abf0$1_1@nova.entelchile.net>... > "Austin Lesea" <austin@xilinx.com> escribió en el mensaje > news:bup6dl$8dl2@cliff.xsj.xilinx.com... > > The reason for the failure of other parts could be that they are NOT > > FPGAs. FPGAs are manufactured in huge volumes, and are all tested in > > the qualification for latch up under irradiation. Many SRAM,s and other > > products do not have the volume to afford such testing, and in fact > > recent shrinks of common parts are known to latch up with a single > > event, and destroy themselves. > > Interesting. Under what conditions and what kind of tests are Xilinx > rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed > information about rad parameters... > > Regards. Pablo - they undergo the standard tests....TID per spec 1019.5, SEL and SEU (Heavy Ion and Proton - Static and Dynamic). All of the specifications (from krads to Cross Sections to energies, etc) are listed in the datasheet. For more detailed info test results are published via the Xilinx Single Event Effects Consoritum, which includes major Aerospace companies, at the typical industry conferences - NSREC, RADECS and MAPLD mainly. Thanks Jason Xilinx Mil/Aero GroupArticle: 65351
Use package numeric_std from IEEE and the type unsigned.
library ieee ;
use ieee.numeric_std.all ;
. . .
SIGNAL nano_bin : unsigned(31 downto 0);
IF....THEN
nano_bin <= nano_bin +1 ;
END IF;
Currently there is no package that directly supports
the type std_ulogic_vector. There is a package that
supports std_logic_vector (called std_logic_unsigned).
Some like it, some don't. The argument is that whenever
possible, use the type unsigned as it contains
documentation in the type. My thought is that for
somethings (such as testbenches) it is unpractical to not
use std_logic_unsigned (at least until we have something
better from IEEE).
The use of std_logic_unsigned is clear as long as you
never use the package std_logic_signed.
Regards,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trent R. wrote:
> Hello,
>
> I started now with VHDL....so maybe it´s a stupid Question....
> but is there an easy way to increment a bitvector?
> For example something like this:
>
> SIGNAL nano_bin : std_ulogic_vector(31 downto 0);
> IF....THEN
> nano_bin <= nano_bin +1 ;
> END IF;
>
> THX Trent
>
Article: 65352Hi, Last time I have posted a question about guard bit in CORDIC algorithm. I have got some good answers from this goupe. When I programe in C to do a simulation, I still don't understand how I do with the guard bits. From one of the papers talking about implementation of CORDIC, it says the input is 12 bits, internal data paths are 16 plus extra 6 guard bits. At the input stage adds 6 all-zero guard bit extension. At the output stage it erases guard bits. And, it also divides two inputs number by 2 at first to prevent overflow. The internal data are represented as signed numbers. My question is: 1. What are the differences between the internal 22 (16+6) bits calculation and 16 bits data plus 6 guard bits extension? Especially I want to get an example to make this question clear. 2. If the 6 extra guard bits are MSB, to erase them will not destroy data? There are 9 stages of CORDIC cells in my application. In my simulation programe I find the high bit in the last stage is at bit 5 (in the guard bits range when I simply use 22 internal bits with there are 6 bits leave off at the first input data stage). 3. Which book talks about the guard bit? Could you recommend me some? Thanks in advance.Article: 65353
Hello, these below are my warning and error-messages: ********************************************** ---<snip!> WARNING:Place:119 - Unable to find location. TBUF component I41_1 not placed. TBUF "I41_1". ERROR:Place:120 - There were not enough sites to place all selected components Phase 6.9 (Checksum:39386fa) REAL time: 30 secs Total REAL time to Placer completion: 30 secs Total CPU time to Placer completion: 29 secs ---<snap!> Best regards, Thomas.Article: 65354
Sorry for some inaccury description. Following is the corrections. a. "At every input stage adds 6 all-zero guard bit extension first, then at its output it erases all the guard bits." b. "There are 6 stages of CORDIC cells cascaded in my application." As my understanding of CORDIC, its vector/rotation is from the MSB. So, there is no overflow like multiply. I just need consider the CORDIC rotation gain(1.647)? In this considering, besides the input data divide 2, why it needs extra 6 guard bits? BTW, in the reply to my last post, What Ray said about MAC is right. I found my previous understanding was wrong. In that paper, multiply-accumulate or divide-accumulate are not performed directly. Any suggestion is highly appreciated.Article: 65356
Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote: : Hi, : just to simplify the previous reccomandations, I suggest you : instantiate the primitive IOBUF at the xilinx pins. Instantiate Entities are normally manufacturer dependant. Normal verilog code has better chances to be manufacturer indpendant. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 65357
"Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message news:bv1hed$8kd$1@mawar.singnet.com.sg... > Yeah, yours is the better approach...However I am converting an ASIC design > into FPGA... > there are a few megabytes of source codes...sigh...that is the problem... If you are familiar with any of the scripting languages you should be able to write something which looks for the lower clocks, changes them to the 36Mhz clock and inserts a pair of lines with the relevant clock enable. It might be a good idea to get it to display what it's done and get you to confirm it, or add comments above every changed line with an easily found search string so you can quickly check what it's done. Give it a _thorough_ visial inspection and make sure it's _well_ simulated to check you haven't messed up. Nial ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone based 'Easy PCI' proto board www.nialstewartdevelopments.co.ukArticle: 65359
Hi, Austin Lesea <austin@xilinx.com> wrote: > radioactive after spending so much time in the beam. Oh, and none of > them ever suffer any damage -- they power on and meet all specs after > hundred and hundreds of rads. What about 100 krad? I'm just curios. In our company we have problems to use devices without qualification for at least 30krad. > > Analysis > > This is a standard procedure, and we are the ONLY company that actually > KNOWS how our parts are affected by cosmic neutron showers, alpha > particles, etc in REAL applications from sea level to 60,000 feet (I > can't talk about the programs we have for mil/aerospace until you sign > an NDA). This seems a bit too overconfident. Actually I didn't know your effort, but I know the effort Actel is doing for its devices. And they prove very sufficient analyses beside the analyses spacecompanies are doing with Actel Fpgas for themself. > Competitors > > Other companies out there are in a state of "blissful ignorance" and > when (not if) they start to have customers complain of failures, they > will be saying, "gee, we don't see anything (because we can't), must be > something you are doing." Why can't they see anything when a customer > complains? I'm shure you wouldn't tell names, but did you _ever_ tried the hotline of another fpga vendor? Tell us a bit about your experience. I'm very satisfied the way Actel is reacting on complaints. bye ThomasArticle: 65361
It sounds like they are calling the added LSBs guard bits. CORDIC has a
gain of 1.647. Assuming the input is left justified, it needs to be right
shifted (divided by 2) to accommodate the gain. I am sure what they are
calling guard bits are extra bits tacked onto the LSBs to absorb the
rounding errors that happen inside the CORDIC as a consequence of the
right shifts (I am also accustomed to 'guard bits' referring to extra sign
bits, not added LSBs).
SO what they are doing is adding extra LSBs to absorb the
truncation/rounding errors that inevitably happen because of the right
shifted cross terms in the CORDIC algorithm, however for 6 iterations, 6
guard bits is excessive. If you look at the maximum error introduced, it
is +/-0.5 at each iteration if the iteration sum/difference is rounded.
Summing that up over the iterations you get a bounded error that is
related to log2(iterations). This can be dealt with by carrying enough
extra precision through the computation to permit you to truncate off the
error at the output.
Jeff wrote:
> Sorry for some inaccury description. Following is the corrections.
>
> a. "At every input stage adds 6 all-zero guard bit extension first,
> then at its
> output it erases all the guard bits."
>
> b. "There are 6 stages of CORDIC cells cascaded in my application."
>
> As my understanding of CORDIC, its vector/rotation is from the MSB.
> So, there is no overflow like multiply. I just need consider the
> CORDIC rotation gain(1.647)? In this considering, besides the input
> data divide 2, why it needs extra 6 guard bits?
>
> BTW, in the reply to my last post, What Ray said about MAC is right. I
> found my previous understanding was wrong. In that paper,
> multiply-accumulate or divide-accumulate are not performed directly.
>
> Any suggestion is highly appreciated.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65363Jim, See below, Austin >> The caveat to your statement is then, configuration bits can be read back >> while the circuit is operating except for SRL16's CLB_RAM and in >> virtex, block RAM as reading columns with those elements while they are >> being clocked can corrupt the state of the user circuit. > > > Sounds like that one, if true, needs a fix.... > ( and an alert -> someone might think they are increasing reliability > by reading back all nodes, and ignoring the 'might change' ones ) - > >>> Austin Lesea wrote: >>> >>>> Jim, >>>> > <snip> > >>>With Virtex II, II Pro, Spartan 3 we can readback all memory excepting > >>>LUTRAM/SRL16 while it is operating and not disturb the static values, > >>>nor disturb the customer design. In the next generation we have also > >>>fixed that, and allow for readback while LUTRAM/SRL16 are operating. > > So this fixed, 'next generation' is not Spartan 3, but whatever is > comming after that ? Yes. > >>>> Now, of course, using readback on LUTRAM/SRL16 and BRAM doesn't help >>>> you, as you do not know what it is supposed to be (as it just might be >>>> changing). > > > If that BRAM was storing constants/lookup info (read only), then > I can see a need to verify the table is actually still correct ? If BRAM or LUTRAM is storing constants, then you may include it in the readback verify. > > -jg >Article: 65364
Thomas, You need to contact one of our FAEs! See below, Austin Thomas Stanka wrote: > Hi, > > Austin Lesea <austin@xilinx.com> wrote: > >>radioactive after spending so much time in the beam. Oh, and none of >>them ever suffer any damage -- they power on and meet all specs after >>hundred and hundreds of rads. > > > What about 100 krad? I'm just curios. In our company we have problems > to use devices without qualification for at least 30krad. Better than 100Krad. Ask for the FAE for radiation test results. > > >>>Analysis >> >>This is a standard procedure, and we are the ONLY company that actually >>KNOWS how our parts are affected by cosmic neutron showers, alpha >>particles, etc in REAL applications from sea level to 60,000 feet (I >>can't talk about the programs we have for mil/aerospace until you sign >>an NDA). > > > This seems a bit too overconfident. > Actually I didn't know your effort, but I know the effort Actel is > doing for its devices. And they prove very sufficient analyses beside > the analyses spacecompanies are doing with Actel Fpgas for themself. No, it is not. Some competitors are spreading information that is patently false, and misleading (there, I said it). They compare us with commercial SRAM, which is false and misleading, as we are not commercial SRAM, have nothing to do with commercial SRAM, and do not use commercial SRAM technology or cells. We use our own design cmos configuration latches, which are shown to be 20X to 100X more robust for the same technology. As for their own tests, they only talk about their fuses, and not their logic, or flip flops. How fair is that? With a part that is one tenth the size of ours. Tens times smaller, is also ten times fewer upsets. How to lie with numbers. > > >>Competitors >> >>Other companies out there are in a state of "blissful ignorance" and >>when (not if) they start to have customers complain of failures, they >>will be saying, "gee, we don't see anything (because we can't), must be >>something you are doing." Why can't they see anything when a customer >>complains? > > > I'm shure you wouldn't tell names, but did you _ever_ tried the > hotline of another fpga vendor? Tell us a bit about your experience. > I'm very satisfied the way Actel is reacting on complaints. > OK, let us try it: Competitors? What is your cross section for logic? Cross section for flip flops? Cross section for config bits, RAM? Go ahead, let us all know your data. Ours is very simple, you can not upset our logic or flip flops as they are so heavily loaded. And the rest of our data is in the power point MAPLD presentation that RK has so kindly provided the link to.Article: 65365
Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote in message news:<Pine.LNX.4.44.0401260218490.15967-100000@lxplus090.cern.ch>... > Hi, > > just to simplify the previous reccomandations, I suggest you > instantiate the primitive IOBUF at the xilinx pins. 1) The original poster wanted to use internal tristates. 2) All of the current synthesis tools infer the right sort of buffers, so there's no need to hand-instantiate them. --aArticle: 65366
t.bartzick@gmx.net (Thomas Bartzick) wrote in message news:<cdd36e13.0401251931.2f3cb1c7@posting.google.com>... > Hello everybody! > > I have a problem with placing my tbuf-elements. > Modules using bus operations are coupled to top-level switching them > to a bidirectional bus. See, like this: > > ---<snip!> > > entity my_struct is port ( > ... > BD : inout std_logic_vector(15 downto 0); > ...); > end my_struct; > > architecture Behavioral of my_struct is > ... > signal de, di : std_logic_vector(15 downto 0); > ... > begin > ... > my_external_connector : process (de, BD, ext_read) > begin > if (ext_read = '1') then > BD <= de; > de <= "ZZZ...Z"; > else > BD <= "ZZZ...Z"; > de <= BD; > end if; > end process; > ... > mod_databus_write_sync : SYNC_2xFF port map ( > I => de, > O => di); > ... > my_module : SOME_MODULE port map ( > DIN => di, > DOUT => internal_output, > CS => ..., > ...); > > my_toplevel_bus_read_process: process (internal_output, > read_condition) > begin > if (read_condition = '1') then > de <= internal_output; > else > de <= "ZZZ...Z"; > end if; > end process; > > end Behavioral; > > ---<snap!> > Additional Note: > **************** > There are about 3 upto 5 internal modules which make use of this > structure. > So we get a maximum of 5x16 = 80 tristate buffer lines, probably some > more. > **************** > > Synthezising, Translation and Mapping is always fine, but since the > implementation process comes to PAR, the placer stops after a couple > of warnings and at least one error like this: > > ---<snip!> > > ... WARNING! Unable to place TBUF of module <#1>! > ... > ... WARNING! Unable to place TBUF of module <#n>! > ... > ... ERROR! Placing was not complete! > ... > > ---<snap!> > > I have read on XILINX support pages, that this problem can be worked > around by using AREA_GROUP constraints. If I have understood this in > the right way, the constraints will show the placer how I would like > to layout the tristate buffers. But all I can choose in ISE for > SPARTANII are Row and Column-statements, for which I have no idea how > to use them in a proper way. > > I am using XILINX Webpack ISE 6.1 with a SPARTANII (-5) architecture. > Help or at least some hints would be very appreciated! > > Bye, > Thomas. Hello Thomas, When considering TBUF placement issues, it's necessary to understand the placement limitations of the TBUF sets as a whole. How large a set can the device handle? How many total sets of a particular size can it handle? These are limitations that come into play long before the total number of TBUF sites available becomes a factor. Spartan-II devices can not handle multi-row TBUF placement within a set (Virtex-II can) so the largest possible TBUF set is equal to the number of columns in the device. The TBUF long lines can be segmented in groups of four TBUFs, so the number of sites consumed by each set should be rounded up to a factor of four, then the total number of possible sets calculated. For example, if the set size is greater than half the number of TBUFs on a long line, then the number of possible sets is equal to two times the number of rows (two TBUFs per CLB), even though TBUF site utilization may only be slightly greater than 50%. If you're unsure of the size of your TBUF sets and the number of sets, see the following Answer record for a perl script that can be used to count them: http://support.xilinx.com/techdocs/2872.htm Regarding constraining TBUF placement, it's often enough to LOC a single TBUF from each set to a site on a particular longline. The rest of the TBUFs in the set are then implicitly LOC'd to the same long line. One possibility is to allow Map to transform some of the TBUFs to slice logic by using the -tx switch. Regards, BretArticle: 65367
Dear Colleague, Please find below information on the Poster Sessions (Regular and Group) of the 2004 NASA/DoD Conference on Evolvable Hardware. Please visit the Conference web-site at: http://ehw.jpl.nasa.gov/events/nasaeh04 for more information about EH-2004. With best regards Ricardo S. Zebulum David Gwaltney Gregory Hornby Didier Keumeulen Jason Lohn Adrian Stoica ------------------------------------------------- SUBMISSION OF SHORT PAPERS (REGULAR POSTERS) Prospective authors (who did not submit an abstract in the full-paper deadline) are invited to submit the electronic version of their short paper (ie PS, PDF, MSWord) by email to eh-2004@cism.jpl.nasa.gov . The paper is limited to 4 pages and should be submitted in single-spaced, 10 point type on a 8.5" X 11" or equivalent paper with 1" margins on all sides. Each submission should contain the following items: (1) title of paper, (2) author name(s), (3) first author physical address, (4) first author e-mail address, (5) first author phone number, (6) a maximum 200 words abstract (7) the text of the paper, and (8) references. Short-papers should be submitted by January, 31st. Accepted short papers will be published in the conference proceedings and presented as REGULAR POSTERS. SUBMISSION OF GROUP POSTERS In addition to the oral and regular poster presentations, the 2004 NASA/DoD Conference on Evolvable Hardware will also include a Group Poster session, similarly to the one of the previous years. Each research group is invited to prepare a poster describing the research performed by their group. If you are interested, please e-mail to eh-2004@cism.jpl.nasa.gov a one-page abstract describing your group poster by March, 5th, 2004, so that your group poster can be referenced in the Conference Proceedings. The abstract submission should contain the following items: (1) title of poster, (2) Researchers' name(s), (3) Research Group web address, (4) Research Group physical address, (5) a maximum 200 words describing poster contentsArticle: 65368
Hi!
I would like to build isp cable for lattice CPLD (ispLSI 1016), but I
don't know how.
Can you help me?
Best Regards,
Mario
Article: 65369Thanks, Ray. Your reply is always right and accurate. I owe you a lot! Sorry again for my incomplete description. There are 22 iterations in our CORDIC cells. So, the 6 LSB guard bits are reasonable. Have a good day!Article: 65370
jim granville <no.spam@designtools.co.nz> wrote...
> We need some more info on peak/average Read and Change stream rates,
> and likely 'change depth'.
data is 8 bits, fifo is 512 entries, reading from the fifo happens
once every 10 clock cycles, a change happens approx. every 10th time,
and the average change depth is 2.
> You can either change on read, and iterate until the change stack
> stops changes, which will be HW frugal, but will have a finite settling
> time. ( similar to a linked-list in SW )
Yes, this is what I am currently doing. For situations where change
depth is 2 or less, this works fine. For change depths of 3 or more, I
have to buffer the incoming data.
> Or, you can change all in-situ, but that is also likely to have a
> finite settling time, as the delta-list will have to arrive
> sequentially, but maybe at a much lower average rate.
> This will read faster, but consume much more HW.
> So it's like any parallel/serial trade off: HW vs bandwidth.
I'm hoping for some clever solution that uses this method -
unfortunately the best I could come up with involved too much hardware
- leaving no room for anything else. If there was a way to implement
this smarter, I'm interested!
> If the change-list stream rate is slow, you could do a combination of
> table correct {fast, but one-deep), and interleaved scan change,
> (slower, but will recurse).
> Thus the FIFO becomes a bit like video memory, where one task
> scans/changes and the other reads.
> It would need "pause" ability, for when/if too many changes arrive
> for the change paths to settle.
I've considered this approach, and if you can figure out a way to make
it work, that would be great. The problem I had was that many values
could change to the same value, eliminating the possibility of using
another linked-list (reverse direction from the initial solution) to
iterate through the changes in the lookup-table.
Article: 65371
Austin,
Are you sure this is true for BRAM? As I understood it, the readback logic for
the BRAM in virtex is shared with part of the operational logic and you will
corrupt a user read if readback is performed on a BRAM while a user read is also
happening, ie, you need to either shut down the clock or have the user circuit
ignore read data. I'm hoping this was not conveyed to me properly, but my
source was rather emphatic (source was involved with the radiation testing at
LANL).
Austin Lesea wrote:
>
> >
> > If that BRAM was storing constants/lookup info (read only), then
> > I can see a need to verify the table is actually still correct ?
>
> If BRAM or LUTRAM is storing constants, then you may include it in the
> readback verify.
>
> >
> > -jg
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65372
The tools are horrible at placing the internal tristates. Putting LOCs on them within the code is one *very* good reason to
instantiate them.
Andy Peters wrote:
> Tullio Grassi <tgrassi@cut_here.mail.cern.ch> wrote in message news:<Pine.LNX.4.44.0401260218490.15967-100000@lxplus090.cern.ch>...
> > Hi,
> >
> > just to simplify the previous reccomandations, I suggest you
> > instantiate the primitive IOBUF at the xilinx pins.
>
> 1) The original poster wanted to use internal tristates.
>
> 2) All of the current synthesis tools infer the right sort of buffers,
> so there's no need to hand-instantiate them.
>
> --a
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65373
Where should I send the invoice? ;-)
Glad to have been able to help.
Jeff wrote:
> Thanks, Ray.
> Your reply is always right and accurate. I owe you a lot!
> Sorry again for my incomplete description. There are 22 iterations in
> our CORDIC cells. So, the 6 LSB guard bits are reasonable.
>
> Have a good day!
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 65374Ray, As we all know, I am certainly not perfect, so I could be wrong here. I am checking. I was pretty confident that changing the address while trying to read hte LUTs affected the contents as they have to share circuitry, but the BRAM is a two port plus the config access, or really a three port memory as the addressing of the config is independent. I will post as soon as I know for sure.... Austin Ray Andraka wrote: > Austin, > > Are you sure this is true for BRAM? As I understood it, the readback logic for > the BRAM in virtex is shared with part of the operational logic and you will > corrupt a user read if readback is performed on a BRAM while a user read is also > happening, ie, you need to either shut down the clock or have the user circuit > ignore read data. I'm hoping this was not conveyed to me properly, but my > source was rather emphatic (source was involved with the radiation testing at > LANL). > > Austin Lesea wrote: > > >>>If that BRAM was storing constants/lookup info (read only), then >>>I can see a need to verify the table is actually still correct ? >> >>If BRAM or LUTRAM is storing constants, then you may include it in the >>readback verify. >> >> >>>-jg >>> > > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >
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