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
I agree, but then there is a limit to the amount of RAM that can go in a system,
and that is often greater than what the OS can use. I've got 2GB in my current
system: that frequently gets exceeded during synplicity's compile phase and Xilinx
PAR. As soon as paging starts, it slows to a crawl.
hamish@cloud.net.au wrote:
>
> Better to buy more RAM and avoid swapping?
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
--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: 43551Hi, I am trying to use a RAM of length 32k (32768) where each element of the RAM is 16 bits wide. I am required to have all the elements of the RAM initialized to zero before processing data elements and placing them in the RAM. This can be done by assigning initial values in VHDL and would work fine during the simulation but when synthesizing the synthesizer IGNORES the initial values. How can I initialize all the RAM elements to zero so that after synthesis I get the same result as after simulation???? Thanks in advance. NomanArticle: 43552
Ray Andraka" wrote > I agree, but then there is a limit to the amount of RAM that can go in a system, > and that is often greater than what the OS can use. I've got 2GB in my current > system: that frequently gets exceeded during synplicity's compile phase and Xilinx > PAR. As soon as paging starts, it slows to a crawl. Austin/Peter: what is the rule-of-thumb for the RAM per CLB for the Xilinx P&R tools? Synth and simulator vendors talk about numbers like 1K per gate/per signal/per ...Article: 43553
Rick Filipkiewicz wrote: > > Jim Thomas wrote: > > > rickman wrote: > > > > > > I am finding that. I just strikes me as odd that I can buy exactly one > > > memory module at a quarter or even an eighth of what the equivalent > > > SDRAM chips will cost me if I buy 1000 of them. But then electronic > > > purchasing has never been logical.. :) > > > > Hey Rick, > > > > Any reason you couldn't just plunk down a DIMM socket? > > I suppose form factor might be one. > > > > Or even an SODIMM skt. They are surface mount and lie horizontally so there's > room for some SMT parts underneath the SODIMM. The skts are a couple of $ > (much cheaper than they used to be) but the SODIMMs themselves are a little > more expensive per MB than DIMMs. > > We've faced this problem of getting individual SDRAMs ourselves but in the > other form of: DIMM lead time = tomorrow afternoon, SDRAM lead time = 6-8 > weeks for small(ish) quantities. It seems that unless you're buying > 100K/month the distis aren't interested ... and if you want something > non-standard like x32 configuration you can just forget it. These parts are going on the bottom of a PC104 card with a 0.1" height restriction. So no modules. The top of the board is covered with IO modules, so all of our chips have to go on the bottom. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 43554
Hi folks, Are there any still-available Xilinx devices which are pin compatible with a XC4010E-PC84-4? I'm thinking a spartan or something similar? Secondly, can anyone suggest an Australian source for these devices (low quantity <10) Thanks, JohnArticle: 43555
In article <3CED5561.82DA8B37@andraka.com>, Ray Andraka <ray@andraka.com> wrote: >I agree, but then there is a limit to the amount of RAM that can go >in a system, and that is often greater than what the OS can use. >I've got 2GB in my current system: that frequently gets exceeded >during synplicity's compile phase and Xilinx PAR. As soon as paging >starts, it slows to a crawl. Just remember that thrashing easily ends up being disk latency, not disk bandwidth bound. [1] As such, an expensive SCSI raid system may not be any better than a single, low latency SCSI disk. (Raid isn't about latency, it is about bandwidth and reliability). Seek time for a 10K RPM scsi is about 4.5 ms, while the 7200 RPM IDEs seem about 8ms. So a faster SCSI single disk is probably worth it, simply to be able to buy the lower latency drives. It might actually be woth considering getting a small (1-5 GB) solid state (DRAM style or Flash style) SCSI or IDE drive to use as your swap drive. Unfortunatly, Quantum seems to have stopped making them (how does 50 microsecond access time strike you?). BitMicro makes flash based ones that again claim 100-250 microsecond access time, claims to have 100 millisecond access time ones available now with good sizes, and good transfer, on ATA bus. [1] After all, if the cad tools could do blocking better, there would be MUCH less thrashing of the cache and main memory. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43556
"H.L" wrote: > Hello all, > I have read few weeks ago in xilinx site about the Chip Scope, seems like a > good solution for testing a FPGA. I am thinking to purchase it but first I > would like some comments about this tool from someone who have used it. Can > someone help me on this? > > Greetings, > Harris Very good tool and a steal @ $450 (well it saved my bacon a couple of months ago so I may be biased). Some restrictions and caveats: o The GUI is pretty clanky but just about useable. For example there's no way to reset the triggers(s) to all `X' after you've been using one of the trigger types that doesn't support `X' values. o The s/w resident on the PC sometimes fails to connect to the ILA core through the JTAG if there's some heavy compute process running in the background. The symptom is the s/w complaining of an illegal version - I've seen v0.0 and v15.0. o I've heard that MultiLinx USB is very flakey/fragile, use the Parallel-III/IV JTAG cable instead. In fact knowing this is what held me back from using Chipsope a while ago when V1.x didn't support Paralle-III. Things missing that you'd find in a real LA: o It requires a continuous sample clock of some description. i.e. you cannot async sample some number of events, hit stop before the buffer's full, and expect to see at least the events you captured. I got around this by creating a sort of background sample clock that ticked if no real one had arrived for a while. o There's no filter on pre-trigger events. In other words you can't say ``trig on event E while storing <filtered subset of states>''. Again its possible to get around this by designing some extra h/e to wrap around the ILA core but changing the pre-filter condition => rebuilding the FPGA. Other than that its an verygood-to-excellent tool and works as advertised. If Xilinx would fix up some of the points above it might even head into magic class.Article: 43557
Nicholas Weaver wrote:
> In article <3CED5561.82DA8B37@andraka.com>,
> Ray Andraka <ray@andraka.com> wrote:
>
> >I agree, but then there is a limit to the amount of RAM that can go
> >in a system, and that is often greater than what the OS can use.
> >I've got 2GB in my current system: that frequently gets exceeded
> >during synplicity's compile phase and Xilinx PAR. As soon as paging
> >starts, it slows to a crawl.
>
> Just remember that thrashing easily ends up being disk latency, not
> disk bandwidth bound. [1]
>
> As such, an expensive SCSI raid system may not be any better than a
> single, low latency SCSI disk. (Raid isn't about latency, it is about
> bandwidth and reliability).
Agreed, The raid is in the current system for reliability. I've suffered 3
or 4 disk failures over the years and the time spent recovering from backups
is well worth the extra cost of having a raid system.
>
>
> Seek time for a 10K RPM scsi is about 4.5 ms, while the 7200 RPM IDEs
> seem about 8ms. So a faster SCSI single disk is probably worth it,
> simply to be able to buy the lower latency drives.
>
> It might actually be woth considering getting a small (1-5 GB) solid
> state (DRAM style or Flash style) SCSI or IDE drive to use as your
> swap drive. Unfortunatly, Quantum seems to have stopped making them
> (how does 50 microsecond access time strike you?).
The flash style doesn't seem appropriate for a paging disk, as there are a
limited number of cycles. Are you aware of any DRAM drives?
>
>
> BitMicro makes flash based ones that again claim 100-250 microsecond
> access time, claims to have 100 millisecond access time ones
> available now with good sizes, and good transfer, on ATA bus.
>
> [1] After all, if the cad tools could do blocking better, there would
> be MUCH less thrashing of the cache and main memory.
>
> --
> Nicholas C. Weaver nweaver@cs.berkeley.edu
--
--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: 43558In article <3CEDC59C.43A0211C@andraka.com>, Ray Andraka <ray@andraka.com> wrote: >> It might actually be woth considering getting a small (1-5 GB) solid >> state (DRAM style or Flash style) SCSI or IDE drive to use as your >> swap drive. Unfortunatly, Quantum seems to have stopped making them >> (how does 50 microsecond access time strike you?). > >The flash style doesn't seem appropriate for a paging disk, as there are a >limited number of cycles. Are you aware of any DRAM drives? Quantum USED to make DRAM drives. Somebody might still, but the market is probably less since big DB apps and the like are on 64 bit architectures which can be stacked with DRAM. >> >> >> BitMicro makes flash based ones that again claim 100-250 microsecond >> access time, claims to have 100 millisecond access time ones >> available now with good sizes, and good transfer, on ATA bus. >> >> [1] After all, if the cad tools could do blocking better, there would >> be MUCH less thrashing of the cache and main memory. >> >> -- >> Nicholas C. Weaver nweaver@cs.berkeley.edu > >-- >--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 > > -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 43559
Hello I am looking for a JTAG ICE. I don't wanne spend much money on it. I want to be able to have a look on the schematics and to be able to compile the software on my own. I am looking for hardware to programm Xilinx and Altera FPGAs and Atmel AVRs with one Software and one hardware. If it would be possible to debug software over JTAG with this hardware it would be great. Dose anyone know any Project with this topic? regards FrankArticle: 43560
>Agreed, The raid is in the current system for reliability. I've suffered 3 >or 4 disk failures over the years and the time spent recovering from backups >is well worth the extra cost of having a raid system. Don't forget to back things up (somehow) anyway. RAID won't protect you from software/mushware/operator errors. >The flash style doesn't seem appropriate for a paging disk, as there are a >limited number of cycles. Are you aware of any DRAM drives? The ones I've seen have been SRAM with battery backup. They are used on database systems where they also expect serious reliability and are willing to pay for it. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 43561
In article <ackib0$138d$1@agate.berkeley.edu>, nweaver@CSUA.Berkeley.EDU
says...
>
>
>Quantum USED to make DRAM drives. Somebody might still, but the
>market is probably less since big DB apps and the like are on 64 bit
>architectures which can be stacked with DRAM.
>
you will find solid state disk manufacturers at
http://www.storagesearch.com/ssd.html
There are also ram based devices
one is the Nitro!Xe from curtis with the following data
* 3.5" half height Solid State Disk
* capacity:- 1G to 4.3G standard models,
other capacities upto 8.6G availabale on request
* Interface:- Ultra2SCSI
* Access Time:- 60 microseconds
* IO (transactions/sec) >10,000
* Interface Transfer Rate:- 80MB/sec
* Data Transfer Rate (sustained):- >68MB/sec
* Height:- 1.6" (40.6mm)
* Width:- 4.0" (101.6mm)
* Depth:- 5.75"(146m
There are no pricing information on the web site
with kind regards
Klaus Leiss
Article: 43562On Thu, 23 May 2002 15:29:22 GMT, John_H <johnhandwork@mail.com> wrote: >So, for high end audio using the heavily oversampled ADC, the conversion is apparantly Sigma Delta. Isn't this ADC >architecture extremely jitter tolerant? Sort of. An oversampling ADC will tend to reduce the effects of ultrasonic jitter, but can't do anything about jitter components within the passband (i.e. less than 20kHz). Consider sampling a sinusoidal signal A.sin(wt). The maximum dv/dt is A.w = A.2.pi.f Assume we are interested in frequencies up to 20kHz. In a 16 bit system, a time error of 243ps will result in an amplitude error of up to 1 LSB. In a 24 bit system, a time error of 949fs (yes, less than a picosecond) will result in an amplitude error of up to 1 LSB. Another way of looking at this is that 5ns p-p aperture jitter (as requested by the OP) will reduce the ADC accuracy to less than 13 bits when sampling a 20kHz signal. I'm not going to claim that it's always possible to hear such small errors though. (The spectral content of the jitter makes a big difference too.) Regards, Allan.Article: 43563
On Fri, 24 May 2002 11:15:52 GMT, allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote: >On Thu, 23 May 2002 15:29:22 GMT, John_H <johnhandwork@mail.com> >wrote: > >>So, for high end audio using the heavily oversampled ADC, the conversion is apparantly Sigma Delta. Isn't this ADC >>architecture extremely jitter tolerant? > >Sort of. An oversampling ADC will tend to reduce the effects of >ultrasonic jitter, but can't do anything about jitter components >within the passband (i.e. less than 20kHz). [good jitter explanation snipped] >Another way of looking at this is that 5ns p-p aperture jitter (as >requested by the OP) will reduce the ADC accuracy to less than 13 bits >when sampling a 20kHz signal. It's not even that good. While oversampling may increase jitter tolerance, the delta-sigma architecture is more than usually sensitive to jitter. Consider that any signal is represented by a pattern of full-scale "0" and "1" signals, it is clear that any error in the duration of those signals translates to an error in their area and therefore in the amplitude of the corresponding analog signal. This is independent of the frequency of the signal, unlike the ladder-DAC based (SA) ADCs, where on a DC input signal, the error from jitter is obviously zero!). If there is any correlation between the full amplitude high-speed train of "0/1" signals and jitter in the clock signal, the errors may not take the form of noise, but distortion or even audible whistling tones. - BrianArticle: 43564
"B=F8rge Strand" wrote: > I will need some really small FIFOs for my next project. The word lengt= h > will be 24 bits, but the depth of the FIFO is not requirred to be more = than > two to sixteen. > > Could dedicated parts of the Spartan be used for such small FIFOs? I pl= an to > program the thing in VHDL. > > Regards, > B=F8rge Let's calculate: your FIFO will use a DP RAM of 24 x 16 max. a DP RAM is composed of 16x1 RAM16X1D.v primitives. Thus: NUM_OF_DPRAMS_OF_BORGE =3D (24 x 16) / (16 x 1) =3D 24 CLBs. This gives you 24 CLBs laid horizontally on the chip. This DPRAM can be generated with Logiblox but your chip must be greater than or equal to Xilinx Spartan/XL XCS30XL (24x24 CLB matrix). Otherwise, you have to divide your words into smaller words. This is not bad, but uses twice routing resources the one above has. More routing resources cause longer PAR times. I'm using a 32x8 FIFO on a Xilinx Spartan-XL XCS40XL-4-PQ208C. UtkuArticle: 43565
Hi, I am after an SDRAM controller in VHDL for Virtex-II. Does anyone know where I could get one from ? Thanks. Philippe.Article: 43566
Hi According to Xilinx datasheets , "by default block selectRAM memory is initialized with all zeros during the device configuration sequence" reference : book UG002(V1.0) 6,december 2000 page 192 then you dont need to do any think it is done ! sometime built in functions help us and then you could enlarge your week end cheers -- Use our news server 'news.foorum.com' from anywhere. More details at: http://nnrpinfo.go.foorum.com/Article: 43567
I am sorry , I was missing simulation , initialisation must be provided through generic statement as the content is the same only addresses must be different this is not too much difficult -- Use our news server 'news.foorum.com' from anywhere. More details at: http://nnrpinfo.go.foorum.com/Article: 43568
"noman" <noman_news@hotmail.com> wrote in message > Hi, > I am trying to use a RAM of length 32k (32768) where each element of > the RAM is 16 bits wide. I am required to have all the elements of the > RAM initialized to zero before processing data elements and placing > them in the RAM. > This can be done by assigning initial values in VHDL and would work > fine during the simulation but when synthesizing the synthesizer > IGNORES the initial values. > How can I initialize all the RAM elements to zero so that after > synthesis I get the same result as after simulation???? > Thanks in advance. How do you instantiate this RAM? Is it just an array written in VHDL, or is is a component created by a tool such as Coregenerator from Xilinx's SW? If you use a component made by a tool such as that, it is most likely that at power on the contents of the RAM will be set to '0's. The same tool can also provide a SINIT pin to initialize by yourself the contents to a predefined value, or even better it can load the initial values (diffirent for each half_word) from a file which contains them in a special format. This loading of values is kept after synthesis, PAR, and on configuration (it is in the bitstream). In case it is an array written in VHDL I can't help you how to keep the initial values in the RAM after synthesis, but I can tell you to try and use one of those tools (Coregenerator for Xilinx, Megafunction wizard for Altera's MaxPlus II ....), and you will have the result you want, and even faster synthesis. gianziArticle: 43569
Philippe, try this free HDL source of sdram controller: http://www.latticesemi.com/account/_download.cfm?AMID=3866 Since I want to includ it on a spartanII in next months, could you give me a feedback, if you use it. Laurent Gauch Philippe Robert wrote: > Hi, > > I am after an SDRAM controller in VHDL for Virtex-II. > Does anyone know where I could get one from ? > > Thanks. > Philippe. > > >Article: 43570
Hi everyone! I try to find a standalone board for image processing using a system-on-a-programmable-chip (SOPC). The application I have in mind is not a high-end one, so let's think of something like 1000MIPS. There are a lot of coprocessing boards connected to a host-system via PCI or other high-speed interfaces. They are nice and powerful, but no help for a standalone system. There are some standalone boards, for example from Ateme or LYRtech http://www.ateme.com/gb/products/evaluation-boards.html http://www.signal-lsp.com/index.html My problem with these boards is, that although they follow the concept of integrating FPGA, DSP and MCU, giving you the possibility to map every task to the best-suited device, they don't follow the concept to the end. They still are a heterogenous multiprocessor/device-system. Every FPGA/DSP/MCU needs area, voltage, interfaces and a standalone development environment. So from the point of view of a board designer as well as of a software developer they have some essential disadvantages. Disadvantages which could easily be removed by using a SOPC. Especially the area/interface/voltage topic would immediately disappear. CoDesign will need some more time to become reality, but changing interfaces between FPGA and DSP more easily would be a direct benefit. Does anyone of you know of a standalone board for image processing using a SOPC? >From what I know there are a few candidates: - Xilinx Virtex-II Pro - Altera Apex with embedded ARM - Transcend A7 - Atmel FPSLIC Both the A7 and the Atmel FPSLIC adress more the controller market than the signal-processing market (max. 60MHz). Leaves us wit the Virtex and the Altera. Has anyone experience with image processing on these chips (or with moving from a discrete FPGA/DSP/MCU-Design to one of them)? Even if there is not yet a board available - the chips are. And with them an interesting design question. As the coupling between FPGA and other units is as thight as never before - can we come up with better (image processing) algorithms by distributing smaller tasks more efficently between different units? Any ideas, experiences or papers around? \ManfredArticle: 43571
Which video interface do you want, 1394, s-video or other ? Manfred Muecke wrote: > Hi everyone! > > I try to find a standalone board for image processing using a > system-on-a-programmable-chip (SOPC). The application I have in mind > is not a high-end one, so let's think of something like 1000MIPS. > > There are a lot of coprocessing boards connected to a host-system via > PCI or other high-speed interfaces. They are nice and powerful, but no > help for a standalone system. > > There are some standalone boards, for example from Ateme or LYRtech > http://www.ateme.com/gb/products/evaluation-boards.html > http://www.signal-lsp.com/index.html > > My problem with these boards is, that although they follow the concept > of integrating FPGA, DSP and MCU, giving you the possibility to map > every task to the best-suited device, they don't follow the concept to > the end. They still are a heterogenous multiprocessor/device-system. > Every FPGA/DSP/MCU needs area, voltage, interfaces and a standalone > development environment. > So from the point of view of a board designer as well as of a software > developer they have some essential disadvantages. Disadvantages which > could easily be removed by using a SOPC. Especially the > area/interface/voltage topic would immediately disappear. CoDesign > will need some more time to become reality, but changing interfaces > between FPGA and DSP more easily would be a direct benefit. > > Does anyone of you know of a standalone board for image processing > using a SOPC? > > From what I know there are a few candidates: > - Xilinx Virtex-II Pro > - Altera Apex with embedded ARM > - Transcend A7 > - Atmel FPSLIC > > Both the A7 and the Atmel FPSLIC adress more the controller market > than the signal-processing market (max. 60MHz). > Leaves us wit the Virtex and the Altera. > Has anyone experience with image processing on these chips (or with > moving from a discrete FPGA/DSP/MCU-Design to one of them)? > > Even if there is not yet a board available - the chips are. And with > them an interesting design question. As the coupling between FPGA and > other units is as thight as never before - can we come up with better > (image processing) algorithms by distributing smaller tasks more > efficently between different units? > Any ideas, experiences or papers around? > > > \Manfred > >Article: 43572
On Fri, 24 May 2002 16:33:14 +0200, Laurent Gauch <laurent.gauch@amontec.com> wrote: >Which video interface do you want, 1394, s-video or other ? CameraLink would be perfect.Article: 43573
Depends on the number of bits you use from the DDS. If you use the DDS to create
a sinewave, convert it to analog, filter it then use a comparator it can be better
than a PLL. If you just take the MSB to create a square wave, then your jitter is
up to a cycle of your master clock.
Marty wrote:
> Jitter from a DDS is lower than a PLL!
>
> Marty
>
--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: 43574
You can use the coregenerator, in which case your initialization vectors get
read from a .coe file. I personally prefer to instantiate the Block RAM
primitives (RAMB4_*) and put the appropriate initialization on them. While it
is a bit more work, it does allow me to control the implementation directly and
allows me to put placement and initialization right in the code, and it
minimizes the number of steps that have to be done to get to a bitstream.
gianzi wrote:
> "noman" <noman_news@hotmail.com> wrote in message
> > Hi,
> > I am trying to use a RAM of length 32k (32768) where each element of
> > the RAM is 16 bits wide. I am required to have all the elements of the
> > RAM initialized to zero before processing data elements and placing
> > them in the RAM.
> > This can be done by assigning initial values in VHDL and would work
> > fine during the simulation but when synthesizing the synthesizer
> > IGNORES the initial values.
> > How can I initialize all the RAM elements to zero so that after
> > synthesis I get the same result as after simulation????
> > Thanks in advance.
>
> How do you instantiate this RAM? Is it just an array written in VHDL, or is
> is a component created by a tool such as Coregenerator from Xilinx's SW? If
> you use a component made by a tool such as that, it is most likely that at
> power on the contents of the RAM will be set to '0's. The same tool can also
> provide a SINIT pin to initialize by yourself the contents to a predefined
> value, or even better it can load the initial values (diffirent for each
> half_word) from a file which contains them in a special format. This loading
> of values is kept after synthesis, PAR, and on configuration (it is in the
> bitstream).
> In case it is an array written in VHDL I can't help you how to keep the
> initial values in the RAM after synthesis, but I can tell you to try and use
> one of those tools (Coregenerator for Xilinx, Megafunction wizard for
> Altera's MaxPlus II ....), and you will have the result you want, and even
> faster synthesis.
>
> gianzi
--
--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