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
<> > Do you know the terms SPI or EIA-232? =A0Or ain't you got to that point > in your class yet? > > Rick I know SPI, but ain't done it. But I haven't heard of EIA-232 yet, is it like the RS-232 : PArticle: 149426
On Oct 24, 1:37=A0pm, Santosh <santos...@gmail.com> wrote: > <> > > > Do you know the terms SPI or EIA-232? =A0Or ain't you got to that point > > in your class yet? > > > Rick > > I know SPI, but ain't done it. But I haven't heard of EIA-232 yet, is > it like the RS-232 : P So what class is this for?Article: 149427
Hi everybody, I'm designing a VHDL testbench for a VHDL module. I have to generate values to be written into a 32 bit register of my module. I decided tu use integer variables to compose my data and than convert them to std_logic_vector to perform the write operation on the module. The issue is that I discovered that VHDL integer range is from -2147483647 to 2147483647, that is to say 0x80000000 integer is not supported. Is there any way to work out this limitation without using directly std_logic_vector type? Thank you in advance for any help Claudia --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149428
On 25 Okt., 12:24, "cdb" <claudia.de- bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote: > The issue is that I discovered that VHDL > integer range is from -2147483647 to 2147483647, > that is to say 0x80000000 integer is not supported. To be precise, 0x80000000 is not necessary supported, which makes it way more complicated. Each tool might define integer in a way it like to do it, as long as integer covers _at least_ the range mentioned above. According to LRM it is valid if a simulator uses 64 bit integer (or 42 bit). > Is there any way to work out this limitation without using directly > std_logic_vector type? No easy way. You could implement whatever you want to use something else (eg. build your own type int64, costs of course a lot of effort), but I suggest using std_(u)logic_vector as soon as you need at least 32 bit. bye ThomasArticle: 149429
On Mon, 25 Oct 2010 05:24:50 -0500, "cdb" <claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote: >Hi everybody, >I'm designing a VHDL testbench for a VHDL module. > >I have to generate values to be written into a 32 bit register of my >module. >I decided tu use integer variables to compose my data and than convert them >to std_logic_vector to perform the write operation on the module. > >The issue is that I discovered that VHDL >integer range is from -2147483647 to 2147483647, >that is to say 0x80000000 integer is not supported. It's worse than that. The integer range is guaranteed to cover that range, but is not necessarily limited to it. So some implementations allow 0x80000000 while others do not. That means you can simulate in Modelsim, and find out later that your code will not synthesise, or simulate in Xilinx ISE simulator. >Is there any way to work out this limitation without using directly >std_logic_vector type? Use the numeric_std library, either signed or unsigned, if your register values represent numeric types. If they represent non-numeric quantites (bitmasks, CPU instructions, characters) then declare them as such, e.g. std_logic_vector constants. Using integers for non-numeric quantites only sows confusion about the intent of your design. - BrianArticle: 149430
>On Mon, 25 Oct 2010 05:24:50 -0500, "cdb" ><claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote: > >>Hi everybody, >>I'm designing a VHDL testbench for a VHDL module. >> >>I have to generate values to be written into a 32 bit register of my >>module. >>I decided tu use integer variables to compose my data and than convert them >>to std_logic_vector to perform the write operation on the module. >> >>The issue is that I discovered that VHDL >>integer range is from -2147483647 to 2147483647, >>that is to say 0x80000000 integer is not supported. > >It's worse than that. The integer range is guaranteed to cover that range, but >is not necessarily limited to it. > >So some implementations allow 0x80000000 while others do not. That means you can >simulate in Modelsim, and find out later that your code will not synthesise, or >simulate in Xilinx ISE simulator. > >>Is there any way to work out this limitation without using directly >>std_logic_vector type? > >Use the numeric_std library, either signed or unsigned, if your register values >represent numeric types. > >If they represent non-numeric quantites (bitmasks, CPU instructions, characters) >then declare them as such, e.g. std_logic_vector constants. >Using integers for non-numeric quantites only sows confusion about the intent of >your design. > >- Brian > Thanks Brian, I need to use 0x80000000 integer only in non-synthesizable code (a testbench), and I decided to adopt integers at high level of my testbench , because at the beginning it seemed more flexible to me ( random number generation etc. ..) and I'm using Modelsim. I verified that in fact -2**31 is supported and it's than converted in the proper std_logic_vector ( I got confused because I was using quartus packages too, in order to use the to_string fuction for example,and quartus staff seems not to support (-2**31) value) Modelsim integer extension seems to solve my problems, but as you rightly noticed, it's not a clear solution: to express non-numeric quantities ( es values to be written on a 32 bit control register) as integer I'm forced to use signed value and consequently a std_logic_vector(TO_SIGNED(...) way of convert them. Modelsim positive/natural range seems to be up to (2*31 - 1) ... Thank you Bye Claudia --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149431
Hello,
I want to use 24 pairs of LVPECL_25 differential inputs in my design,
at a S3E500 FPGA device. During mapping, ISE gives the following
warnings and removes these inputs:
MapLib:701 - Signal pecl_input_p<23> connected to top level port
pecl_input_p<23> has been removed.
MapLib:701 - Signal pecl_input_n<23> connected to top level port
pecl_input_n<23> has been removed.
...
MapLib:701 - Signal pecl_input_p<23> connected to top level port
pecl_input_p<0> has been removed.
MapLib:701 - Signal pecl_input_n<23> connected to top level port
pecl_input_n<0> has been removed.
The input buffers are instantiated in VHDL like this:
Gen1: for i in 23 downto 0 generate
IBUFDS_inst : IBUFDS generic map (IOSTANDARD => "LVPECL_25")
port map (
O => cmp_in(i), -- Diff_p output (connect
directly to top-level port)
I => pecl_input_p(i), -- Diff_n output (connect
directly to top-level port)
IB => pecl_input_n(i) -- Buffer input
);
end generate Gen1 ;
and in the constraint file it is specified that:
NET "pecl_input_p<0>" LOC = "p57" | IOSTANDARD = LVPECL_25 ;
NET "pecl_input_n<0>" LOC = "p58" | IOSTANDARD = LVPECL_25 ;
...
The "cmp_in" output of the buffer is used and has load connected to
it, that is not removed from optimization steps. The problem seems to
be buffer-related, when I remove the buffer the inputs are not removed
by ISE. I also tried instantiating the buffer with following way,
getting the same results:
Gen1: for i in 23 downto 0 generate
buffer_array : IBUFDS_LVPECL_25 port map
(I=>input_p(i),IB=>input_n(i) , O=>input_int(i));
end generate Gen1 ;
Any ideas?
Thank you in advance for your time,
George
Article: 149432"cdb" <claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote in message news:Cs2dnSXM2OBvx1jRnZ2dnUVZ_rudnZ2d@giganews.com... > Hi everybody, > I'm designing a VHDL testbench for a VHDL module. > > I have to generate values to be written into a 32 bit register of my > module. > I decided tu use integer variables to compose my data and than convert > them > to std_logic_vector to perform the write operation on the module. > > The issue is that I discovered that VHDL > integer range is from -2147483647 to 2147483647, > that is to say 0x80000000 integer is not supported. > > Is there any way to work out this limitation without using directly > std_logic_vector type? > > Thank you in advance for any help > > Claudia > Perhaps I'm missing the point, but I would have used x"8000_0000" With the underscore being optional.Article: 149433
Does anyone know if it is possible to drive a GTP tile with a clock from a PLL. I want to use the GREFCLK option and it says in the user guide that the CLKIN pin should be driven using a BUFG. I have done this with the input of the BUFG from a PLL but when I try to map the design I get the following error. PhysDesignRules:2270 - Block U_gtp_sata/tile0_v5_gtpwizard_v2_1_i/gtp_dual_i (GTP_DUAL_X0Y3) needs GTP_DUAL_X0Y2 instantiated: When using a GTP/GTX with a REFCLK coming from an IBUFDS element near another GTP/GTX, each GTP in between the source and destination must be instantiated in the correct manner (See AR 33473). If you don't instantiate these other GTP tiles the software tools will route the REFCLK correctly, but the design may not work in hardware. It may be that you can only drive the BUFG from an external clock but I would be interested if anyone knows this for certain. Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149434
Just do a quick search in google for MapLib:701 I found quite a few people who have had the same problem Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149435
I don't know if PLL is allowed as a clock source, but the error you see seems to me unrelated. It simply says that the tiles in path of the clock have to be powered up, or else there is no guarantee that they will pass clock properly. With regards to using PLL, look at jitter/phase noise requirements of the GTP/GTX and see if they can be met when the PLL is used. /Mikhail "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote in message news:96adnflEw6DZAFjRnZ2dnUVZ_vudnZ2d@giganews.com... > Does anyone know if it is possible to drive a GTP tile with a clock from a > PLL. I want to use the GREFCLK option and it says in the user guide that > the CLKIN pin should be driven using a BUFG. I have done this with the > input of the BUFG from a PLL but when I try to map the design I get the > following error. > > PhysDesignRules:2270 - Block > U_gtp_sata/tile0_v5_gtpwizard_v2_1_i/gtp_dual_i (GTP_DUAL_X0Y3) needs > GTP_DUAL_X0Y2 instantiated: When using a GTP/GTX with a REFCLK coming from > an IBUFDS element near another GTP/GTX, each GTP in between the source and > destination must be instantiated in the correct manner (See AR 33473). If > you don't instantiate these other GTP tiles the software tools will route > the REFCLK correctly, but the design may not work in hardware. > > It may be that you can only drive the BUFG from an external clock but I > would be interested if anyone knows this for certain. > > Thanks > > Jon > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 149436
On Sat, 23 Oct 2010 01:33:00 -0500, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: >Hi muzaffar >i have gone through the datasheet and can't seem to figure out the >component values that's why i asked for help =) . Can you kindly tell me, >currently i am using the app note configuration of 2A, app note's link is >given in the first thread. Mosfets and diodes look OK for 3A. You need to change the 15uH inductor. Try the DO3316P-472 from the list. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 149437
I think the error is just a generic error message. I'm not too bothered about jitter at the moment as I wont be using the GREFCLK in the final design. The board I am using doesnt have a clk on the GTP clk inputs so I needed to find another way to get a clk. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149438
On Oct 23, 5:14=A0am, Arne <a...@pagelnet.de> wrote: > Hello, > > following situation: > > I have a board with a 10MHz oscillator which supplies a microcontroller a= nd a spartan3e. > > The spartan uses a DCM to generate 50MHz for a global clock. > The Controller has also a PLL to generate 50Mhz internal. > > Both, the controller and the spartan are connected over a parallel bus, t= he bus interface has a > clock output (configured to 50MHz, permanently on). > These clock signal is connected to a LHCLK input of the spartan. > > The simplest way for me would be to use the supplied bus clock at LHCLK-P= in as global clock for my > design, but I get warnings when I try this. > I can't feed a DCM with a LHCLK signal, at least I wasn't able to do this= . > > Because the clocks have the same source, I could try to synchronize them. > I tried to use the bus clock as feedback for the DCM, but when I Try this > I get errormessages like "Place:1012 - A clock IOB / DCM component pair h= ave been found that are not > placed at an optimal clock IOB / DCM site pair." > > Another solution I think about is to use the bus clock to feed the bus-in= terface and then building a > fifo for clock domain crossing, but this is more complex. > > Any suggestion what would be the best way to solve this problem? > > regards > =A0 =A0Arne You will never get the two 50MHz clocks to synchronize. If it were me, I would ignore the 10MHz into the FPGA, and use the 50MHz from the controller for _everything_. RKArticle: 149439
On Oct 25, 6:27=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > If they represent non-numeric quantites (bitmasks, CPU instructions, char= acters) > then declare them as such, e.g. std_logic_vector constants. > Using integers for non-numeric quantites only sows confusion about the in= tent of > your design. > I generally agree, unless simulation performance is paramount, due to the operations required, and/or the amount of memory required by the simulation. Sometimes a little less obvious intent is worth it for huge simulation performance gains. And for anyone who's been around low level embedded SW, the techniques will feel right at home. Bit-wise logical operations (AND/OR/NOT/XOR, etc.) are not supported on integers, so there is no way to use built-in processor instructions for simulating these even if you wrote your own package to implement them. Otherwise, extracting or shifting bit-fields is simple (*, /, mod by powers of two), much faster executing (simulating) than with vector based quantities, and simulation memory requirements are drastically reduced too. AndyArticle: 149440
On 10/25/2010 06:53 AM, cdb wrote: >> On Mon, 25 Oct 2010 05:24:50 -0500, "cdb" >> <claudia.de-bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote: >> >>> Hi everybody, >>> I'm designing a VHDL testbench for a VHDL module. >>> >>> I have to generate values to be written into a 32 bit register of my >>> module. >>> I decided tu use integer variables to compose my data and than convert > them >>> to std_logic_vector to perform the write operation on the module. >>> >>> The issue is that I discovered that VHDL >>> integer range is from -2147483647 to 2147483647, >>> that is to say 0x80000000 integer is not supported. >> >> It's worse than that. The integer range is guaranteed to cover that range, > but >> is not necessarily limited to it. >> >> So some implementations allow 0x80000000 while others do not. That means > you can >> simulate in Modelsim, and find out later that your code will not > synthesise, or >> simulate in Xilinx ISE simulator. >> >>> Is there any way to work out this limitation without using directly >>> std_logic_vector type? >> >> Use the numeric_std library, either signed or unsigned, if your register > values >> represent numeric types. >> >> If they represent non-numeric quantites (bitmasks, CPU instructions, > characters) >> then declare them as such, e.g. std_logic_vector constants. >> Using integers for non-numeric quantites only sows confusion about the > intent of >> your design. >> >> - Brian >> > > Thanks Brian, > I need to use 0x80000000 integer only in non-synthesizable code (a > testbench), and I decided to adopt integers at high level of my testbench > , > because at the beginning it seemed more flexible to me ( random number > generation etc. ..) > > and I'm using Modelsim. > > I verified that in fact -2**31 is supported and it's than converted in the > proper std_logic_vector ( I got confused because I was using quartus > packages too, in order to use the to_string fuction for example,and quartus > staff seems not to support (-2**31) value) > > Modelsim integer extension seems to solve my problems, > but as you rightly noticed, it's not a clear solution: > to express non-numeric quantities ( es values to be written on a 32 bit > control register) as integer I'm forced to use signed value > and consequently a std_logic_vector(TO_SIGNED(...) way of convert them. > > Modelsim positive/natural range seems to be up to (2*31 - 1) ... If you do end up doing something a little 'weird' then comment the heck out of it, to alleviate the confusion you necessarily sow. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 149441
Thomas Stanka <usenet_nospam_valid@stanka-web.de> wrote: > On 25 Okt., 12:24, "cdb" <claudia.de- > bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote: >> The issue is that I discovered that VHDL >> integer range is from -2147483647 to 2147483647, >> that is to say 0x80000000 integer is not supported. > To be precise, 0x80000000 is not necessary supported, which makes it > way more complicated. Each tool might define integer in a way it like > to do it, as long as integer covers _at least_ the range mentioned > above. According to LRM it is valid if a simulator uses 64 bit > integer (or 42 bit). In many high-level languages, constants are not signed. The unary negation operator, -, is applied to a positive constant. In that case, in 32 bits you can't hava a constant -2147483648, but in most cases it can be the result of an expression. It might be that it is unsupported, or implementation dependent, only when written as a literal constant. -- glenArticle: 149442
On 25 =CF=EA=F4, 18:12, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > Just do a quick search in google for MapLib:701 I found quite a few peopl= e > who have had the same problem > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I did that and most of them had the inputs unconnected (no load connected), while one of them that had a similar problem (not with pecl buffers but with another standard) solved it by a different declaration of the buffers, that different declaration is not valid for my case. Any ideas guys? Thank you for your answer JonArticle: 149443
You could try to just create a simple design with 1 buffer driving some logic with an output and see if that works. If it does then try to build up to the design you have and see when you get the error. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 149444
On Oct 25, 12:27=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Thomas Stanka <usenet_nospam_va...@stanka-web.de> wrote: > > On 25 Okt., 12:24, "cdb" <claudia.de- > > bartolomeis@n_o_s_p_a_m.transport.alstom.com> wrote: > >> The issue is that I discovered that VHDL > >> integer range is from -2147483647 to 2147483647, > >> that is to say 0x80000000 integer is not supported. > > To be precise, 0x80000000 is not necessary supported, which makes it > > way more complicated. Each tool might define integer in a way it like > > to do it, as long as integer covers _at least_ the range mentioned > > above. =A0According to LRM it is valid if a simulator uses 64 bit > > integer (or 42 bit). > > In many high-level languages, constants are not signed. > The unary negation operator, -, is applied to a positive constant. > In that case, in 32 bits you can't hava a constant -2147483648, > but in most cases it can be the result of an expression. > > It might be that it is unsupported, or implementation dependent, > only when written as a literal constant. > > -- glen This is the first time I've seen any justification for not including the entire 32 bit two's complement representable range in integer. Interesting... I have a feeling many implementations do not extend the range (as allowed by the LRM) to 32 bit two's complement not because of this, but because they simply did not realize or care that it was not quite 32 bits. However, the way the LRM is written, the bounds of a data type range specification apply equally to constants, signals and variables of that type. Thus an implementation would not be allowed to accept a signal or variable value that is beyond what it would accept for a constant of the same type. The implementation either has to allow it in all three cases, or disallow it in all three cases. AndyArticle: 149445
Andy <jonesandy@comcast.net> wrote: (snip) >> In many high-level languages, constants are not signed. >> The unary negation operator, -, is applied to a positive constant. >> In that case, in 32 bits you can't hava a constant -2147483648, >> but in most cases it can be the result of an expression. >> It might be that it is unsupported, or implementation dependent, >> only when written as a literal constant. > This is the first time I've seen any justification for not including > the entire 32 bit two's complement representable range in integer. > Interesting... I have a feeling many implementations do not extend the > range (as allowed by the LRM) to 32 bit two's complement not because > of this, but because they simply did not realize or care that it was > not quite 32 bits. It is at least true for C and Fortran in places where expressions are allowed. (The Fortran DATA statement allows for a signed constant, as expressions are not allowed.) > However, the way the LRM is written, the bounds of a data type range > specification apply equally to constants, signals and variables of > that type. Thus an implementation would not be allowed to accept a > signal or variable value that is beyond what it would accept for a > constant of the same type. The implementation either has to allow it > in all three cases, or disallow it in all three cases. It isn't so obvious for verilog, but both C and Fortran allow for sign magnitude and ones complement. ANSI C requires binary, but Fortran allows for any base greater than one. Does verilog allow for a sign magnitude or ones complement integer? -- glenArticle: 149446
Hi,
I have a very simple operator problem in VHDL. I try to compare some
inputs with logical operators but get an error message...
entity test is
port (
paddr : in std_logic_vector(15 downto 0);
psel : in std_logic;
penable : in std_logic;
pwrite : in std_logic
);
end entity test;
signal wrfifo_full : std_logic;
process (paddr, psel, penable, pwrite, wrfifo_full) is
begin
if (((paddr(8 downto 2) = "1000000")) and (psel and penable) and
(pwrite and not(wrfifo_full))) then
dt_fifo_wr_i <= '1';
else
dt_fifo_wr_i <= '0';
end if;
end process;
Unfortuantely, I get then the following error message:
if (((paddr(8 downto 2) = "1000000")) and (psel and penable) and
(pwrite and not(wrfifo_full))) then | ncvhdl_p:
|
*E,OPTYMM (hdl/vhdl/test.vhd,523|43): operator argument type mismatch
87[4.3.3.2] 93[4.3.2.2] [7.2]
Anyway sees what is the problem?
Cheers
Article: 149447On 10/25/2010 3:11 PM, Giorgos_P wrote: > MapLib:701 - Signal pecl_input_p<23> connected to top level port > pecl_input_p<0> has been removed. > MapLib:701 - Signal pecl_input_n<23> connected to top level port > pecl_input_n<0> has been removed. > Hi George, This section might be a clue. It seems to be trying to attach bit 23 to bit 0. Dunno why. FWIW, my code uses 0 to 15 , rather than 15 downto 0, but that shouldn't make any difference. Are you sure LVPECL inputs are allowed on that bank? Anything else attached to that bank that you haven't constrained the I/O type? Does it work with LVDS inputs? Good luck, Syms.Article: 149448
Martin <sportfreund@gmx.at> writes:
> Unfortuantely, I get then the following error message:
>
> if (((paddr(8 downto 2) = "1000000")) and (psel and penable) and
> (pwrite and not(wrfifo_full))) then | ncvhdl_p:
(psel and penable) returns std_logic
(pwrite and not(wrfifo_full)) returns std_logic
You need to do
if ((paddr(8 downto 2) = "1000000") and
((psel and penable) = '1') and
((pwrite and not(wrfifo_full)) = '1')) then
//Petter
--
.sig removed by request.
Article: 149449On Tue, 26 Oct 2010 03:14:34 -0700 (PDT), Martin <sportfreund@gmx.at> wrote: >Hi, > >I have a very simple operator problem in VHDL. I try to compare some >inputs with logical operators but get an error message... > >entity test is > port ( > paddr : in std_logic_vector(15 downto 0); > psel : in std_logic; > penable : in std_logic; > pwrite : in std_logic > ); >end entity test; > >signal wrfifo_full : std_logic; > >process (paddr, psel, penable, pwrite, wrfifo_full) is >begin > if (((paddr(8 downto 2) = "1000000")) and (psel and penable) and >(pwrite and not(wrfifo_full))) then > dt_fifo_wr_i <= '1'; > else > dt_fifo_wr_i <= '0'; > end if; >end process; > >Unfortuantely, I get then the following error message: > >if (((paddr(8 downto 2) = "1000000")) and (psel and penable) and >(pwrite and not(wrfifo_full))) then | ncvhdl_p: > >| >*E,OPTYMM (hdl/vhdl/test.vhd,523|43): operator argument type mismatch >87[4.3.3.2] 93[4.3.2.2] [7.2] > >Anyway sees what is the problem? "and" operates on booleans to provide a boolean result. or "and" operates on std_logic to provide a std_logic result. but "if" requires a boolean expression... You have written if <bool expression> and <std_logic expression> then... The least effort solution is to write if <bool expression> and (<std_logic expression> = '1') then... and this may be the best solution here. But if there are a lot of these in your code, it suggests you are fighting the type system rather than using it. Strong typing is your friend... if you can learn to get along. One trick for learning to get along: The type system allows overloading by function result, so you can overload "and" with your own function, e.g. taking two std_logic arguments and returning a boolean. I don't see any way of creating ambiguities or dangers doing this. A package of functions like these can perhaps simplify and clarify your code. - Brian
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