Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 127725

Article: 127725
Subject: Re: Cyclone II short-circuit failure mode
From: Andy Botterill <andy@plymouth2.demon.co.uk>
Date: Sun, 06 Jan 2008 14:42:34 +0000
Links: << >>  << T >>  << A >>
edaudio2000@yahoo.co.uk wrote:

> 
> I am not too convinced this was a manufacturing or solder short
> problem.
> The FPGA chip is fed from a 100mA limited power supply, and cannot
> imagine how any combination
> of solder shorts would have caused the chip to fuse so solidly
> internally.

There are failure analysis companies around. We have used maser.
You will probably have to send them a good and a bad device plus some 
socketted fan out pcb.
> 
> In any case, the board had been working for a while when it failed
> suddenly during tests.
> So I imagine some form of external "spanner in the works"  may have
> been responsible.
> There is a 5V line on the board (high current capacity) but that's
> all.
> 
> I suspect an ESD failure might have caused the chip to stop working,
> or make some of the I/O pins
> become not operational, that's all.

Curve tracing supplies and signals will show which if any pins have been 
damaged by ESD.
> 
> The puzzle is that the chip went "fused short" i.e. less than an ohm
> between the 3v3 vccio4 and gnd (The 1V5 supply is OK).
> 
> And quite a solid short it is,  If I apply 1V to vccio  the chip draws
> a lot of current and gets warm..

Diagnosing to an on device issue can be done by removing the package 
surface exposing the passivation layer of the silicon. Cove the 
passivation layer with liquid crystal. Apply voltage and watch for 
changes of colour under a microsocope.

It is a tricky business at the best of times.
> 
> This is all very odd...It would be interesting to know what might have
> caused this.
> 
> Regards
> 
> Ted
> 
> 
> 
> 
> 
> 

Article: 127726
Subject: Re: How to connect a LED with a clock?
From: Vagant <vladimir.v.korostelev@rambler.ru>
Date: Sun, 6 Jan 2008 07:30:47 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 6, 4:36=A0pm, MikeShepherd...@btinternet.com wrote:
> >Thank you very much. I just wonder whether each LED of the board is
> >physically connected to some pin of FPGA or not?
>
> FInd the circuit diagram ("schematic"). =A0Then look at it. =A0If it
> doesn't make sense, you first need to learn some basic electronics,
> because a lot of the literature you'll meet as you proceed will assume
> that you have that knowledge.
>
> Mike

Thank you, I have found the schematics at Xilinx Web Site. I am really
surprised that I had not noticed this file before. Many thanks!

Article: 127727
Subject: Re: Ethernet on recent FPGAs
From: posedge52@yahoo.com
Date: Sun, 6 Jan 2008 08:34:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 6, 2:54 am, John McCaskill <jhmccask...@gmail.com> wrote:
> <snip>
>
> > 1) Buy a batch of unique addresses (which isn't cheap and involves
> > administrative hassle).  If you're designing a LAN for an airliner I'm
> > going to fly on, I'd like you to use this method.
>
> Mike,
>
> While I agree that the MAC ID space is so large that the chance of a
> collision for a random address is very low, I do not agree with that
> statement.  Buying a range of unique addresses is cheap and easy, and
> no administrative hassle is involved.
>
> The IEEE administers MAC IDs, and you can buy a range of them for a
> one time fee online.  I bought the OUI package online with a credit
> card and have no regrets. Take a look at:
>
> http://standards.ieee.org/regauth/oui/index.shtmlhttp://standards.ieee.org/regauth/oui/pilot-ind.htmlhttp://standards.ieee.org/regauth/oui/forms/
>
> You can buy a 4K block of MAC IDs for $500 USD, or a 2^24 block of IDs
> for $1650.  That is lost in the noise for producing a commercial
> product.
>
> This is a far better deal than I get from the PCI SIG where I have to
> pay every year to retain my vendor ID. For the MAC IDs, I pay once and
> it is mine for ever.
>
> While I am a small business owner and complain about every penny
> spent, I think that the IEEE gives me a fair deal.

Another option is to let the customer set the ID through some
configuration option. That way collisions can be avoided post
manufacture. And the administrator can't claim that you used an ID
"without permission".

Article: 127728
Subject: Re: MPMC On EDK
From: Daniel Koethe <dkoethe@nospam-web.de>
Date: Sun, 06 Jan 2008 17:44:35 +0100
Links: << >>  << T >>  << A >>
The MPMC DDR-Interface is based on the MIG-Memory Controller. Download 
at http://www.xilinx.com/products/ipcenter/MIG.htm the "User Guide" 
(ug086.pdf). See page 331/332: Generic Memory Interface Guidelines.

Daniel



ratemonotonic schrieb:
> Hi All ,
> 
> I am trying to interface microblaze with a Micron DDR SDRAM
> (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am
> running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O
> and DDR_DQS_DIV_I , else I get errors , it also states that these
> should be connected in for spartan 3.
> 
> The problem is that there is not much documentation about these port
> lines in the MPMC data sheet. Has anyone used this? does any one know
> how to connect these lines up?
> 
> thanks in advance
> 
> BR
> rate

Article: 127729
Subject: Compilation of Plasma SW under Linux
From: Wojciech Zabolotny <wzab@ise.pw.edu.pl>
Date: Sun, 6 Jan 2008 17:08:47 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi All,

I have previously send this message to comp.arch.embedded, but probably it
was "NTG", as it is more associated with the soft CPU on FPGA problem.
Therefore I try once (the last one ;-) ) again in the comp.arch.fpga


I have successfully compiled the Plasma soft CPU for my Xilinx Spartan 3E
Starter Kit (the version of Plasma core
http://www.opencores.org/projects.cgi/web/mips/overview
contains the top entity and UCF needed for this board).

However I was not able to generate my own software for this CPU.
The provided tools (
http://www.opencores.org/projects.cgi/web/mips/gccmips_elf.zip,
http://www.opencores.org/projects.cgi/web/mips/tools_bin.zip,
http://www.opencores.org/projects.cgi/web/mips/gmake.zip
)
are "Windows-only" and unfortunately do not run under wine emulator.

I have changed the makefile to make use of the mips-linux-gnu-gcc
or mipsel-linux-gnu-gcc packages (available from
http://buildd.emdebian.org/debian/ )

It was also necessary to replace some backslashes with slashes.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
# Customize for Linux                                                          
CC_X86 = gcc -Wall -O -g                                                        
CP = cp                                                                        
RM = rm -rf                                                                    
#BIN_MIPS = ../../mips/sde/bin                                                  
VHDL_DIR = ../vhdl                                                              
#GCC_MIPS  = mipsel-linux-gnu-gcc $(CFLAGS)                                    
#AS_MIPS   = mipsel-linux-gnu-as                                                
#LD_MIPS   = mipsel-linux-gnu-ld                                                
#DUMP_MIPS = mipsel-linux-gnu-objdump                                          
GCC_MIPS  = mips-linux-gnu-gcc $(CFLAGS)                                        
AS_MIPS   = mips-linux-gnu-as                                                  
LD_MIPS   = mips-linux-gnu-ld                                                  
DUMP_MIPS = mips-linux-gnu-objdump                                              

# Customize for Windows                  
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

To make sources compiling I had to add the redefiniton
of strncat2 to the rtos.h file:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
#define strcpy     strcpy2  //don't use intrinsic functions                    
#define strcat     strcat2                                                      
#define strncat     strncat2 // <= added by WZab                                                  
#define strcmp     strcmp2                                                      
#define strlen     strlen2    
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Unfortunately, even after this adjustments, there are still problems
after "make rtos" I get the following messages:

mips-linux-gnu-ld: boot.o: warning: linking PIC files with non-PIC files

../tools/convert_bin.exe
test.axf -> code.txt & test.bin
Entry=0x10000c50 length=0=0x0

I can try to force mips-linux-gnu-as to generate the PIC file by
adding the "-KPIC" option, but then I get the following warning:

mips-linux-gnu-as -KPIC -o boot.o ../tools/boot.asm
../tools/boot.asm: Assembler messages:
../tools/boot.asm:35: Warning: No .cprestore pseudo-op used in PIC code
../tools/boot.asm:85: Warning: No .cprestore pseudo-op used in PIC code

Anyway the convert_bin complains as before.

So I have two questions:
1) How to avoid the problem with PIC code?
2) Is it possible to generate the ROM contents with the standard tool like
   mips(el)-linux-gnu-objcopy ?
   Or how to fix the convert to work under linux?
-- 
TIA & Regards,
Wojciech M. Zabolotny


Article: 127730
Subject: Re: MPMC On EDK
From: ratemonotonic <niladri1979@gmail.com>
Date: Sun, 6 Jan 2008 09:30:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On 6 Jan, 16:44, Daniel Koethe <dkoe...@nospam-web.de> wrote:
> The MPMC DDR-Interface is based on the MIG-Memory Controller. Download
> athttp://www.xilinx.com/products/ipcenter/MIG.htmthe "User Guide"
> (ug086.pdf). See page 331/332: Generic Memory Interface Guidelines.
>
> Daniel
>
> ratemonotonic schrieb:
>
> > Hi All ,
>
> > I am trying to interface microblaze with a Micron DDR SDRAM
> > (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am
> > running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O
> > and DDR_DQS_DIV_I , else I get errors , it also states that these
> > should be connected in for spartan 3.
>
> > The problem is that there is not much documentation about these port
> > lines in the MPMC data sheet. Has anyone used this? does any one know
> > how to connect these lines up?
>
> > thanks in advance
>
> > BR
> > rate

Hi Daniel ,

Thanks for the links the doc looks good and I am going through it now.
Is the MPMC suitable to interface with asynchronous DDR SDRAMS? i.e.
the reference board I am using has Micron MT46V16M16FG-75 16Mx16 part
which takes min 75mhz clock. the microblaze on the board is running at
50 Mhz, but the board has 75Mhz clock. In the original design an OPB
DDR SBRAM controller was used in which there was seperate control for
the DDR clock inputs , but MPMC only seems to take the system clock as
an input which is my case is 50 Mhz. How do I produce an 75 Mhz DDR
clock from MPMC?

Thanks very much ,
BR
Rate

Article: 127731
Subject: Re: Spartan 3E Sarter Kit Ethernet
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 06 Jan 2008 19:06:47 GMT
Links: << >>  << T >>  << A >>
Arlet Ottens <usenet+5@c-scape.nl> wrote:

>posedge52@yahoo.com wrote:
>> On Jan 5, 10:08 pm, "Pavel.Schu...@gmail.com"
>> <Pavel.Schu...@gmail.com> wrote:
>>> Hello.
>>> Would you please to get me some information about how can i realize
>>> UDP transmition with Spartan 3E Starter Kit? Can i use IP supplied
>>> with EDK in conjunction with Microblaze. Can I solve the problem
>>> without using Microblaze?
>> 
>> You transmitt ethernet packets by waiting for the PHY transmitt clock
>> to go low "always @(negedge E_TX_CLK)".  Then set E_TX_EN=1 and
>> E_TXD[3:0]=first nibble. Then for every event set next nibble. Once
>> you have supplied all data. Set E_TX_EN=0 to complete packet. You have
>> to wait 24 cycles at 100M before sending a new one.
>> The nibbles shall be 555555555555555D - packet data - crc32. Crc32 is
>> calculated from packet data only.
>
>If it is acceptable to hardwire the IP and MAC addresses, then a fairly 
>straightforward state machine, in combination with a prepared header can 
>transmit UDP frames. This can be a reasonable solution for a quick hack 
>on a lab.
>
>For local networks it is also reasonably safe to omit the UDP checksum. 
>This can be done by setting it to an all-zeroes value. By doing so, you 
>can avoid making an extra pass over the data.

Actually, you can calculate the CRC on the fly because it is
transmitted last.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 127732
Subject: Re: Spartan 3E Sarter Kit Ethernet
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Sun, 06 Jan 2008 20:28:40 +0100
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> Arlet Ottens <usenet+5@c-scape.nl> wrote:
> 
>> If it is acceptable to hardwire the IP and MAC addresses, then a fairly 
>> straightforward state machine, in combination with a prepared header can 
>> transmit UDP frames. This can be a reasonable solution for a quick hack 
>> on a lab.
>>
>> For local networks it is also reasonably safe to omit the UDP checksum. 
>> This can be done by setting it to an all-zeroes value. By doing so, you 
>> can avoid making an extra pass over the data.
> 
> Actually, you can calculate the CRC on the fly because it is
> transmitted last.
> 

The Ethernet layer CRC-32 is transmitted last, but the UDP checksum is 
in the header.

Beware that omitting the UDP checksum removes protection against data 
corruption inside the FPGA, e.g. a bug in the transmit path before the 
CRC-32 is applied.







Article: 127733
Subject: Re: MPMC On EDK
From: Daniel Koethe <dkoethe@nospam-web.de>
Date: Sun, 06 Jan 2008 22:25:13 +0100
Links: << >>  << T >>  << A >>
ratemonotonic schrieb:
> On 6 Jan, 16:44, Daniel Koethe <dkoe...@nospam-web.de> wrote:
>> The MPMC DDR-Interface is based on the MIG-Memory Controller. Download
>> athttp://www.xilinx.com/products/ipcenter/MIG.htmthe "User Guide"
>> (ug086.pdf). See page 331/332: Generic Memory Interface Guidelines.
>>
>> Daniel
>>
>> ratemonotonic schrieb:
>>
>>> Hi All ,
>>> I am trying to interface microblaze with a Micron DDR SDRAM
>>> (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am
>>> running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O
>>> and DDR_DQS_DIV_I , else I get errors , it also states that these
>>> should be connected in for spartan 3.
>>> The problem is that there is not much documentation about these port
>>> lines in the MPMC data sheet. Has anyone used this? does any one know
>>> how to connect these lines up?
>>> thanks in advance
>>> BR
>>> rate
> 
> Hi Daniel ,
> 
> Thanks for the links the doc looks good and I am going through it now.
> Is the MPMC suitable to interface with asynchronous DDR SDRAMS? i.e.
> the reference board I am using has Micron MT46V16M16FG-75 16Mx16 part
> which takes min 75mhz clock. the microblaze on the board is running at
> 50 Mhz, but the board has 75Mhz clock. In the original design an OPB
> DDR SBRAM controller was used in which there was seperate control for
> the DDR clock inputs , but MPMC only seems to take the system clock as
> an input which is my case is 50 Mhz. How do I produce an 75 Mhz DDR
> clock from MPMC?

The MPMC can not produce a 75Mhz clock from a 50 Mhz source. But the 
MPMC supports 1:2 System/PIM clock and memory clock.

See at page 50 of Datasheet MPMC (DS643) near "<PIM>_Clk".

For example you have a 50Mhz source clock, use clk0 (system clock) and 
clk2x output of a DCM to produce the 100Mhz memory clock. Do not forget 
to connect clk0 and clkfb to assure zero phase offset.


> 
> Thanks very much ,
> BR
> Rate

Article: 127734
Subject: Re: Ethernet on recent FPGAs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 06 Jan 2008 13:46:40 -0800
Links: << >>  << T >>  << A >>
John McCaskill wrote:

> While I agree that the MAC ID space is so large that the chance of a
> collision for a random address is very low, I do not agree with that
> statement.  Buying a range of unique addresses is cheap and easy, and
> no administrative hassle is involved.

There is a story that in the beginnings of ethernet using random 48 bit
MAC addresses was considered, but rejected because of the (small)
probability of two accidentally choosing the same address.

As I understand it, in the current system there have been devices
produced that accidentally had the same address.  As the current system
involves humans, such as programming ROMs and installing them in cards,
there is a relatively high probability of accidents.

Choosing a random 46 bit number with the local administration bit
on and the multicast bit off might not be so bad.

-- glen


Article: 127735
Subject: Re: conversion problem
From: FPGA <FPGA.unknown@gmail.com>
Date: Sun, 6 Jan 2008 14:13:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 6, 8:40=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Sat, 5 Jan 2008 14:04:04 -0800 (PST),
>
> FPGA <FPGA.unkn...@gmail.com> wrote:
> >function int_to_float (x: signed) return signed
>
> >I wish to convert the input signed vector to Single precision 32 bit
> >floating point number. I do not know what the input string length is
> >going to be. Output string length is fixed.
>
> [...]
>
> >I am really confused.
>
> So it would seem. =A0Normally I'm fairly impatient with people
> who bring standard homework problems here, but at least you've
> been honest and you've made some suggestions. =A0So I'll try to
> make some suggestions in return.
>
> I think you may be a little confused about the way numbers
> are represented in binary. =A0Let's start by looking at a
> really simple *unsigned* integer - try 11:
>
> =A0 11 decimal =3D=3D 001011 binary
>
> Obviously it doesn't matter how many leading zeros you have,
> so I've used a total of 6 bits just for the example.
>
> Each binary digit represents a power of 2:
>
> =A0 11 decimal =3D =A0 =A00 =A0 =A00 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[32] [16] [8] =A0[4] =A0[2] =A0[1]
>
> I guess you know that. =A0Now let's go to SIGNED
> numbers. =A0There are many, many possible ways to
> represent signed values in binary, but the method
> that's by far the most common for integers, and is
> used by "signed" data in the numeric_std package, is
> twos complement. =A0In this form, the MOST SIGNIFICANT
> bit is negated:
>
> =A0+11 decimal =3D =A0 =A00 =A0 =A00 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [-32] [16] [8] =A0[4] =A0[2] =A0[1]
> =A0-30 decimal =3D =A0 =A01 =A0 =A00 =A0 =A00 =A0 =A00 =A0 =A01 =A0 =A00
>
> And, in general, any signed number less than 0 will
> have its most significant bit set to 1.
>
> For floating-point representation, however, most people
> (you included) use SIGN-AND-MAGNITUDE representation.
> In this form, we keep one bit - the sign bit - as a
> flag to say whether the number is negative or positive.
> Otherwise, we represent the number as a positive number:
>
> =A0+11 decimal =3D =A0 =A00 =A0 =A0 0 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[SIGN] =A0[16] [8] =A0[4] =A0[2] =A0[1]
> =A0-11 decimal =3D =A0 =A01 =A0 =A0 0 =A0 =A01 =A0 =A00 =A0 =A01 =A0 =A01
>
> OK, so that's integer representation sorted out. =A0Now
> let's think about floating-point.
>
> Have you looked at
> =A0http://en.wikipedia.org/wiki/IEEE_754#Single-precision_32_bit
>
> ??? =A0It seems to me to be splendidly clear.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Thank you Janathan. Your explaination helped a lot.

I would like to know the bit width of my result(signed bit stream
"interpreted as integer") when i convert single precision number 32 -
bit to a signed output(integer range). I understand that in worst
case, iwould require 32 bit register to represent all possible
integers. Can we instead make this output of variable width(depending
on magnitude of input) than keeping it 32 bit. Which would be the best
approach?

Your advise is appreciated

Article: 127736
Subject: Xilinx MIG onm Solaris
From: Michael Laajanen <michael_laajanen@yahoo.com>
Date: Sun, 06 Jan 2008 23:14:41 +0100
Links: << >>  << T >>  << A >>
Hi,

I can't locate MIG in coregen on Solaris 9.2 and ip update 2?

Is it only on Linux and Windows?

/michael

Article: 127737
Subject: Re: Ethernet on recent FPGAs
From: nico@puntnl.niks (Nico Coesel)
Date: Mon, 07 Jan 2008 00:31:51 GMT
Links: << >>  << T >>  << A >>
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

>John McCaskill wrote:
>
>> While I agree that the MAC ID space is so large that the chance of a
>> collision for a random address is very low, I do not agree with that
>> statement.  Buying a range of unique addresses is cheap and easy, and
>> no administrative hassle is involved.
>
>There is a story that in the beginnings of ethernet using random 48 bit
>MAC addresses was considered, but rejected because of the (small)
>probability of two accidentally choosing the same address.
>
>As I understand it, in the current system there have been devices
>produced that accidentally had the same address.  As the current system
>involves humans, such as programming ROMs and installing them in cards,
>there is a relatively high probability of accidents.
>
>Choosing a random 46 bit number with the local administration bit
>on and the multicast bit off might not be so bad.

Yes and no. Like others already pointed out, devices need a serial
number anyway. Not just for administration but also to keep track of
devices. So having a fixed number (MAC address) assigned to unit xyz
generally saves a lot of trouble.

Besides, if you are going to generate random MAC addresses you may get
intermittant errors because fixed MAC addresses are expected. Those
kind of errors are the last you want on a network.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 127738
Subject: Re: Ethernet on recent FPGAs
From: andrew@cucumber.demon.co.uk (Andrew Gabriel)
Date: 07 Jan 2008 01:01:31 GMT
Links: << >>  << T >>  << A >>
In article <B_KdnWf0IICN1hzanZ2dnUVZ_t6onZ2d@comcast.com>,
	glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> There is a story that in the beginnings of ethernet using random 48 bit
> MAC addresses was considered, but rejected because of the (small)
> probability of two accidentally choosing the same address.
> 
> As I understand it, in the current system there have been devices
> produced that accidentally had the same address.  As the current system
> involves humans, such as programming ROMs and installing them in cards,
> there is a relatively high probability of accidents.

In the early days, address allocations were notified to
applicants in the order the bits are transmitted in an
ethernet frame on the wire, and a significant number of
the early vendors produced loads of kit using completely
the wrong OUI as a consequence (with the bits in every
octet of the OUI in reverse order).

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

Article: 127739
Subject: Re: conversion problem
From: "KJ" <kkjennings@sbcglobal.net>
Date: Mon, 07 Jan 2008 01:06:22 GMT
Links: << >>  << T >>  << A >>
<snip>

> Thank you Janathan. Your explaination helped a lot.
>
> I would like to know the bit width of my result(signed bit stream
> "interpreted as integer") when i convert single precision number 32 -
> bit to a signed output(integer range).

If you understand how a single precision number is representing in binary 
you would know how many bits you need as well.

> Can we instead make this output of variable width(depending
> on magnitude of input) than keeping it 32 bit.
No.

KJ 



Article: 127740
Subject: MicroBlaze floating point precision issues
From: JD Newcomb <the.jd.in.space@gmail.com>
Date: Sun, 6 Jan 2008 19:06:54 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello, group.

I'm having a heck of a time trying to figure out why my MicroBlaze
implementation is presenting *supposedly* single-precision floating
point values as double-precision values truncated to 32 bits.

Here's what I mean:

float test = 22;   // for example

printf("test = 0x%08x\r\n",test);    // prints   "test = 0x40360000"
printf("test = %d\r\n",test);    // prints    "test = 1077280768"
printf("test = %f\r\n",test);     // prints    "test = 22.000000" or
some precision

22 in single-point floating point (hex) is 0x41B00000, and in double-
precision is 0x4036000000000000. So, truncate the double-precision
value and you have what's printed to the screen. I'm completely
baffled. Am I missing something? A gcc flag? How is this even possible
for a single-precision instruction set?

Article: 127741
Subject: Re: Xilinx MIG onm Solaris
From: "John Schmitz" <a@a>
Date: Sun, 6 Jan 2008 19:25:34 -0800
Links: << >>  << T >>  << A >>
Correct, Linux and Windows only.  The workaround is to run the MIG tool on 
Linux or Windows and transfer the output files over to the Solaris machine 
for integration.

"Michael Laajanen" <michael_laajanen@yahoo.com> wrote in message 
news:5ud26iF1hgf6pU1@mid.individual.net...
> Hi,
>
> I can't locate MIG in coregen on Solaris 9.2 and ip update 2?
>
> Is it only on Linux and Windows?
>
> /michael 



Article: 127742
Subject: Re: MicroBlaze floating point precision issues
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Mon, 07 Jan 2008 13:29:27 +1000
Links: << >>  << T >>  << A >>
Hi,

JD Newcomb wrote:

> I'm having a heck of a time trying to figure out why my MicroBlaze
> implementation is presenting *supposedly* single-precision floating
> point values as double-precision values truncated to 32 bits.
> 
> Here's what I mean:
> 
> float test = 22;   // for example
> 
> printf("test = 0x%08x\r\n",test);    // prints   "test = 0x40360000"
> printf("test = %d\r\n",test);    // prints    "test = 1077280768"
> printf("test = %f\r\n",test);     // prints    "test = 22.000000" or
> some precision
> 
> 22 in single-point floating point (hex) is 0x41B00000, and in double-
> precision is 0x4036000000000000. So, truncate the double-precision
> value and you have what's printed to the screen. I'm completely
> baffled. Am I missing something? A gcc flag? How is this even possible
> for a single-precision instruction set?

If that literally is your test code, GCC might be being a bit too clever 
for you and effectively hard coding the literal '22' as the arg to the 
printf statements.

Try using

   float test = 22.0f;

as the initial assignment for starters.  To force single precision 
constants you need the 'f' suffix, otherwise you burn tragic number of 
cycles doing wasteful double to float conversions.

Also, perhaps specify optimisation level -O0 to gcc, see if that gets 
you anywhere.

Regards,

John




Article: 127743
Subject: Viterbi Decoder
From: sarah.stregel@gmail.com
Date: Sun, 6 Jan 2008 19:54:57 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I am designing a viterbi decoder with r=1/2 and k=7 on fpga but don't
want to design from scratch. Can one share some reference code for
r=1/2 and maybe k=3 etc. which I can use as a base for development.

Thanks,
Sara

Article: 127744
Subject: Re: MicroBlaze floating point precision issues
From: JD Newcomb <the.jd.in.space@gmail.com>
Date: Sun, 6 Jan 2008 20:36:55 -0800 (PST)
Links: << >>  << T >>  << A >>
Thank you, John, for the quick response.

On Jan 6, 10:29 pm, John Williams <jwilli...@itee.uq.edu.au> wrote:
> Hi,
>
>
>
> JD Newcomb wrote:
> > I'm having a heck of a time trying to figure out why my MicroBlaze
> > implementation is presenting *supposedly* single-precision floating
> > point values as double-precision values truncated to 32 bits.
>
> > Here's what I mean:
>
> > float test = 22;   // for example
>
> > printf("test = 0x%08x\r\n",test);    // prints   "test = 0x40360000"
> > printf("test = %d\r\n",test);    // prints    "test = 1077280768"
> > printf("test = %f\r\n",test);     // prints    "test = 22.000000" or
> > some precision
>
> > 22 in single-point floating point (hex) is 0x41B00000, and in double-
> > precision is 0x4036000000000000. So, truncate the double-precision
> > value and you have what's printed to the screen. I'm completely
> > baffled. Am I missing something? A gcc flag? How is this even possible
> > for a single-precision instruction set?
>
> If that literally is your test code, GCC might be being a bit too clever
> for you and effectively hard coding the literal '22' as the arg to the
> printf statements.
>

Well, the above wasn't the code that got me investigating the problem
in the first place, but the results are the same.

> Try using
>
>    float test = 22.0f;
>
> as the initial assignment for starters.  To force single precision
> constants you need the 'f' suffix, otherwise you burn tragic number of
> cycles doing wasteful double to float conversions.

 I'm not using constants in my code that pertains to this particular
issue. I have a function that returns an int, and I typecast it to a
float and store it in the float variable:

float foo;

foo = (float) bar(&tmp);   // tmp is some 32-bit ASCII-like value
that's converted to an integer value... don't worry about it.

bar() in this case would return 22 as an int, and printing the
variable foo results in the same printed statement as my test code
above.

>
> Also, perhaps specify optimisation level -O0 to gcc, see if that gets
> you anywhere.
>
> Regards,
>
> John

No optimizations also get me the same result. Any other ideas?
Compiler flags I'm not seeing? The other question is: is this even
wrong?  I mean, I say it is because calculating the values out by hand
using the IEEE 754 standard shows that the results are wrong. But
using a value like 450.123f in the test code above printed as the 32-
bit truncated double-precision value as 0x40776000 (single-precision
is actually 0x43BB0000). Assuming that the truncation would reduce its
precision, the floating value printed out as 450.122986. [shrug] Maybe
it is right.

Article: 127745
Subject: Re: MicroBlaze floating point precision issues
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Mon, 07 Jan 2008 08:05:37 +0100
Links: << >>  << T >>  << A >>
JD Newcomb wrote:
> Hello, group.
> 
> I'm having a heck of a time trying to figure out why my MicroBlaze
> implementation is presenting *supposedly* single-precision floating
> point values as double-precision values truncated to 32 bits.
> 
> Here's what I mean:
> 
> float test = 22;   // for example
> 
> printf("test = 0x%08x\r\n",test);    // prints   "test = 0x40360000"
> printf("test = %d\r\n",test);    // prints    "test = 1077280768"
> printf("test = %f\r\n",test);     // prints    "test = 22.000000" or
> some precision
> 
> 22 in single-point floating point (hex) is 0x41B00000, and in double-
> precision is 0x4036000000000000. So, truncate the double-precision
> value and you have what's printed to the screen. I'm completely
> baffled. Am I missing something? A gcc flag? How is this even possible
> for a single-precision instruction set?

If you use a "%x" or "%d" argument, printf() will only print a 32-bit 
integer, no matter what you pass as the argument. Any additional bits in 
the argument will just be ignored.

If you want to find out how many bytes are used in the implementation, try:

printf( "float: %d, double %d\n", sizeof(float), sizeof(double) );

If sizeof() returns a value greater than 4 bytes, you may want to try 
printing it as a 64 bit integer argument, using:

printf( "test %llx\n", test );

Note that this isn't guaranteed to produce any meaningful results.


Article: 127746
Subject: Re: MicroBlaze floating point precision issues
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 06 Jan 2008 23:13:00 -0800
Links: << >>  << T >>  << A >>
JD Newcomb wrote:

> float test = 22;   // for example

> printf("test = 0x%08x\r\n",test);    // prints   "test = 0x40360000"
> printf("test = %d\r\n",test);    // prints    "test = 1077280768"
> printf("test = %f\r\n",test);     // prints    "test = 22.000000" or
> some precision

> 22 in single-point floating point (hex) is 0x41B00000, and in double-
> precision is 0x4036000000000000. So, truncate the double-precision
> value and you have what's printed to the screen. I'm completely
> baffled. Am I missing something? A gcc flag? How is this even possible
> for a single-precision instruction set?

That is C.

C always converts (float) to (double) before passing it to a
varargs function.  %f expects a double, not a float, as it will
always be converted before the call.

try:
printf("test = 0x%08x\r\n",*(int*)&test);

(assumes sizeof(float)==sizeof(int), but you were already
assuming that.)

-- glen


Article: 127747
Subject: Re: Xilinx, How to generate PAD file, from the UCF file
From: Goli <togoli@gmail.com>
Date: Sun, 6 Jan 2008 23:15:42 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi
Jim,

Thanks a lot for the link. I really found this tool very useful.

Kevin,

thanks for the reply. I know I can do that but I was looking for a
simpler alternative.

--
Goli

Article: 127748
Subject: Re: What does this do ?
From: backhus <nix@nirgends.xyz>
Date: Mon, 07 Jan 2008 08:24:42 +0100
Links: << >>  << T >>  << A >>
iqbalmuh@hotmail.co.uk schrieb:
> Hi,
> 
> Can anyone tell me what this bit of code is doing ?
> 
> -- declarations
> -------------------------------------------------------------------------------------------
> signal phase	:    std_logic_vector(6 downto 0);
> 
> type  INTEGER_ARRAY is array ( natural range <> ) of integer;
> 
> constant  NUMERATOR : INTEGER_ARRAY(7 downto 0)	:= (7,30,7,7, 30, 30,
> 30,30);
> 
> variable phase_next : std_logic_vector(6 downto 0);
> --------------------------------------------------------------------------------------------
> 
> -- **** problem code **********
> 
> phase_next := phase + NUMERATOR(conv_integer(std));
> 
> Obviously the conv_integer(std) part of the code is being used to
> access the array NUMERATOR but I don't understand exactly how since no
> number value is being specified to key into the array
> ie. what is the value of 'std' that is being converted to an integer
> by the function 'conv_integer' ?
> 
> Thanks
Hi,
just two guesses:
1.) there's a port named std in the entity.
2.) your code snippet is just wrong in that line (copy & paste error or 
uncompleted template)

Have a nice synthesis
   Eilert

Article: 127749
Subject: Re: Compilation of Plasma SW under Linux
From: Steven Derrien <sderrienREMOVE@irisa.fr>
Date: Mon, 07 Jan 2008 09:16:00 +0100
Links: << >>  << T >>  << A >>
Hello,

I'd suggest that you try compiling your own mips gcc cross-compiler on 
your linux machine, using as target *mipsel-elf* (I am using it for 
Plasma).

Below is a makefile that should automate most of the job (beware of 
wrapped lines).

Hope it can help.

Steven


GCC_VER=gcc-4.0.2
BINUTILS_VER=binutils-2.16.1
GDB_VER=gdb-6.6
INSIGHT_VER=insight-6.6
TARGET =  mipsel
INSTALL_DIR= /opt/mipsic/

all:
	@echo "## GNU SDK builder (binutil-gcc-gdb) for target machine $(TARGET) "
	@echo "  1) Make sure that Makefile variable INSTALL_DIR shall point to 
an *existing* installation directory"
	@echo "  2) Create a new environment variable MIPSIC and set its value 
to $(INSTALL_DIR)"
	@echo "  3) Check that your PATH environmenet variable points to 
$(INSTALL_DIR)/bin "
	@echo "  4) Run make build_sdk"
	
insight  : $(INSTALL_DIR)/bin/$(TARGET)-elf-insight

binutils : $(INSTALL_DIR)/bin/$(TARGET)-elf-ar
gdb 	 : $(INSTALL_DIR)/bin/$(TARGET)-elf-gdb
gcc 	 : $(INSTALL_DIR)/bin/$(TARGET)-elf-gcc

utils	 : 	$(INSTALL_DIR)/bin/bin2mif \
			$(INSTALL_DIR)/bin/bin2hex
#			$(INSTALL_DIR)/bin/hex2mif \
# 			$(INSTALL_DIR)/bin/elf2bin \



build_sdk : \
	$(INSTALL_DIR)/bin/$(TARGET)-elf-gcc \
	$(INSTALL_DIR)/bin/$(TARGET)-elf-gdb \
	$(INSTALL_DIR)/bin/$(TARGET)-elf-insight \


$(INSTALL_DIR) :
	mkdir -p $(INSTALL_DIR)
	export PATH=$PATH:$(INSTALL_DIR)/bin


#
# Binutils	
#
build :
	-mkdir build

$(BINUTILS_VER).tar.bz2 :
	@echo Downloading $(BINUTILS_VER)
	@wget ttp://ftp.gnu.org/pub/gnu/binutils/$(BINUTILS_VER).tar.bz2

build/$(BINUTILS_VER)/ : $(BINUTILS_VER).tar.bz2 build
	@echo Uncompressing $(BINUTILS_VER)
	@tar xvfj $(BINUTILS_VER).tar.bz2 > /dev/null
	mv $(BINUTILS_VER) build/$(BINUTILS_VER)

$(INSTALL_DIR)/bin/$(TARGET)-elf-objdump : build/$(BINUTILS_VER) 
$(INSTALL_DIR)
	cd build/$(BINUTILS_VER); \
	./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\
	make ;\
	make install ;\
	cd ../


#
# gcc	
#

$(GCC_VER).tar.bz2 :
	@echo Downloading $(GCC_VER)
	@wget http://ftp.gnu.org/pub/gnu/gcc/$(GCC_VER)/$(GCC_VER).tar.bz2

build/$(GCC_VER)/ : $(GCC_VER).tar.bz2
	@echo Uncompressing $(GCC_VER)
	@tar xvfj $(GCC_VER).tar.bz2 > /dev/null
	mv $(GCC_VER) build/$(GCC_VER)

$(INSTALL_DIR)/bin/$(TARGET)-elf-gcc : build/$(GCC_VER) 
$(INSTALL_DIR)/bin/$(TARGET)-elf-objdump
	cd build/ ; ./$(GCC_VER)/configure --prefix=$(INSTALL_DIR) 
--target=$(TARGET)-elf --enable-languages=c ;\
	make ;\
	make install

	
#
# gdb	
#
$(GDB_VER).tar.bz2 :
	@echo Downloading $(GDB_VER)
	wget http://ftp.gnu.org/pub/gnu/gdb/$(GDB_VER).tar.bz2
	
build/$(GDB_VER)/ : $(GDB_VER).tar.bz2 build
	@echo Uncompressing gdb
	tar xvfj $(GDB_VER).tar.bz2 > /dev/null
	mv $(GDB_VER) build/$(GDB_VER)
	
$(INSTALL_DIR)/bin/$(TARGET)-elf-gdb : build/$(GDB_VER) 
$(INSTALL_DIR)/bin/$(TARGET)-elf-gcc
	cd build/$(GDB_VER); \
	sh ./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\
	make ;\
	make install ;\
	cd ../

#
# insight-gdb	
#
$(INSIGHT_VER).tar.bz2 :
	@echo Downloading $(INSIGHT_VER)
	wget 
http://mirrors.kernel.org/sources.redhat.com/insight/releases/$(INSIGHT_VER).tar.bz2
	
build/$(INSIGHT_VER) : $(INSIGHT_VER).tar.bz2 build
	@echo Uncompressing insight-gdb
	@tar xvfj $(INSIGHT_VER).tar.bz2 > /dev/null
	mv $(INSIGHT_VER) build/$(INSIGHT_VER)

$(INSTALL_DIR)/bin/$(TARGET)-elf-insight : build/$(INSIGHT_VER) 
$(INSTALL_DIR)/bin/$(TARGET)-elf-gcc
	cd build/$(INSIGHT_VER)/ ;\
	./configure --prefix=$(INSTALL_DIR) --target=$(TARGET)-elf ;\
	make  ;\
	make install ;\
	cd ../



# clean

real_clean :
	cd build ; \rm -r *
	
	
#
# scripts
#
$(INSTALL_DIR)/bin/mips-assembler:
	cp scripts/* $(INSTALL_DIR)/bin/



# archive
zip :
	cd .. ; zip -r mips-devkit.zip mips-devkit


Wojciech Zabolotny a écrit :

> Hi All,
> 
> I have previously send this message to comp.arch.embedded, but probably it
> was "NTG", as it is more associated with the soft CPU on FPGA problem.
> Therefore I try once (the last one ;-) ) again in the comp.arch.fpga
> 
> 
> I have successfully compiled the Plasma soft CPU for my Xilinx Spartan 3E
> Starter Kit (the version of Plasma core
> http://www.opencores.org/projects.cgi/web/mips/overview
> contains the top entity and UCF needed for this board).
> 
> However I was not able to generate my own software for this CPU.
> The provided tools (
> http://www.opencores.org/projects.cgi/web/mips/gccmips_elf.zip,
> http://www.opencores.org/projects.cgi/web/mips/tools_bin.zip,
> http://www.opencores.org/projects.cgi/web/mips/gmake.zip
> )
> are "Windows-only" and unfortunately do not run under wine emulator.
> 
> I have changed the makefile to make use of the mips-linux-gnu-gcc
> or mipsel-linux-gnu-gcc packages (available from
> http://buildd.emdebian.org/debian/ )
> 
> It was also necessary to replace some backslashes with slashes.
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> # Customize for Linux                                                          
> CC_X86 = gcc -Wall -O -g                                                        
> CP = cp                                                                        
> RM = rm -rf                                                                    
> #BIN_MIPS = ../../mips/sde/bin                                                  
> VHDL_DIR = ../vhdl                                                              
> #GCC_MIPS  = mipsel-linux-gnu-gcc $(CFLAGS)                                    
> #AS_MIPS   = mipsel-linux-gnu-as                                                
> #LD_MIPS   = mipsel-linux-gnu-ld                                                
> #DUMP_MIPS = mipsel-linux-gnu-objdump                                          
> GCC_MIPS  = mips-linux-gnu-gcc $(CFLAGS)                                        
> AS_MIPS   = mips-linux-gnu-as                                                  
> LD_MIPS   = mips-linux-gnu-ld                                                  
> DUMP_MIPS = mips-linux-gnu-objdump                                              
> 
> # Customize for Windows                  
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> To make sources compiling I had to add the redefiniton
> of strncat2 to the rtos.h file:
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> #define strcpy     strcpy2  //don't use intrinsic functions                    
> #define strcat     strcat2                                                      
> #define strncat     strncat2 // <= added by WZab                                                  
> #define strcmp     strcmp2                                                      
> #define strlen     strlen2    
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Unfortunately, even after this adjustments, there are still problems
> after "make rtos" I get the following messages:
> 
> mips-linux-gnu-ld: boot.o: warning: linking PIC files with non-PIC files
> 
> ../tools/convert_bin.exe
> test.axf -> code.txt & test.bin
> Entry=0x10000c50 length=0=0x0
> 
> I can try to force mips-linux-gnu-as to generate the PIC file by
> adding the "-KPIC" option, but then I get the following warning:
> 
> mips-linux-gnu-as -KPIC -o boot.o ../tools/boot.asm
> ../tools/boot.asm: Assembler messages:
> ../tools/boot.asm:35: Warning: No .cprestore pseudo-op used in PIC code
> ../tools/boot.asm:85: Warning: No .cprestore pseudo-op used in PIC code
> 
> Anyway the convert_bin complains as before.
> 
> So I have two questions:
> 1) How to avoid the problem with PIC code?
> 2) Is it possible to generate the ROM contents with the standard tool like
>    mips(el)-linux-gnu-objcopy ?
>    Or how to fix the convert to work under linux?



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search