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
>Scramble technology still uses randomized serial and XOR now? After 8b/ >10b technology, I think other randomized XOR scramble technology is >dying out, is it right? 8b/10b has a 20% bandwidth hit. That may be reasonable on short links where the cost of the link is small relative to the cost of the end points. But change hats from a computer room to a Telco. Their costs are mostly the fibers in the ground. Using scramblers is a no-brainer for 20% cost reduction. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 124376
Weng Tianxiang wrote: > Hi Hal, > 8b/10b is perfect for scrambling function. PCI-e uses 8b/10b > technology. > > Scramble technology still uses randomized serial and XOR now? After 8b/ > 10b technology, I think other randomized XOR scramble technology is > dying out, is it right? > > IBM got one patent for 8b/10b technology in 1981, Xilinx filed for 23 > patents on 8b/10b implementation in FPGA on one day in 2004. > > I think that IBM is really a technology leader in almost all respects > in computer industry. Xilinx is the leader of FPGA. > > Weng 80B/10B is not a scrambler. It's a coding mechanism used to balance the DC offset of the encoded stream. It's a straight encode/decode. Don't be disappointed and frustrated for what you don't know.Article: 124377
On 19 Sep., 17:56, merche <dora...@gmail.com> wrote: > Hi!, I have a big problem: > > I use Libero to Proasic Plus Family of Actel. My FPGA has got 4 global > pin (4 GL macro), I need put a clock in a global buffer but I can=B4t > because I have others signals with highest fanout. what can I do? Explain your real problem. Do you need more global inputs or is it a problem of synthesis? Then instantiate a GL Buffer for the clk in your codeArticle: 124378
Another fat-ass discussion invoked by Weng. Hey Weng, you always turn on the most crapiest and unhealthiest discussions. BTW any big-company chief scientists or fat-ass academic professors want to discuss about YARDstick, my super tool for custom processor development? There is a joke about academic bozzos and their capability of coding... http://electronics.physics.auth.gr/people/nkavv/yardstick/Article: 124379
Hi Allan. You hit the point. That is exactly why there are no such designs in real life. You always can trade comb. delay vs. latency, but you have to look for the solution that suits your needs the best. Now look at your example result with 14MHz. Theoretical data throughput is the same as in an iterative design running at 14*14Mhz, which I think is a clock frequency that can be achieved by modern FPGAs. But: With the iterative design you save about 90% area and don't have to worry so much about moving the data from one clock domain to another. In the best possible case you can run the AES and all other circuits at the same (high) clock frequency. The same thing is also valid for the S-Boxes in an AES design. Often made with Blockrams, out of convenience. But there are solutions published that use very small combinatorical circuits. These solutions have the disadvantage of large delays (20 to 30 ns) thus reducing the clock rate of the whole AES design. Now what do you do in such a case? Find out how to pipeline that solution. If you can increase the clock frequency into a range where it fits into the overall design, you can save all the valuable and rare BRAMs. It may cost you some clock cycles of additional latency, but it depends on the application if that is a problem or not. So back to your original postings title: Complex cores with low latency have high combinatorical delays. The problems that arise from such solutions are in most cases larger than the benefits, if there are any at all. Have a nice synthesis Eilert Allan Herriman schrieb: ...snip... > I did some tests today... > > I unrolled our (conventional) 14 round implementation into one big > mess of combinatorial logic with FFs at either end and ran it through > the tools: > ...snip... > 14MHz results in feedback modes giving about 1.8Gb/s encryption > throughput. I guess that's enough for GbEthernet, but we already know > GbE can be done with a conventional pipelined AES implementation.Article: 124380
>Also, "Fourteen Ways to Fool Your Synchronizer" is a reasonable paper > >http://www.ee.technion.ac.il/~ran/papers/Sync_Errors_Feb03.pdf I think I understand metastability. Several/many years ago, I used to use it as a calibration on books. Look in the index under metastability or synchronizer. If you don't find anything you know either the book doesn't cover it or the index is poor. It's hard to imagine a text on digital logic that doesn't mention metastability. Who wants a book with a crappy index? If you do find something, see if it matches your understanding. The paper is probably better than average,, but that's relative to a field full of bogus/useless papers. If you don't already understand metastability, it doesn't do a very good job of explaining it. If you do understand it, it has a few patterns that might be good to add to your list. The real estate people joke about the 3 most important things being location, location, and location. Well, in metastability, the 3 most important things are settling time, settling time time, and settling time. Assuming you believe in settling time, here are my comments on the paper. 0) Section 2, A Correct Two Flop Synchronizer It gives the classic MTBF formula. It doesn't mention that the data is hard to get. I haven't seen any data other than lab typicals. Has anybody seen any numbers on VCC or Temp or process? Has anybody seen anything in a data sheet? (as compared to an app-note) It also doesn't even hint that you might want to be extra conservative if your design is used in safety critical equipment (as compared to a lab hack to collect some data from a one-shot experiment) or if your design will be used in a bazillion systems with good software where a hardware glitch will generate a core dump that the software guys get to pour over. 1) Section 3.2, the One Flop Synchronizer... This can actually be good enough. Suppose you have a system with the classical 2 FF synchronizer that works OK at 100 MHz. The best case settling time is 10 ns. (That's ignoring clock-to-out, routing, and setup times.) Suppose you run that system at 50 MHz but remove the first FF. The big ugly cloud of gates in the FSM picture is good enough to run at 10 ns but your system clock is 20 ns, so you have a guaranteed 10 ns of settling time. That was more than good enough in the 2 FF case. Why isn't it good enough in the one FF case? 2) They missed another important case - routing delays. Just because your 2 FFs are right next to each other on the schematic or source code doesn't meant the placement tools will put them next to each other on the chip. If your FFs are far apart, the routing delays can eat up a lot of the cycle time leaving not much left for settling time. 3) Section 3.11, Metastability Blocker Kludges like this are a good sanity check. There are two reasons to run away when you see one. First, they are (often) hard to analyze. With the classic 2 FF case you have a good chance of understanding things. You can use the standard formula to estimate MTBF and vendors sometimes publish data to plug into the formula. With a kludge, you have to read all the fine print on the data sheets until you find the catch. One of the classic examples put a runt pulse on the reset to a FF. Please let me know if you find any data to back that up. The second reason is that kludges eat up prop time, thus reducing settling time. Settling time is exponential. That's much better than the constant factor from a kludge. (If you find one that works, please let me know.) I can't figure out how that example is supposed to work. The S/R FF gets reset by RESET. It gets set if the mux lets a 1 through. Maybe the S/R FF should get reset by clock low, or something like that. In any case, it only leaves a half cycle of settling time. (assuming 50-50 clocking.) -- These are my opinions, not necessarily my employer's. I hate spam.Article: 124381
Hi everyone, may I ask you a question. I'm trying to find out how to handle multi-cycle paths in VHDL libraries. I'm using Xilinx ISE 9.2i and XST. I have designed a number of modules, all compiled into separate libraries, which I would now like to use in a bigger design. Some of them have multi-cycle paths, so I would like to specify appropriate timing constraints. I know that I can specify from-to (only?) in an .xcf-file, however, that information appears to end up only in the .ngc-netlist, not in the VHDL-library. As opposed to, for example, a maxdelay-constraint, which I can specify as an attribute in the VHDL-source, and which is included in the library and later recognized by P&R. Any help? Thanks a lot, best regards GunterArticle: 124382
On Sep 20, 7:26 am, Thomas Stanka <usenet...@stanka-web.de> wrote: > On 19 Sep., 17:56, merche <dora...@gmail.com> wrote: > > > Hi!, I have a big problem: > > > I use Libero to Proasic Plus Family of Actel. My FPGA has got 4 global > > pin (4 GL macro), I need put a clock in a global buffer but I can=B4t > > because I have others signals with highest fanout. what can I do? > > Explain your real problem. Do you need more global inputs or is it a > problem of synthesis? Then instantiate a GL Buffer for the clk in your > code thanks Thomas Stanka! But... In my code I have instantiated a GL Buffer (is a fast clock). But in the synthesis: the log say... Automatic dissolve during optimization of view:work.w_r9(w_r9) of GL2(GL) then, others signals with highest fanout promoted to global buffer. This synthesis is made with Synplify. I don=B4t know how change this automatic options.Article: 124383
thanks Thomas Stanka! But... In my code I have instantiated a GL Buffer (is a fast clock). But in the synthesis: the log say... Automatic dissolve during optimization of view:work.w_r9(w_r9) of GL2(GL) then, others signals with highest fanout promoted to global buffer. This synthesis is made with Synplify. I don=B4t know how change this automatic options.Article: 124384
On 18 Wrz, 04:12, Pasacco <pasa...@gmail.com> wrote: > Hi > > Let me ask two questions --: > > According to Virtex-4 configuaration guide > (http://www.xilinx.com/bvdocs/userguides/ug071.pdf), > ICAP interface is either 8-bit or 32-bit, with up to 60MHz CCLK. > Most of diagrams and explanations are based on 8-bit interface. > > I also saw one document, in which latest VIrtex-4 ICAP provides 32-bit > interface with 100 MHz. > > I wonder if 32-bit interface operates, in a same way as 8-bit > interface. > > Is 32-bit interface 4 times faster than 8-bit interface? > > In 100 MHz mode, are there any handshaking during the bitstream > loading? It could be to fast, > (There was no handshaking during bitream loading, in Virtex-II Pro, if > I am correct) There is "busy" signal. Look into the Virtex4 Configuration Guide Regards, Jerzy GburArticle: 124385
Data on D must be stable before CLK, else you'll got garbage, scientificaly called "metastability" problems. http://www.interfacebus.com/Design_MetaStable.html Vasile On Sep 19, 7:52 pm, Berk Birand <d...@email.me> wrote: > Hi everyone, > > I am running into a really peculiar problem for a research project that I > am working on. The circuit is fairly simple one, which needs to measure > which one of two signals reaches a flip-flop first. Two impulses are sent > through two different paths, and they are both fed to a D flip-flop. The > circuit uses a nifty trick for outputting which signal got there first. > > One of the signals (signal A) is connected to the D input, and the other > one (signal B) to the Clock input. Both signals get a 0-to-1 transition. > If signal A arrives first, D is '1' when there is a transition on Clk, > so output of flip-flop is 1: > > |------------- > A (D) | > ____| > > |------------- > B (Clk) | > __________| > > If signal B gets there first, then when Clock occurs, D is still '0', so > output is '0' > > |------------- > D | > _________| > > |------------- > Clk | > ____| > > (I hope my feeble attempts were sufficient to demonstrate the situation) > > It was pretty easy to code this using VHDL; I just needed to connect the > signals correctly. > > The problem is that during the Place & Route phase, I receive a warning > telling me that I have a clock signal coming from a combinatorial, gated > circuit. As I have pointed out, this is actually what I want. The peculiar > problem manifests itself as follows: > When I synthesize it, the Device Summary correctly finds 64 slices that > are being used. Yet when I run PAR, that number suddenly becomes 8 slices! > I think the reduction in the slice count is due to the given warning, > since the rest of the circuit behaves as expected. > > Can anybody tell me how I should deal with this situation? I have tried > using a CLOCK_SIGNAL attribute, but I doubt that's what I want. > > I would appreciate any help, > Thanks, > Berk Birand > > -- > Posted via a free Usenet account fromhttp://www.teranews.comArticle: 124386
> IF OP = "Weng Tianxiang" AND group = comp_arch_fpga THEN > be_prepared_for_a_long_thread; > ORIF crossposted = to_comp_lang_vhdl THEN > this_could_go_on_all_week; > ANDIF both_the_above THEN > make_that_a_month; > BUTIF plonk! THEN > blessed_relief; > ELSIF experiences < imagination THEN > OP_question <= not(sense); > ELSE > possibly_on_topic; > END IF; > > HTH., Syms. ;-) > > p.s. Sorry, couldn't resist it! > > p.p.s. I guess one. You can view the whole FPGA as one big state machine. > Do I win £5? ROFL, how could I have missed this posting for 3 days... LOL ThomasArticle: 124387
"vasile" <piclist9@gmail.com> wrote in message news:1190286570.416365.21640@19g2000hsx.googlegroups.com... > Data on D must be stable before CLK, else you'll got garbage, > scientificaly called "metastability" problems. > http://www.interfacebus.com/Design_MetaStable.html > > Vasile > I feel I need to argue this morning ... you won't get garbage. If you violate setup, the output will go metastable for a short period of time and then settle on either the previous value or the new value. The metastability will be so short in duartion you may as well ignore is effect unless you have a clock period above 500Mhz. MikeArticle: 124388
For example, I have two wires FA[23:1] (address line for Flash) and RAM_A_SD[63:0] (data line for SRAM), due to the number of pins constraint, FA and RAM_A_SD share the same FPGA pins (seen from outside of FPGA). I tried to assign those two wires to the same pins in pin assignment file, but got errors from Xilinx ISE mapping process, saying that it is incorrect to assign two wires to the same pin and cannot resolve the pin assignments. Just wondering whether it is possible to use both Flash and SRAM outside of FPGA in this case, or should I tri-state every single data line which shares the same pin with other wires, such that there is only one wire goes into a particular pin (seen from inside fpga)? cheers, -WeiArticle: 124389
On Thu, 20 Sep 2007 08:12:03 +0200, backhus <nix@nirgends.xyz> wrote: >Hi Allan. >You hit the point. >That is exactly why there are no such designs in real life. Ah yes. I have come to the same conclusion. A few years ago, I designed what I believe was the first 10Gb/s AES256 encryptor on the market. It used CTR mode, because that was the only mode suitable to run at those rates in the FPGAs that were available then. I recall thinking that feedback modes (e.g. CFB) would be possible at 10Gb/s in FPGAs in a few years time. I'll try this test again when the next generation of FPGAs come out. For the crypto naive: The throughput of a block cypher with feedback is determined by the delay through the block cypher calculation. Pipelining is good for getting impressive clock numbers, but it actually hurts throughput. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Thanks to all who responded, Allan.Article: 124390
"Mike Lewis" <someone@micrsoft.com> wrote in message news:55a73$46f26a9e$401a86c3$16577@PRIMUS.CA... > > "vasile" <piclist9@gmail.com> wrote in message > news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >> Data on D must be stable before CLK, else you'll got garbage, >> scientificaly called "metastability" problems. >> http://www.interfacebus.com/Design_MetaStable.html >> >> Vasile >> > > I feel I need to argue this morning ... you won't get garbage. If you > violate setup, the output will go metastable for a short period of time > and then settle on either the previous value or the new value. The > metastability will be so short in duartion you may as well ignore is > effect unless you have a clock period above 500Mhz. > > Mike > Hi Mike, That's not true. (You did say you were up for an argument!) Flipflops can go metastable for any (unlimited) amount of time, with rapidly decreasing probability as the metastable time increases. Also, it is not necessarily the case that the FF's output goes crazy during metastability. The effect can manifest itself as an arbtrarily long clock to out. As to ignoring this effect unless you're going at 500MHz or more, I hope you don't work on any safety critical systems! In FPGA-land, the timing closure tools only aim to meet the clock timing for non-metastable FFs. The place and route could easily leave a circuit vulnerable to a slight increase in clock to out delay caused by metastability. There's no need for us to go over all this yet again. Googling comp.arch.fpga will doubtless return hundreds of posts about folks' "metastability proof FFs" with thousands of replies shooting these devices down! IIRC, Peter from Xilinx has published the results of his extensive experiments on this issue. I urge anyone interested to track this down. HTH, Syms. p.s. As for the OP's question, I'm pretty sure the warning isn't the problem. I guess the P&R is optimising away logic which can be reduced, perhaps because the logic's outputs don't get used.Article: 124391
On Sep 20, 9:06 am, Wei Wang <camww...@gmail.com> wrote:
> For example, I have two wires FA[23:1] (address line for Flash) and
> RAM_A_SD[63:0] (data line for SRAM), due to the number of pins
> constraint, FA and RAM_A_SD share the same FPGA pins (seen from
> outside of FPGA). I tried to assign those two wires to the same pins
> in pin assignment file, but got errors from Xilinx ISE mapping
> process, saying that it is incorrect to assign two wires to the same
> pin and cannot resolve the pin assignments. Just wondering whether it
> is possible to use both Flash and SRAM outside of FPGA in this case,
> or should I tri-state every single data line which shares the same pin
> with other wires, such that there is only one wire goes into a
> particular pin (seen from inside fpga)? cheers, -Wei
I'll try this again:
Wei;
<1>
FA[0] ---|3S>-----+------ FPGA pin
FA_en----^ |
|
RAM_A_SD---|3S>----+
RAM_A_en -----^
--|3S>-- is a tri-state buffer
^ is its enable pin
-Dave Pollum
Article: 124392On Thu, 20 Sep 2007 07:06:42 -0700, Wei Wang <camwwang@gmail.com> wrote: >For example, I have two wires FA[23:1] (address line for Flash) and >RAM_A_SD[63:0] (data line for SRAM), due to the number of pins >constraint, FA and RAM_A_SD share the same FPGA pins (seen from >outside of FPGA). I tried to assign those two wires to the same pins >in pin assignment file, but got errors from Xilinx ISE mapping >process, saying that it is incorrect to assign two wires to the same >pin and cannot resolve the pin assignments. Just wondering whether it >is possible to use both Flash and SRAM outside of FPGA in this case, >or should I tri-state every single data line which shares the same pin >with other wires, such that there is only one wire goes into a >particular pin (seen from inside fpga)? cheers, -Wei If I understand what you're asking, you need to time multiplex the pins internally ie as you have to have two sets of wires, one for flash, one for sram, you need to multiplex them before you drive the pins. So you have a single set of pins which goes to both flash & sram and individual chip enable pins to tell which external chip can use the wires. So internally multiplex the buses, & externally de-mux with the chip select. Hope this helps.Article: 124393
In comp.arch.fpga, Symon <symon_brewer@hotmail.com> wrote: >> >> "vasile" <piclist9@gmail.com> wrote in message >> news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >>> Data on D must be stable before CLK, else you'll got garbage, >>> scientificaly called "metastability" problems. >>> http://www.interfacebus.com/Design_MetaStable.html [...] > That's not true. (You did say you were up for an argument!) Flipflops can go > metastable for any (unlimited) amount of time, with rapidly decreasing > probability as the metastable time increases. Also, it is not necessarily > the case that the FF's output goes crazy during metastability. The effect > can manifest itself as an arbtrarily long clock to out. If the clock to out can be arbitrary long, how would the above proposed solution with the extra synchronizer DFF solve the problem? If the setup of the synchronizer DFF is violated (which is inevitable as the D-input is an external signal), it's output may violate the input setup time of the synchronous system for the next clock edge. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)Article: 124394
"Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message news:a9f1c$46f28f36$54f63171$8563@publishnet.news-service.com... > In comp.arch.fpga, > Symon <symon_brewer@hotmail.com> wrote: >>> >>> "vasile" <piclist9@gmail.com> wrote in message >>> news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >>>> Data on D must be stable before CLK, else you'll got garbage, >>>> scientificaly called "metastability" problems. >>>> http://www.interfacebus.com/Design_MetaStable.html > [...] >> That's not true. (You did say you were up for an argument!) Flipflops can >> go >> metastable for any (unlimited) amount of time, with rapidly decreasing >> probability as the metastable time increases. Also, it is not necessarily >> the case that the FF's output goes crazy during metastability. The effect >> can manifest itself as an arbtrarily long clock to out. > > If the clock to out can be arbitrary long, how would the above proposed > solution with the extra synchronizer DFF solve the problem? If the setup > of the synchronizer DFF is violated (which is inevitable as the D-input > is an external signal), it's output may violate the input setup time > of the synchronous system for the next clock edge. > > -- > Stef > Hi Stef, That's the whole point. You can't cure the problem 100%, but you can get arbitrarily close to fixing it by using more synchronising FFs, or waiting longer. Someone once suggested that circuits should be designed to only go metastable once (on average) for twice the amount of time you plan to be in the job you're doing! HTH, Syms.Article: 124395
On Thu, 20 Sep 2007 17:18:14 +0200, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: >In comp.arch.fpga, >Symon <symon_brewer@hotmail.com> wrote: >>> >>> "vasile" <piclist9@gmail.com> wrote in message >>> news:1190286570.416365.21640@19g2000hsx.googlegroups.com... >>>> Data on D must be stable before CLK, else you'll got garbage, >>>> scientificaly called "metastability" problems. >>>> http://www.interfacebus.com/Design_MetaStable.html >[...] >> That's not true. (You did say you were up for an argument!) Flipflops can go >> metastable for any (unlimited) amount of time, with rapidly decreasing >> probability as the metastable time increases. Also, it is not necessarily >> the case that the FF's output goes crazy during metastability. The effect >> can manifest itself as an arbtrarily long clock to out. > >If the clock to out can be arbitrary long, how would the above proposed >solution with the extra synchronizer DFF solve the problem? If the setup >of the synchronizer DFF is violated (which is inevitable as the D-input >is an external signal), it's output may violate the input setup time >of the synchronous system for the next clock edge. You don't solve the problem you ameliorate it. The probability that a flop going metastable is p, two of them going metastable one after the other is p^2 (rougly speaking, I'm an engineer not a mathematician). If p is sufficiently small, p^2 may be small enough that you won't get it till sun goes super nova (or what ever our star will do when it reaches its end of life). If that's not acceptable to you add another flop to make the probability p^3 and stick around till our galaxy becomes a mush.Article: 124396
Hal Murray wrote:
> 1) Section 3.2, the One Flop Synchronizer...
>
> This can actually be good enough. Suppose you have a system with the
> classical 2 FF synchronizer that works OK at 100 MHz. The best case
> settling time is 10 ns. (That's ignoring clock-to-out, routing, and
> setup times.) Suppose you run that system at 50 MHz but remove the
> first FF. The big ugly cloud of gates in the FSM picture is good
> enough to run at 10 ns but your system clock is 20 ns, so you have
> a guaranteed 10 ns of settling time. That was more than good enough
> in the 2 FF case. Why isn't it good enough in the one FF case?
I use at least two anyway to rule out duplication
of the synchronizing register by synthesis
(which could eliminate the synchronization effect).
I could do the same thing with constraints,
but these do not always follow the source
code around.
-- Mike Treseler
Article: 124397Hi everyone. I'm trying to transfer data from DDR memory to a custom PLB_IPIF peripheral in a Virtex II Pro XUP card. I have some questions: 1. In EDK is not possible to configure a scatter-gather DMA access with PLB in the Peripheral wizard. Why? 2. I'm trying to transfer data using simple DMA under linux 2.4 compiled for PPC405, but the system crash when it is inicialized the DMA transfer. Totally dead. I'm keeping in mind the differences between physical and virtual addresses in source and destiny registers, in fact i have tried with a driver for kernel. In standalone mode the DMA transfer works fine. I'm working with EDK 8.2 . I know there are many things can be wrong, but any help or suggestion is appreciated. Thank you in advance.Article: 124398
Hi, I am working on a study to copmpre the effiency of synthesied adders. I have built a ripple adder and a carry look ahead using VHDL for a Virtex FPGA. I know that the lookahead carry adder is much faster than the ripple carry adder but when I synthezied both fro a 16 bit adder i got only an improvement of 2ns using the lookahead carry adder. For the lookahead adder i built a 1 bit adder which generates the P,G,Sum and Carry and than built the lookahead logic using standard techniques. The carry in was computed as : C(i) <= G(i-1) or ( P(i-1) and C(i-1); Finally i added the inputs and the Carries. Can someone telle me if i did wrong implementation or give me some tips how to code it properly. Thanks a lot JosephArticle: 124399
>I feel I need to argue this morning ... you won't get garbage. If you >violate setup, the output will go metastable for a short period of time and >then settle on either the previous value or the new value. The metastability >will be so short in duartion you may as well ignore is effect unless you >have a clock period above 500Mhz. What page of the data sheet says that? How do you know what can be ignored in my application? (You probably won't "ignore" things if your system is doing critical things like pointing missles or keeping track of money.) -- These are my opinions, not necessarily my employer's. I hate spam.
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