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
Hi Antti, thank you for your answer. I forgot to ask what this corresponding command is. ;o) My search in the EC/ECP handbook was unsuccessful. Rgds Andr=E9 >Antti Lukats wrote=20 >yes they doArticle: 93326
Art! Thanks so much for the pointers. I've gone through the literature (the book I have), but it's all about syntax and nothing about practical applicaiton. A few quesitons however : - why do you need a clk? Why does anything need a clock? If I can synthesize a device which is a set of nested gates (i.e. an 'AND' gate) which perform logic, where does the clock come in? - why out <= (en) ? out + 1 : out ; ? Why not "out <= (en) ? 1 : out" Though I'm more interested in "out[index] <= (en) ? in : out[index]" -- can I do that? i.e the counter determines the index, and the enable alows me to latch the value. - is it possible to have the input (in) above be tri-state, such that I can latch 0, 1, Z? (i think Z is high-impedence) Thanks again - I'll start playing with some of the suggested changes and see how far I can get. RezaArticle: 93327
<ALuPin@web.de> schrieb im Newsbeitrag news:1135064646.387219.84000@o13g2000cwo.googlegroups.com... Hi Antti, thank you for your answer. I forgot to ask what this corresponding command is. ;o) My search in the EC/ECP handbook was unsuccessful. Rgds André >Antti Lukats wrote >yes they do there is nothing special or nothing to know, just use diff prim and connect one iopad the second will be autoassigned - thats it nothing special to worry about AnttiArticle: 93328
I have an ISE project where I have a Microblaze submodule, containing 2 CPUs. When I try to make timing constrains a warning popps up: <<You have more than one instance of the EDK module MyBlaze. This will not implement correctly. >> This is not true. I have only one instance of my dual processorcore. Is it safe to ignore this warning? What can I do to prevent this warning? RaymondArticle: 93329
Hello Thomas, > Have anybody seen the error: "Invalid Profile Start & End Memory > Address" before? I had also a problem with this error message wen i tried to generate an ACE file with the genace.tcl script and also in the XMD. In my opinion the problem is in the Cygwin enviroment which is used for the xbash. I get the error when I run the command "xmd -tcl genace.tcl ..." from the xbash. If I run the same command with the same tools from the Windows command prompt it runs ok. The last comment from the Xilinx webcase support was to reinstall the ISE and EDK. But I am afraid to do it. With the workaround everything works good. Perhaps this is not the solution for you but it might can help. > And what does it mean? ??? I think it mean nothing. Perhaps in the software (Cygwin/Xilinx, I don't know) is a NULL pointer assignment or buffer overflow which causes an random error. See you later FlorianArticle: 93330
Hi Thanks for your reply. I am using CABLE parallel III . Actually two device is in the chain.Both are not detected.So checking the First device. I have set the control bit 101(m2,m1,m0).I have tired 1 1 1 combination also .But no use. I have already used 1.2K but Nochange .So i came down to 220 ohm resisitor.I will try to use 2k I have checked TCK and TMS .TDI levels .It is okay.But TDO is logic high always.Now the cable speed is 200khz only Expecting your reply Thanks in advance >Hello, > > What cable are you using for programming? If it is a cable IV, Is it >powered (LED is green not yellow)? Is this the only device in the chain? >The cable IV needs power on pin 2 of the cable to match the IO supply of the >device to be programmed. >Check your mode control bits. I have programmed the V2P40 using both JTAG >and serial with the mode bits set for serial slave. >I would try a larger resistor and see if your symptoms change. (The Virtex >Pro spec states >200 ohms.) Try a 1K or 2K? > >I am not familiar with the CRO acronym. Did you look at the timing and >levels with a scope? We had trouble with the TDO->TDI on one part in the >chain and the signals were not passing at 5MHz. Dropping the cable speed >helped but fixing the path (missing a pullup) got us running reliably. > >Regards, > Bart > >On Mon, 19 Dec 2005 10:52:37 -0600, rmanand wrote: > >> >> >>Hi friends >> >>The Virtex II pro (XC2VP100) device is not Configuring through Impact7.1e >> >> >>When i try to check with CRO what is happeing at the BOUNDARY SCAN SIGNALS >>TDO ,TDI,TCK ,TMS >> >>I found TDI,TMS,TDI signals are okay .THE TDO is always stuck at >>one(pulled up by 220 ohm resisitor preferred by xilinix). >> >>The prog Pin is pulled up to 3.3V through 4.7k.The Init pin is pulled up >>to 3.3v through 4.7k.These all are xilinx reccomendation. >> >>I could not understand what will be reason for the TDO is always high at >>one and how to solve the problem. >> >> >>The impact is always throughing Impact -583 error. >>Expeting your valuabe replies >> >>Thanks in advance >> >> > > > >Article: 93331
Yes you are right, there is nothing special to worry about. The Place and Route Report shows that the second IO is reserved whereas the Post-Place-and-Route Floorplanner does not show any connection between the two IOs. But it should be assumed that the connection does exist ... Rgds Andr=E9Article: 93332
Hi fellow engineers, I am about to design a PCB containing a Xilinx Virtex-4 FPGA. I have some experience in board design and have already used several Virtex and Virtex-II devices. I want an ICS8442 LVDS clock synthesizer to be the clock source of my Virtex-4. A look at the Virtex-4 User Guide (ug070.pdf) scared me a lot by stating "Clock inputs can be configured for any I/O standard, including differential I/O standards. Each clock input can be either single-ended or differential. All 16 or 32 clock inputs can be differential if desired. Global clock inputs can be configured for any I/O standard except LVDS and HT output differential standards. Only CSE output differential standards are supported by the global clock input pins." Does that mean that I am not allowed to connect an LVDS clock to the Global-clock inputs? Or did I get something wrong here? I have to use the ICS8442 because of the large frequency scale from 25-700 MHz. Regards, MelanieArticle: 93333
"Melanie Nasic" <quinn_the_esquimo@freenet.de> schrieb im Newsbeitrag news:do8vhr$sv9$1@mamenchi.zrz.TU-Berlin.DE... > Hi fellow engineers, > > I am about to design a PCB containing a Xilinx Virtex-4 FPGA. I have some > experience in board design and have already used several Virtex and > Virtex-II devices. I want an ICS8442 LVDS clock synthesizer to be the > clock source of my Virtex-4. > A look at the Virtex-4 User Guide (ug070.pdf) scared me a lot by stating > "Clock inputs can be configured for any I/O standard, including > differential I/O standards. Each clock input can be either single-ended or > differential. All 16 or 32 clock inputs can be differential if desired. > Global clock inputs can be configured for any I/O standard except LVDS and > HT output differential standards. Only CSE output differential standards > are supported by the global clock input pins." > Does that mean that I am not allowed to connect an LVDS clock to the > Global-clock inputs? Or did I get something wrong here? I have to use the > ICS8442 because of the large frequency scale from 25-700 MHz. > > Regards, Melanie > no nothing wrong, read it once more time the clock input pins can not be used LVDS OUTPUT they of course can be used as LVDS input. the restriction of some V4 lvds iopins of being input only for LVDS is new it is related to the 'low capacitance' of those pins I think AnttiArticle: 93334
"Antti Lukats" <antti@openchip.org> wrote in message news:do8vsi$22q$03$1@news.t-online.com... > "Melanie Nasic" <quinn_the_esquimo@freenet.de> schrieb im Newsbeitrag > news:do8vhr$sv9$1@mamenchi.zrz.TU-Berlin.DE... >> Hi fellow engineers, >> >> I am about to design a PCB containing a Xilinx Virtex-4 FPGA. I have some >> experience in board design and have already used several Virtex and >> Virtex-II devices. I want an ICS8442 LVDS clock synthesizer to be the >> clock source of my Virtex-4. >> A look at the Virtex-4 User Guide (ug070.pdf) scared me a lot by stating >> "Clock inputs can be configured for any I/O standard, including >> differential I/O standards. Each clock input can be either single-ended >> or differential. All 16 or 32 clock inputs can be differential if >> desired. Global clock inputs can be configured for any I/O standard >> except LVDS and HT output differential standards. Only CSE output >> differential standards are supported by the global clock input pins." >> Does that mean that I am not allowed to connect an LVDS clock to the >> Global-clock inputs? Or did I get something wrong here? I have to use the >> ICS8442 because of the large frequency scale from 25-700 MHz. >> >> Regards, Melanie >> > no nothing wrong, read it once more time > > the clock input pins can not be used LVDS OUTPUT > they of course can be used as LVDS input. > > the restriction of some V4 lvds iopins of being input only for LVDS is new > it is related to the 'low capacitance' of those pins I think > > Antti > Antti is correct, but I, too, was confused by the wording in the user guide. I contacted our FAE and he confirmed that the restriction is only when using these pins as outputs. BobArticle: 93335
Hello community, I am thinking about implementing a real-time compression scheme on an FPGA working at about 500 Mhz. Facing the fact that there is no "universal compression" algorithm that can compress data regardless of its structure and statistics I assume compressing grayscale image data. The image data is delivered line-wise, meaning that one horizontal line is processed, than the next one, a.s.o. Because of the high data rate I cannot spend much time on DFT or DCT and on data modelling. What I am looking for is a way to compress the pixel data in spatial not spectral domain because of latency aspects, processing complexity, etc. Because of the sequential data transmission line by line a block matching is also not possible in my opinion. The compression ratio is not so important, factor 2:1 would be sufficient. What really matters is the real time capability. The algorithm should be pipelineable and fast. The memory requirements should not exceed 1 kb. What "standard" compression schemes would you recommend? Are there potentialities for a non-standard "own solution"? Thank you for your comments. Regards, MelanieArticle: 93336
I attended Altera's DSP showcase/seminar in Rochester, there was a large presence for interest in implementing MPEG4 (section 10 or 11, I can't remember) for HDTV applications. You didn't say if the advice you are searching for is for a commercial product, R&D science project or a student project but even implementing something real time for DVD quality (720x480) is worth considering. I think a while back somebody announced the availability of JPEG library on the www.opencores.org, http://www.opencores.org/projects.cgi/web/jpeg/overview I haven't tried it but critiquing it could be a good place to start. You could incorporate parts of its implementation into yours, omit the parts you don't agree with, and foster new not present in it. There is also a section Video Compress Systems, http://www.opencores.org/projects.cgi/web/video_systems/overview that would be worth taking a look at. A slightly different approach is using a tool like ImpulseC (www.impulsec.com). It isn't really C but it is close. It allows you to efficiently manage parallel systems of functions and integrate them into VHDL and Verilog designs. Maybe it is the bubble I have been living in, but your clock speed seems high, what device families are you considering? I have seen 80 Mhz designs outperform similar applications on gigahertz PC. Don't let PC marketing skew your objectivity (or maybe it is there choice in operating systems). Could you tell us more about the purpose of your project and you end application? DerekArticle: 93337
Melanie Nasic wrote: > Hello community, > >... > What "standard" compression schemes would you recommend? Are there > potentialities for a non-standard "own solution"? > I would think of something like: - run length encoding - arithmetic coding - maybe a dictionary encoding like zip - if you know some statistics about the values you want to compress you could also try if huffman coding is sufficent Regards Stefan > Thank you for your comments. > > Regards, Melanie > >Article: 93338
"Melanie Nasic" <quinn_the_esquimo@freenet.de> writes:
> Because of the high data rate I cannot spend much time on DFT or DCT
> and on data modelling. What I am looking for is a way to compress
> the pixel data in spatial not spectral domain because of latency
> aspects, processing complexity, etc. Because of the sequential data
> transmission line by line a block matching is also not possible in
> my opinion. The compression ratio is not so important, factor 2:1
> would be sufficient. What really matters is the real time
> capability. The algorithm should be pipelineable and fast. The
> memory requirements should not exceed 1 kb.
You don't say anything about quality.
Here's C code for a lossy compressor / decompressor which consistently
achieves a 2:1 ratio for 8 bpp grayscale images:
#include <stdint.h>
#include <stdio.h>
int
compress(FILE *fin, FILE *fout)
{
uint8_t pin[2], pout;
for (;;) {
if (fread(&pin, sizeof pin, 1, fin) != 1)
return (ferror(fin) ? -1 : 0);
pout = (pin[0] + pin[1]) / 2;
if (fwrite(&pout, sizeof pout, 1, fout) != 1)
return -1;
}
}
int
decompress(FILE *fin, FILE *fout)
{
uint8_t pin, pout[2];
for (;;) {
if (fread(&pin, sizeof pin, 1, fin) != 1)
return (ferror(fin) ? -1 : 0);
pout[0] = pout[1] = pin;
if (fwrite(&pout, sizeof pout, 1, fout) != 1)
return -1;
}
}
(note that the code assumes that the size of the input stream is an
even number)
DES
--
Dag-Erling Smørgrav - des@des.no
Article: 93339"Melanie Nasic" <quinn_the_esquimo@freenet.de> wrote in message news:do9206$1m4$1@mamenchi.zrz.TU-Berlin.DE... > Hello community, > > I am thinking about implementing a real-time compression scheme on an FPGA > working at about 500 Mhz. Facing the fact that there is no "universal > compression" algorithm that can compress data regardless of its structure > and statistics I assume compressing grayscale image data. The image data > is delivered line-wise, meaning that one horizontal line is processed, > than the next one, a.s.o. > Because of the high data rate I cannot spend much time on DFT or DCT and > on data modelling. What I am looking for is a way to compress the pixel > data in spatial not spectral domain because of latency aspects, processing > complexity, etc. Because of the sequential data transmission line by line > a block matching is also not possible in my opinion. The compression ratio > is not so important, factor 2:1 would be sufficient. What really matters > is the real time capability. The algorithm should be pipelineable and > fast. The memory requirements should not exceed 1 kb. > What "standard" compression schemes would you recommend? Are there > potentialities for a non-standard "own solution"? > > Thank you for your comments. > > Regards, Melanie > The answer, as always, is it all depends ... Lossless compression (something like run length encoding) might work for some kinds of image data (computer screens, rendered images), but will fail for others (natural images etc). Lossy compression will of course lose something from the image. The simplest form is probably to average two adjacent pixels, giving you 2 to 1. I suspect that anything more complex will exceed your space/speed/complexity budget. You need to spell out what type of images you are processing, what level of 'loss' is acceptable and why you need compression anyway (it will cause you much pain !) DaveArticle: 93340
"Melanie Nasic" <quinn_the_esquimo@freenet.de> wrote in message news:do9206$1m4$1@mamenchi.zrz.TU-Berlin.DE... > Hello community, > > I am thinking about implementing a real-time compression scheme on an FPGA > working at about 500 Mhz. Facing the fact that there is no "universal > compression" algorithm that can compress data regardless of its structure > and statistics I assume compressing grayscale image data. The image data > is delivered line-wise, meaning that one horizontal line is processed, > than the next one, a.s.o. > Because of the high data rate I cannot spend much time on DFT or DCT and > on data modelling. What I am looking for is a way to compress the pixel > data in spatial not spectral domain because of latency aspects, processing > complexity, etc. Are you hoping for lossless, or is lossy OK? > Because of the sequential data transmission line by line a block matching > is also not possible in my opinion. The compression ratio is not so > important, factor 2:1 would be sufficient. What really matters is the real > time capability. The algorithm should be pipelineable and fast. The memory > requirements should not exceed 1 kb. That's 1024 bits, or bytes? Is it enough for one line? You don't say what your resolution and frame rate are. > What "standard" compression schemes would you recommend? Are there > potentialities for a non-standard "own solution"? If you don't have a line of storage available, that restricts you a lot. I don't understand this though. If you're using a 500MHz FPGA, it's presumably recent, and presumably has a decent amount of storage. How about a 1d predictor, non-linear quantizer and entropy coder? If you have more memory available, look at JPEG-LS. It can do lossless, or variable mild degrees of loss. > > Thank you for your comments. > > Regards, Melanie >Article: 93341
Hi Pete, I want the compression to be lossless and not based on perceptional irrelevancy reductions. By stating 1 kb I meant 1024 bits and that's just about half the line data. Your recommendation "1d predictor, non-linear quantizer and entropy coder" sound interesting. COuld you please elaborate on that? How is it done? Where can I find some exemplary codes? How can it be achieved with hardware (VHDL sources?) Thank you a lot. Bye, Mel. "Pete Fraser" <pfraser@covad.net> schrieb im Newsbeitrag news:11qg5v3q9plph0a@news.supernews.com... > > "Melanie Nasic" <quinn_the_esquimo@freenet.de> wrote in message > news:do9206$1m4$1@mamenchi.zrz.TU-Berlin.DE... >> Hello community, >> >> I am thinking about implementing a real-time compression scheme on an >> FPGA working at about 500 Mhz. Facing the fact that there is no >> "universal compression" algorithm that can compress data regardless of >> its structure and statistics I assume compressing grayscale image data. >> The image data is delivered line-wise, meaning that one horizontal line >> is processed, than the next one, a.s.o. >> Because of the high data rate I cannot spend much time on DFT or DCT and >> on data modelling. What I am looking for is a way to compress the pixel >> data in spatial not spectral domain because of latency aspects, >> processing complexity, etc. > > Are you hoping for lossless, or is lossy OK? > >> Because of the sequential data transmission line by line a block matching >> is also not possible in my opinion. The compression ratio is not so >> important, factor 2:1 would be sufficient. What really matters is the >> real time capability. The algorithm should be pipelineable and fast. The >> memory requirements should not exceed 1 kb. > > That's 1024 bits, or bytes? > Is it enough for one line? > You don't say what your resolution and frame rate are. > >> What "standard" compression schemes would you recommend? Are there >> potentialities for a non-standard "own solution"? > > If you don't have a line of storage available, that restricts you a lot. > I don't understand this though. If you're using a 500MHz FPGA, it's > presumably recent, and presumably has a decent amount of storage. > > How about a 1d predictor, non-linear quantizer and entropy coder? > If you have more memory available, look at JPEG-LS. > It can do lossless, or variable mild degrees of loss. >> >> Thank you for your comments. >> >> Regards, Melanie >> > >Article: 93342
Eric in <1135052719.226464.50920@f14g2000cwb.googlegroups.com>: > I have Linux up running for PPC on the virtex-ii pro board (XUPV2P). > I'm new to embedded system design. Anyhow, I'm hoping to run software > applications on the board. I'm familiar with adding software to the > standalone system using EDK. But with an OS on it, what modifications > do I need to make before the executables (.elf) can be run? Is there > any reference? Thanks plenty. shouldn't static binaries run without any modifications? when building the application, the link step should specify the `-static' flag. clemensArticle: 93343
Antti, Yes, some pins do not have the LVDS output structure. The "low capacitance" that affords is a mere 0.5 pF, so I think more appropriate would be to say these pins just don't have these two IO output standards available to them. Austin Antti Lukats wrote: > "Melanie Nasic" <quinn_the_esquimo@freenet.de> schrieb im Newsbeitrag > news:do8vhr$sv9$1@mamenchi.zrz.TU-Berlin.DE... > >>Hi fellow engineers, >> >>I am about to design a PCB containing a Xilinx Virtex-4 FPGA. I have some >>experience in board design and have already used several Virtex and >>Virtex-II devices. I want an ICS8442 LVDS clock synthesizer to be the >>clock source of my Virtex-4. >>A look at the Virtex-4 User Guide (ug070.pdf) scared me a lot by stating >>"Clock inputs can be configured for any I/O standard, including >>differential I/O standards. Each clock input can be either single-ended or >>differential. All 16 or 32 clock inputs can be differential if desired. >>Global clock inputs can be configured for any I/O standard except LVDS and >>HT output differential standards. Only CSE output differential standards >>are supported by the global clock input pins." >>Does that mean that I am not allowed to connect an LVDS clock to the >>Global-clock inputs? Or did I get something wrong here? I have to use the >>ICS8442 because of the large frequency scale from 25-700 MHz. >> >>Regards, Melanie >> > > no nothing wrong, read it once more time > > the clock input pins can not be used LVDS OUTPUT > they of course can be used as LVDS input. > > the restriction of some V4 lvds iopins of being input only for LVDS is new > it is related to the 'low capacitance' of those pins I think > > Antti > >Article: 93344
"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag news:do988l$84u2@xco-news.xilinx.com... > Antti, > > Yes, some pins do not have the LVDS output structure. The "low > capacitance" that affords is a mere 0.5 pF, so I think more appropriate > would be to say these pins just don't have these two IO output standards > available to them. > > Austin > Hi Austin yes I know, I learned it the hard way, I was jump starting a FX12 board with LVDS _output_ clock connected in the banks that do not LVDS out (eg banks 0..3 for FX12-SF363) - after reading the datasheet, well its all in the datasheet but I guess there are more people around to find this issue the hard way. AnttiArticle: 93345
I totally agree on that, Antti! The information given in the user guide is very misleading. "Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:do998g$nc3$00$1@news.t-online.com... > "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag > news:do988l$84u2@xco-news.xilinx.com... >> Antti, >> >> Yes, some pins do not have the LVDS output structure. The "low >> capacitance" that affords is a mere 0.5 pF, so I think more appropriate >> would be to say these pins just don't have these two IO output standards >> available to them. >> >> Austin >> > Hi Austin > > yes I know, I learned it the hard way, I was jump starting a FX12 board > with LVDS _output_ clock connected in the banks that do not LVDS > out (eg banks 0..3 for FX12-SF363) - after reading the datasheet, well > its all in the datasheet but I guess there are more people around > to find this issue the hard way. > > Antti >Article: 93346
Stefan, The huffman coding sounds interesting. From what I remember, most real image data is spatially correlated. That would lead me to guess that the most likely difference between two adjacent pixel values is zero, then one, etc. This would seem to be suitable to use huffman coding on, by just coding the difference It would be interesting to run sample scenes through the filter. It is not obvious that a lossless 2:1 reduction can be guaranteed because one could synthesize a scene that would not compress. Also, the transformed image may not be robust in the presence of noise. Just my two cents. -NewmanArticle: 93347
Reza - Most designs use a clock becuase they are synchronous designs. Current methodologies favor this design style for many reasons, too many to go into here. In a synchronous system, all logic is clocked by some (small) number of system clocks. This makes timing analysis easier and avoids a lot of potential bugs. You should take a look at some real life examples of Verilog code to see how it is written in the real world. There are lots of sources to look at on the web, take a look at some of the simpler designs at opencores.org One thing to remember - some of the Verilog language can't be synthesized. When you're coding something, try to imagine what the hardware would look like. For example, the "wait()" construct is not synthesizable. Why? Could you imagine harware to implement something like wait()? Good Luck! John ProvidenzaArticle: 93348
John - You mention the patent describes the Median Filter, but does it actually claim it in the claims section? A patent can describe anything, but the last section of the patent (the claims) is where the patent actually claims what the invention is. If it isn't in the claims, it is not being patented. John ProvidenzaArticle: 93349
Since there are 54 patents with "Inventor Name" including "Jiang" and "Assignee Name" including "Lucent" I'm guessing this guy gets paid based on how many patents he churns out. I would contact the Lucent General Counsel (the lawyers) and *ask* them if they would like to know of a patent based on plagiarized ideas. Most of the claims are for "The method" which you appear to have developed. You can supply the general counsel with supporting documentation. It's sad to see plagiarism. It's ridiculous to have someone make a living off it. "JustJohn" <john.l.smith@titan.com> wrote in message news:1135044436.644317.150800@o13g2000cwo.googlegroups.com... > Ah, this is interesting. Weng and I have been having this extended chat > on median filters (hope it did not bore anyone), and because it seems > that Weng is looking to develop something patentable, I had a look-see > over at USPTO. I find there is a recently (04, July) granted patent, US > 6760737, which seems after wading through all the pat-speak > gobbledy-gook (which is mostly in the order of a proof (that can be > done a bit simpler)), to list my median circuit exactly. One paragraph > (col 4, lines 47-50) even describes the pipelining, not verbatim from > the XCell note, but close enough. > > So has anyone else here had this happen? What was your reaction? On the > one hand, I'm pleased to see that I can generate patentable stuff (5 > years earlier than filing date on this one), but on the other hand > mildly annoyed to see someone else's name there, and wishing I'd made > the filing myself. How would you react? > > I would think the patent is useless, because I'd already shown the > method, but am wondering if the state of law is such that Lucent could > come after me for using my own circuit. > > Corrolary question...Do most patents just make money for lawyers and > add to the writer's resumes? Or do a majority have actual worth beyond > that? > > Regards All, > John >
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