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 18900

Article: 18900
Subject: Re: Xilinx FPGA Editor...does it really work
From: "Austin Franklin" <austin@darkr99m.com>
Date: 20 Nov 1999 16:17:46 GMT
Links: << >>  << T >>  << A >>
Hi,

> First use File/Main Properties to turn the Edit Mode to Read Write (it is
Read
> Only by default).

I thought I had the 'read/write' selected when I tried doing my
edits...because it let me add the block, so it must have been in
read/write, right?

I'll try this again...

> Then zoom in to your CLB (Ctrl-Right Click - and by the way zoom out is
> Shift-Ctrl-Right Click!) and select your CLB pin.

I clocked on the CLB I wanted to add, and it highlighted, then I clicked
'add' and that worked (as it did before...

>Then find your net in the
> All Nets List (you can sort them by name) and Shith-Click to select it
(if you
> just Click the pin will be deselected).

I just left click and it selects the net, and highlights it...

> ress the add button and wait.

OK..it comes back and said 'warning: FPGAEditor:132 = the add command did
not find anything to add...you may have meant clock Shift-Click on the
pin...so I'll try that...AH!  That worked.

This pisses me off though, that is NOT how the on-line documentation says
it works.  They list the procedure as follows:

Adding Component Pins to an Existing Net
To add component pins to an existing net follow these steps.
In the Array window, select the component pins you want to add to the net.

The selected pins must be on a placed component (not a site), and the
selected pins must not belong to any other net.

Select the net to which you will add the pins in one of the following ways.

Display a list of nets in the List window, then select the net name from
this list.

Select any net pin, ratsnest line, or routed segment on the desired net.

Enter the Select command in the Command Line toolbar.

Select Edit Add.

The selected pins are added to the net.

When I do their procedure...it just doesn't work.  How did you figure out
how to do it?  You certainly didn't follow their documentation!

> Then
> wait some more and when you least expect it your pin will be connected to
that
> net. Of course, you must first configure the CLB pin and then add it to
the
> net, otherwise it will just give you an error.

It let me add the pin using your instructions, with no error, and the block
isn't configured...

> You can also add multiple pins
> to a net this way (using Shift-Click).

All set on adding nets now!  It's that 'Shift' that did it!

> Now for the CLB equation problem. Select the CLB, press the editblock
button
> and in the Block Editor window the F= toolbar button. Edit Feqn and Geqn
and
> press the Save Changes and Closes Window toolbar button. It works for me.

I type "f4", "a4" and even the name of the net in the Feqn area...with no
equation (to avoid any problems with what characters mean not, and, or
etc.) and when I hit 'save' I get an error "not a valid value for the Feqn
attribute".  Anything aside from 0 or 1 gives me an error.  This still
appears to be broken for me...any suggestions?

Even if this tools worked, and was documented correctly...is is vastly more
difficult to use than the previous version...which worked quite well.  Even
the graphics in the new tool are 'difficult'.

Thanks for all your help!  Well, at least you got me able to add a pin to
an existing net!  That's a lot further than I was before!  P.S.  I am using
2.1i...

Regards,

Austin


Article: 18901
Subject: Re: Xilinx FPGA Editor...does it really work?
From: "Austin Franklin" <austin@darkr99m.com>
Date: 20 Nov 1999 16:21:38 GMT
Links: << >>  << T >>  << A >>
> I think Catalin gave you some good advice. I believe the procedure you
> were using will let you add the pin to a new net. Since the net you
> typed exists, it would not clobber the existing net. 

Yep, he did...I am not able to add a CLB pin to an existing net...but I
still can't edit the equation in the CLB...

> The tool was protecting you from yourself... AND being very obtuse. 

That wasn't the problem...it was I was following the documentation....which
failed to mention the need to 'shift-click' to select the CLB pin (after
selecting the net in the List window)...

Obtuse is an understatement...I don't believe I ever had to read the
documentation of the previous XACT Editor...it was just easy and intuitive
to use....for once I read the documentation...and it appears it was
wrong...it may have been wrong in the old version, but hey, I would have
never known ;-)

Thanks!

Austin

Article: 18902
Subject: Re: Xilinx FPGA Editor...does it really work?
From: "Austin Franklin" <austin@darkr99m.com>
Date: 20 Nov 1999 16:38:42 GMT
Links: << >>  << T >>  << A >>
> Yep, he did...I am not able to add a CLB pin to an existing net...but I
> still can't edit the equation in the CLB...

Sorry, bad proof reading...that is NOW able to add a CLB pin...

Article: 18903
Subject: Re: Need advice on interfacing SDRAM modules
From: Tom Davidson <TomD@Nshore.com>
Date: Sat, 20 Nov 1999 14:16:20 -0600
Links: << >>  << T >>  << A >>
If you're not trying to do anything fancy, like multiple bank activation,
you can implement a SDRAM precharge controller in an Altera Max7128A-6
at 66MHZ, it gets pretty dicey at 75 and 83, I still havent been able to get my design
to run at 100MHZ though, too many layers of logic on the RAS, CAS, and WE lines.
I'm also doing the address mux in the MAX, and using a GAL for the DQM decode.
This sits on a PPC750 bus, and does burst/singlebeat 64/32/16/8 byte transfers.
It's at the limit of the PLD right now with one-hot state machines.

mar@tcelectronic.com wrote:

> Hello Maciej
>
> Have a look at an article, published in EDN 020298:
>
> Analyzing and implementing SDRAM and SGRAM controllers, available at:
> http://www.ednmag.com/reg/1998/020298/03df_04.htm
>
> You'll have to register at edn, to get access to the article.
>
> Regards,
> Martin Roenne
> TC Electronic
>
> In article <38303A31.6A89@et.put.poznan.pl>,
>   Maciej Bartkowiak <mbartkow@et.put.poznan.pl> wrote:
> > Dear All
> >
> > Here, at the University, we are running a design project that involves
> > interfacing the SDRAM modules with a custom FPGA-based system. We have
> > to cope with severe problems related to the complexity of SDRAM
> control.
> > We badly need advice from experienced designers of uC systems and
> would
> > be truly thankful for some hints. We are looking for any
> possibilities
> > to contact such experts, so please let us know if you know any.
> >
> > thank you very much,
> >
> > m.b.
> >
> > --
> >
> > Maciej Bartkowiak, PhD
> >
> ========================================================================
> > Institute of Electronics and Telecommunication     fax: (+48 61)
> 6652572
> > Poznan University of Technology                  phone: (+48 61)
> 6652171
> > Piotrowo 3A                             email:
> mbartkow@et.put.poznan.pl
> > 60-965 Poznan POLAND
> http://www.et.put.poznan.pl/~mbartkow
> >
> ========================================================================
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Article: 18904
Subject: Re: Virtex: Getting flip-flops into the pads
From: simon_bacon@my-deja.com
Date: Sat, 20 Nov 1999 21:37:15 GMT
Links: << >>  << T >>  << A >>
Looking in the .MRP file (from MAP) is much easier than lurching
around in FPGA Editor.

Also, beware that Synplify is 'smart' enough to convert some register
sequences to SRLs, which can _never_ be put into IOBs.  When this
happens you have to dance the attribute tango, or use explicit
FF instantiation, to get the result you desire.

In article <814j3o$6ai$1@bcrkh13.ca.nortel.com>,
  "Jamie Sanderson" <jamie@nortelnetworks.com> wrote:
<snip>
> I've checked this using the FPGA editor. The pads are only being
> used as IBUF or OBUF.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18905
Subject: Re: Why not Lucent ORCA FGPAs?
From: murray@pa.dec.com (Hal Murray)
Date: 21 Nov 1999 00:36:47 GMT
Links: << >>  << T >>  << A >>

> For now, I am very happy with the Lucent parts. I got 221 IOs in a 256
> BGA package which is more than any of the Xilinx parts. The Xilinx
> Virtex part (comparable to the OR3T parts) only gives 180 IOs in the 256
> pin package!!!

Does 221 out of 256 leave enough power-ground pins?  How about
when you have a big bus switching?

Do the Lucent parts have separate VCCs for core and IO?
-- 
These are my opinions, not necessarily my employers.
Article: 18906
Subject: Re: Xilinx FPGA Editor...does it really work?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 20 Nov 1999 22:11:37 -0500
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> Obtuse is an understatement...I don't believe I ever had to read the
> documentation of the previous XACT Editor...it was just easy and intuitive
> to use....for once I read the documentation...and it appears it was
> wrong...it may have been wrong in the old version, but hey, I would have
> never known ;-)
> 
> Thanks!
> 
> Austin

I feel your pain. It has been a major point of contention with me over
the years that although the tools have improved (even though you might
argue that point ;) they are still a far cry from being user friendly. I
don't spend much time in the chip editors except to verify the results
of synthesis and placement. But I do spend a lot of time using
constraints. As long as we are complaining, I think this is one of the
top three areas where improvement is required. 

I guess a lot of the tools are not too hard to use after you come up the
learning curve, but they can be such a pain to learn!!! I am now
learning the Lucent Orca design tools and I don't think they are any
better than the Xilinx tools and may well be somewhat worse. In both
houses the documentation is left as a poor stepchild (it is written by
engineers, ya know! ) and are very seldom redone when new stuff comes
out in a new format. As a result there seems to be multiple places you
have to check to get the info you need if it is available at all. And
don't bother suggesting that some new documentation should be written.
It is hard to find a champion among the FGPA vendors for that. 

Well, thanks for the opportunity to complain. I always enjoy sharing my
misery with others...  :)


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 18907
Subject: Re: Why not Lucent ORCA FGPAs?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 20 Nov 1999 22:29:04 -0500
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> > For now, I am very happy with the Lucent parts. I got 221 IOs in a 256
> > BGA package which is more than any of the Xilinx parts. The Xilinx
> > Virtex part (comparable to the OR3T parts) only gives 180 IOs in the 256
> > pin package!!!
> 
> Does 221 out of 256 leave enough power-ground pins?  How about
> when you have a big bus switching?
> 
> Do the Lucent parts have separate VCCs for core and IO?
> --
> These are my opinions, not necessarily my employers.


I will let you know, but I don't think it will be a problem. I have a 32
bit data bus and when I add DMA to my design in a month or two I will
also have a 24 bit address bus switching at the same time (maybe). Most
of the problem is with ground bounce. 

It is a bit funny, but a 256 pin BGA has 270 pins. They add 16 pins
(balls) in the center that are all grounds. I think this brings the
total grounds to 29. There are 13 Vdd giving 17 IOs per power pin and
about 7.5 IOs per ground pin. 

So I am not expecting any problem from ground bounce. I have put
decoupling capacitors very, very close to the power pins, one per. So I
don't expect a problem from the power side either. 

The OR3T family uses 3 volt Vdd for the whole chip. They make the IOs 5
volt tolerant. So the power is all on one set of Vdd pins. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 18908
Subject: Re: Need advice on interfacing SDRAM modules
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 20 Nov 1999 22:37:16 -0500
Links: << >>  << T >>  << A >>
Tom Davidson wrote:
> 
> If you're not trying to do anything fancy, like multiple bank activation,
> you can implement a SDRAM precharge controller in an Altera Max7128A-6
> at 66MHZ, it gets pretty dicey at 75 and 83, I still havent been able to get my design
> to run at 100MHZ though, too many layers of logic on the RAS, CAS, and WE lines.
> I'm also doing the address mux in the MAX, and using a GAL for the DQM decode.
> This sits on a PPC750 bus, and does burst/singlebeat 64/32/16/8 byte transfers.
> It's at the limit of the PLD right now with one-hot state machines.

One suggestion, one-hot coding is not always the best or fastest way to
go with a state machine. Basically to make a machine faster, you want to
minimize the number of inputs (variables) to each bit of the state
machine. One-hot encoding works well when you have a simple state
diagram which has few entry paths to each state and those entry paths
have few variables controlling them. 

If this is not the case and your machine has many paths into some states
and/or you have a lot of different control variables on paths to a
single term, you may be better off with an encoded machine. In that case
you at least can represent any combination of states with the same
number of variables (bits). So a machine with say, 6 different paths
converging to the IDLE state won't need 6 state variables to the IDLE
logic, just enough to encode the number of states. 

-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 18909
Subject: Synplify vs. FPGA Compiler II (v3.3)
From: arafeeq@my-deja.com
Date: Sun, 21 Nov 1999 04:07:32 GMT
Links: << >>  << T >>  << A >>
 Hello!

We are evaluating the above two Synthesis tools for our FPGA and ASIC
design. Anybody who has used these tools could you please tell me which
tool we should be buying in order to design the FPGA and ASIC. Please
note that our design will be 250,000 gates and FPGA would be Xilinx's
virtex device XCV800.

If possible could you highlight from your experience point of view whats
the diff. between FPGA Express and FPGA Compiler II also.



Thanks in advance for your comments,

Best Regards,

Abdul Rafeeq.



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18910
Subject: Re: [Q] End-goal: porting ISA design to PCI. Which PLD to learn?
From: Assaf Sarfati <azarfati@bwiil.jnj.com>
Date: Sun, 21 Nov 1999 08:34:58 +0200
Links: << >>  << T >>  << A >>
Paul Oh wrote:
> 
> Hi to all!
> 
> My end-goal is to port my ISA card design to PCI.  This ISA card is a
> simple 8255-based I/O board.  It's details if you are interested are at
> http://www.boondog.com - see the Tutorials link.
> 
> I have no PCI experience.  My impression is that one needs a FPGA or other
> programmable logic device (PLD) for PCI interfacing.
> 
> I have no PLD experience but do know digital logic and digital system
> design (I am mechanical engineer).
> 
> Xilinx and Altera sell affordable ($100 range) development kits and
> software (student versions).
> 
> Q.  For my stated end-goal which PLD should I begin my learning curve on?
> Q.  Are on-line PCI tutorials (in relation to my end-goal or porting
>     ISA designs to PCI) ?
> 
> Much appreciated,
> 
> Paul Oh

If you are porting an existing ISA design, the easiest path is to use a
standard PCI-interface chip. There are several companies which offer
various solutions, including PCI-to-ISA. See PLX (www.plxtech.com) AMCC
(www.amcc.com) and V3 (www.vcubed.com).

PCI-cores for FPGAs are usually intended for complex FPGAs in which PCI
interface is mandatory, but not a very large part of the design; they
are also pretty expensive (NRE of $5K and above). There are also some
FPGAs (QuickLogic, ORCA) which have a hard-wired PCI core built in. All
are probably overkill for your application.

		Regards
		Assaf Sarfati
Article: 18911
Subject: Brand New MUSIC
From: Jonathon Hill<jhill5@neo.rr.com>
Date: Sun, 21 Nov 1999 08:58:37 GMT
Links: << >>  << T >>  << A >>
Check Out The New Music At MP3.com
 CLICK  HERE>http://artists.mp3s.com/artists/9/lightyear.html
Article: 18912
Subject: Re: Need advice on interfacing SDRAM modules
From: jhallen@world.std.com (Joseph H Allen)
Date: Sun, 21 Nov 1999 17:41:25 GMT
Links: << >>  << T >>  << A >>
In article <383768EC.33B55D9F@yahoo.com>,
Rickman  <spamgoeshere4@yahoo.com> wrote:
>Tom Davidson wrote:
>> 
>> If you're not trying to do anything fancy, like multiple bank activation,
>> you can implement a SDRAM precharge controller in an Altera Max7128A-6
>> at 66MHZ, it gets pretty dicey at 75 and 83, I still havent been able to get my design
>> to run at 100MHZ though, too many layers of logic on the RAS, CAS, and WE lines.
>> I'm also doing the address mux in the MAX, and using a GAL for the DQM decode.
>> This sits on a PPC750 bus, and does burst/singlebeat 64/32/16/8 byte transfers.
>> It's at the limit of the PLD right now with one-hot state machines.

>One suggestion, one-hot coding is not always the best or fastest way to
>go with a state machine. Basically to make a machine faster, you want to
>minimize the number of inputs (variables) to each bit of the state
>machine. One-hot encoding works well when you have a simple state
>diagram which has few entry paths to each state and those entry paths
>have few variables controlling them. 

>If this is not the case and your machine has many paths into some states
>and/or you have a lot of different control variables on paths to a
>single term, you may be better off with an encoded machine. In that case
>you at least can represent any combination of states with the same
>number of variables (bits). So a machine with say, 6 different paths
>converging to the IDLE state won't need 6 state variables to the IDLE
>logic, just enough to encode the number of states. 

I think one-hot coding is still the best.  The problems you mention can
almost always be fixed by using some combination of pipelining and parallel
state machines.  For example, the problem of 6 different paths leading to
the IDLE state can be fixed by adding two flip flops.  The input to each is
the OR of three of the 6 paths, but one cycle early.  Now you have only two
paths from these flip flops (but you have more than one bit on at the same
time).  Also I find that it is unwise to add unnecessary control logic just
to reduce the number of states.  It is better to have duplicate states which
lack control logic and use output flip flops to merge these states into the
control signals that they generate.  Most steps of my state machines reduce
to simple shift registers with no steering logic.

One other technique is helpful for this: break the problem into multiple
smaller parallel state machines.  On the output side this often means using
synchronous set/reset flip flops to make extended pulses.  Why OR 8 states
into a single control line which is on for 8 consecutive cycles, when all
you need is two?  One for when it turns on and one for when it turns off.

On the input side, think subroutines.  The main controller has IDLE and
BUSY states, and generates START signals for the subroutine state machines. 
These give DONE signals back to the main controller to break it out of the
BUSY states.
-- 
/*  jhallen@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 18913
Subject: Re: Why not Lucent ORCA FGPAs?
From: Robert Sefton <rsefton@home.com>
Date: Sun, 21 Nov 1999 19:24:10 GMT
Links: << >>  << T >>  << A >>
I'm a long-time Xilinx user but have been using Orca for the past
year due to circumstances beyond my control. My overall opinion of
the 3T and 3L devices is positive, but there many other reasons to
choose Xilinx over Orca:

1. The Orca tools are not as comprehensive as the Xilinx tools.
Orca has no floorplanner, for example. And the bug-fix cycle is
much longer for Orca. The huge Xilinx cutomer base and the
above-average sophistication of most long-time Xilinx customers
give Xilinx a huge advantage in identifying tool bugs. And to
Xilinx's credit, they take advantage of this to identify
workarounds and distribute patches much faster than Lucent.
2. Lucent tech support is nowhere near the level of Xilinx. I've
always found Xilinx FAE support excellent; the on-line answers
database, app notes, etc., also excellent; the hot-line support is
better than most, but I hesitate to call it excellent; the
information available through users groups and forums like this ng
is excellent due simply to the much larger Xilinx customer base.
Lucent provides token FAE support and their on-line resouces are
pitiful.
3. Lucent has poor IP support for Orca vs. Xilinx. They don't even
own a PCI core that they can provide customers. There is a huge
amount of IP available for Xilinx both directly and through
3rd-party partnerships.
4. Xilinx has a much more clear and agressive road map going
forward. They're the clear technology leader in the FPGA space in
my opinion.
5. The level of support from other tool vendors (Synplify,
ModelTech, etc.) is much greater for Xilinx than for Orca. Just
look at the number of Xilinx-specific app notes on these vendors'
web sites for an indication of their priority. Again, this is due
to the large number of Xilinx users vs. Orca.

One other general comment. Xilinx's sole business is programmable
logic. FPGAs is a very small part of Lucent's business, and it
shows. If Lucent ever really threw significant development/support
and marketing resources at Orca I think they could almost compete
with Xilinx. But the commitment just isn't there. I think you
would be much happier and successful as a Xilinx customer.

Robert Sefton

Rickman wrote:
> 
> I have picked the Lucent ORCA FPGAs for the board I am currently
> building due to IO count, part cost and support. I have noticed that
> there are not many people discussing these devices in this newsgroup,
> which I assume is because there are not a lot of people using them. Can
> I ask why Xilinx parts are preferred over the Lucent devices? Other than
> inertia, why did you pick the Xilinx devices?
> 
> --
> 
> Rick Collins
> 
> rick.collins@XYarius.com
> 
> remove the XY to email me.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
> 
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
> 
> Internet URL http://www.arius.com
Article: 18914
Subject: Altera JAM
From: "Erich Wagner" <ewagner@pdq.net>
Date: Sun, 21 Nov 1999 13:29:59 -0600
Links: << >>  << T >>  << A >>
Is anyone actively using Altera's JAM technology? What are your experiences?
I haven't heard anything about it for over a year and had assumed (probably
incorrectly) that interest in it had faded away.

Thanks,
Erich



Article: 18915
Subject: Re: Why not Lucent ORCA FGPAs?
From: "Adam J. Elbirt" <aelbirt@nac.net>
Date: Sun, 21 Nov 1999 16:56:11 -0500
Links: << >>  << T >>  << A >>
Robert,

Just as an FYI, Lucent has had the EPIC floorplanner for quite some time.  In
fact, they had EPIC before Xilinx had their M1 equivalent.

Adam

Robert Sefton wrote:

> I'm a long-time Xilinx user but have been using Orca for the past
> year due to circumstances beyond my control. My overall opinion of
> the 3T and 3L devices is positive, but there many other reasons to
> choose Xilinx over Orca:
>
> 1. The Orca tools are not as comprehensive as the Xilinx tools.
> Orca has no floorplanner, for example. And the bug-fix cycle is
> much longer for Orca. The huge Xilinx cutomer base and the
> above-average sophistication of most long-time Xilinx customers
> give Xilinx a huge advantage in identifying tool bugs. And to
> Xilinx's credit, they take advantage of this to identify
> workarounds and distribute patches much faster than Lucent.
> 2. Lucent tech support is nowhere near the level of Xilinx. I've
> always found Xilinx FAE support excellent; the on-line answers
> database, app notes, etc., also excellent; the hot-line support is
> better than most, but I hesitate to call it excellent; the
> information available through users groups and forums like this ng
> is excellent due simply to the much larger Xilinx customer base.
> Lucent provides token FAE support and their on-line resouces are
> pitiful.
> 3. Lucent has poor IP support for Orca vs. Xilinx. They don't even
> own a PCI core that they can provide customers. There is a huge
> amount of IP available for Xilinx both directly and through
> 3rd-party partnerships.
> 4. Xilinx has a much more clear and agressive road map going
> forward. They're the clear technology leader in the FPGA space in
> my opinion.
> 5. The level of support from other tool vendors (Synplify,
> ModelTech, etc.) is much greater for Xilinx than for Orca. Just
> look at the number of Xilinx-specific app notes on these vendors'
> web sites for an indication of their priority. Again, this is due
> to the large number of Xilinx users vs. Orca.
>
> One other general comment. Xilinx's sole business is programmable
> logic. FPGAs is a very small part of Lucent's business, and it
> shows. If Lucent ever really threw significant development/support
> and marketing resources at Orca I think they could almost compete
> with Xilinx. But the commitment just isn't there. I think you
> would be much happier and successful as a Xilinx customer.
>
> Robert Sefton
>
> Rickman wrote:
> >
> > I have picked the Lucent ORCA FPGAs for the board I am currently
> > building due to IO count, part cost and support. I have noticed that
> > there are not many people discussing these devices in this newsgroup,
> > which I assume is because there are not a lot of people using them. Can
> > I ask why Xilinx parts are preferred over the Lucent devices? Other than
> > inertia, why did you pick the Xilinx devices?
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> >
> > remove the XY to email me.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design
> >
> > Arius
> > 4 King Ave
> > Frederick, MD 21701-3110
> > 301-682-7772 Voice
> > 301-682-7666 FAX
> >
> > Internet URL http://www.arius.com

--
"Sometimes I think the surest sign that there's intelligent life on
other planets is that none of it has tried to contact us."
                                      - Calvin, "Calvin and Hobbes"


Article: 18916
Subject: CHES 2000
From: Christof Paar <christof@ece.wpi.edu>
Date: Sun, 21 Nov 1999 17:45:05 -0500
Links: << >>  << T >>  << A >>
           Workshop on Cryptographic Hardware and Embedded Systems 2000
                                 (CHES '2000)
                   http://www.ece.WPI.EDU/Research/crypt/ches

                       Worcester Polytechnic Institute
                       Worcester, Massachusetts, USA
                            August 17 & 18, 2000

                           First Call for Papers

General Information

The focus of this workshop is on all aspects of cryptographic hardware
and embedded system design. The workshop will be a forum of new results
from the research community as well as from the industry. Of special
interest are contributions that describe new methods for efficient
hardware implementations and high-speed software for embedded systems,
e.g., smart cards, microprocessors, DSPs, etc. We hope that the
workshop will help to fill the gap between the cryptography research
community and the application areas of cryptography. Consequently, we
encourage submission from academia, industry, and other organizations.
All submitted papers will be reviewed.

This will be the second CHES workshop. The first workshop, CHES '99, was
held at WPI in August of 1999 and was very well received by academia and
industry. There were 170 participants, more than half of which were from
outside the United States.

The topics of interest include but are not limited to:

   * Computer architectures for public-key cryptosystems
   * Computer architectures for secret-key cryptosystems
   * Reconfigurable computing and applications in cryptography
   * Cryptographic processors and co-processors
   * Modular and Galois field arithmetic architectures
   * Tamper resistance on the chip and board level
   * Architectures for smart cards
   * Tamper resistance for smart cards
   * Efficient algorithms for embedded processors
   * Special-purpose hardware for cryptanalysis
   * Fast network encryption
   * True and pseudo random number generators

Mailing List

If you want to receive emails with subsequent Call for Papers and 
registration information, please send a brief mail to ches@ece.orst.edu. 

Instructions for Authors

Authors are invited to submit original papers. The preferred submission
form is by electronic mail to ches@ece.orst.edu. Papers should be
formatted in 12pt type and not exceed 12 pages (not including the title
page and the bibliography). The title page should contain the author's
name, address (including email address and an indication of the
corresponding author), an abstract, and a small list of key words.
Please submit the paper in Postscript or PDF. We recommend that you
generate the PS or PDF file using LaTeX, however, MS Word is also
acceptable. All submissions will be refereed.

Only original research contributions will be considered. Submissions
must not substantially duplicate work that any of the authors have
published elsewhere or have submitted in parallel to any other
conferences or workshops that have proceedings.

Workshop Proceedings

The post-proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science (LNCS) series. Notice that in order to be
included in the proceedings, the authors of an accepted paper must
guarantee to present their contribution at the workshop.

Important Dates

 Submission Deadline:          April 15th, 2000.
 Acceptance Notification:      June 15th, 2000.
 Final Version due:            August 1st, 2000.
 Workshop:                     August 17th & 18th, 2000.
 
NOTES: The CHES dates August 17 & 18 are the Thursday & Friday preceding
       CRYPTO '2000 which starts on August 20.

Invited Speakers

David Naccache, Gemplus, France.
		"How to explain side channel leakage to your kids?"

Alfred Menezes, University of Waterloo, Canada.
		TBA

Program Chairs

All correspondence and/or questions should be directed to either of the
Program Chairs:

 Cetin Kaya Koc                       Christof Paar
 Dept. of Electrical & Computer       Dept. of Electrical & Computer
 Engineering                          Engineering
 Oregon State University              Worcester Polytechnic Institute
 Corvallis, Oregon 97331, USA         Worcester, MA 01609, USA
 Phone: +1 541 737 4853               Phone: +1 508 831 5061
 Fax: +1 541 737 8377                 Fax: +1 508 831 5491
 Email: Koc@ece.orst.edu              Email: christof@ece.wpi.edu

Program Committee

Gordon Agnew,  University of Waterloo, Canada
Wayne Burleson,   University of Massachusetts at Amherst, USA
Kris Gaj, George Mason University, USA
Peter Kornerup, Odense University, Denmark
Jean-Jacques Quisquater,   Universite Catholique de Louvain, Belgium
Patrice L. Roussel,  Intel Corporation, USA
Christoph Ruland,   University of Siegen, Germany
Joseph H. Silverman, Brown University and NTRU Cryptosystems, Inc., USA
Colin D. Walter, Computation Department - UMIST, U.K.
Michael Wiener,   Entrust Technologies, Canada

Location

WPI is in Worcester, the second largest city in New England. The city
is 80 km (50 miles) West of Boston and 280 km (175 miles) North-East of
New York City.

Worcester is home to a wealth of cultural treasures, many of which are
just a short distance from WPI. These include the historic Higgins
Armory Museum, which houses one of the world's largest collections of
armor; the EcoTarium (formerly New England Science Center), one of the
only museums in the country dedicated to environmental education; and
the beautifully restored Mechanics Hall, one of America's finest
concert halls. The Worcester Art Museum, holding one of the nation's
finest collections, and the world-renowned American Antiquarian
Society, with the largest collection of items printed during the
nation's colonial period, are within two blocks of the WPI campus.
Worcester is also well known for its ten colleges, which cooperate
through the Colleges of Worcester Consortium.

Recreation areas within easy driving distance include Boston and Cape
Cod to the east, the White and Green mountains to the north, and the
Berkshires to the west.

August weather in New England is usually very pleasant with average
temperatures of 20 C (70 F).

Workshop Sponsors

This workshop has received generous support from Intel, secunet AG, and
SITI.  The organizers express their sincere thanks.

Article: 18917
Subject: Re: configure_flex10k30e_jtag_jam
From: Michael Stanton <mikes@magtech.com.au>
Date: Mon, 22 Nov 1999 10:25:08 +1100
Links: << >>  << T >>  << A >>
Andreas

Sorry if this sounds dumb, but check the actions in the parameters you pass when
you call jam.exe.
Jam will happily do nothing (without complaint) if you don't include something
like "DOCONFIGURE=1" with the parameters in the call.

We use the Jam player to configure a 10K30A as part of a 3 device JTAG chain,
through an "embedded" ByteBlaster and it has been working fine so far...

Regards, Michael


a_maier@my-deja.com wrote:

> Hello All i want to configure a altera flex10k30e using the jtag-port and a
> jam-player. I am using MAX+II vers. 9.30 and the update to 9.31 applied to
> it. The jam-player i ported for my hardware is vers. 2.12. When running the
> JAM/STAPL file of my design an error occurs (even with the original 16bit
> jam-player jam.exe). The error is "Error on line 35: action name not found."
> Is there anybody who has experience in configuring flex devices with JAM?
>
> Andreas
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.




Article: 18918
Subject: Re: Why not Lucent ORCA FGPAs?
From: Ray Andraka <randraka@ids.net>
Date: Sun, 21 Nov 1999 19:45:45 -0500
Links: << >>  << T >>  << A >>
EPIC is _NOT_ a floorplanner.  It is an editor, and a PITA at that.  I'd take the
old  the Xact 6.0 XDE and floorplanner over the current tools any day if they
would support the current devices.

Adam J. Elbirt wrote:

> Just as an FYI, Lucent has had the EPIC floorplanner for quite some time.  In
> fact, they had EPIC before Xilinx had their M1 equivalent.
>
> Adam
>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18919
Subject: PADS Experience?
From: "Anthony Ellis - LogicWorks" <a.ellis@logicworks.co.za>
Date: Mon, 22 Nov 1999 06:07:05 +0200
Links: << >>  << T >>  << A >>
Sorry. Thids is not an FPGA question but I am sure you all use similar
tools.

Has anyone any comment on the PADS schematic capture tool as compared to say
Orcad or Protel.
I am looking for a good, reasonable cost,  front end for PCB designs -
Win85/98 based.
Someting with good hierarchy support rather than "dumb" busses and blocks.


Anthony
--
LogicWorks - Electronic Development Services
    Anthony Ellis
    Cell:           082 4453285
    Phone      27-(0)12 9988062


Article: 18920
Subject: IWDRS 2000 Final Call for Papers
From: Minhee Cho <mhcho@camars.kaist.ac.kr>
Date: Mon, 22 Nov 1999 16:01:21 +0900
Links: << >>  << T >>  << A >>

======================================================================

                      ICDCS 2000 CALL FOR PAPERS

  International Workshop on Distributed Real-Time Systems (IWDRS)

                Taipei, Taiwan, Republic of China,
                          April, 10 - 13, 2000
             http://calab.kaist.ac.kr/Conf/IWDRS2000

                         in conjunction with
 The 20th International Conference on Distributed Computing Systems
                             (ICDCS 2000)
                 http://www.cis.ohio-state.edu/~icdcs20/
 Workshop proceedings to be published by IEEE Computer Society Press
======================================================================



THEME

Recently, the distributed real-time systems are widely adopted in
various environments like process control systems, automatized
factories,
and even a car. IWDRS will be devoted to the presentation of new and
on-going projects in distributed real-time technology and applications.
The prime purpose of IWDRS is to provide researchers with an opportunity

to discuss their evolving ideas and results.Topics of interest include
but are not limited to:
  o Distributed Real-Time Scheduling
  o Distributed Real-Time Programming Language
  o Distributed Multimedia Systems
  o Distributed Resource Management
  o Real-Time Kernel
  o Real-Time Surveillance
  o Networking, Fault Tolerance, and Security
  o Plant and Process Control
  o Telecommunications and Mobile Computing
  o Space Systems, Air Traffic Control, Avionics, and Air Defense


IMPORTANT DATES
  o Submission:  December 1, 1999
  o Notification of Acceptance:   December 15, 1999
  o Camera-ready Copies: January, 1, 2000

PAPER SUBMISSION

Authors are invited to submit research contributions representing
original, previously unpublished work. Submitted papers will be
carefully evaluated based on originality, significance, technical
soundness, and clarity of exposition. All papers will be refereed
by at least two members of the program committee. Accepted papers
will be published by IEEE Computer Society Press as proceedings of
the ICDCS 2000 workshops. All submitted papers MUST be formatted
according to the author guidelines provided by IEEE Computer
Society Press (two-column format) and MUST NOT be longer than
6 pages.

Electronic Submission

Please e-mail one PDF or PostScript version of your paper to the
Workshop Program Chair at hyoon@calab.kaist.ac.kr

Postal Submission

If, for some reason, you cannot send your paper by email,
ONLY THEN you may submit it as four hard copies to the following
address:

 Prof. Hyunsoo Yoon
 Dept. of Computer Science,
 Korea Advanced Institute of Science and Technology,
 373-1 Kusong-dong, Yusong-gu, Taejon 305-701, Republic of Korea

WORKSHOP CHAIR

 Hyunsoo Yoon, Korea Advanced Institute of Science and Technology,
 Republic of Korea


PROGRAM COMMITTEE

 Sang Hyuk Son (Univ. of Virginia, USA)
 Insup Lee (Univ. of Pennsylvania, USA)
 Heung-Kyu Lee (KAIST, Korea)
 Jae-Heon Yang (KAIST, Korea)
 Kane Kim (U. C. Irvine, USA)
 Al Mok (Univ. of Texas at Austin, USA)
 Lui Sha (Univ. of Illinois at Urbana-Champaign, USA)
 John Stankovic (Univ. of Virginia, USA)
 Oleg Sokolsky (Univ. of Pennsylvania, USA)
 Kwei-Jay Lin (U. C. Irvine, USA)
 Sangyoul Min (Seoul National University, Korea)
 Seongbae Eun (Hannam University, Korea)
 Jinsoo Kim (Korea Telecom, Korea)
 Tarek Abdelzaher (Univ. of Virginia, USA)
 Tei-Wei Kuo (National Chung Cheng Univ., Taiwan)
 Victor Lee (City Univ. of Hong Kong, Hong Kong)
 Jane Liu (Univ. of Illinois at Urbana-Champaign, USA)
 Kang Shin (Univ. of Michigan, USA)
 Kinji Mori (Tokyo Inst. of Tech., Japan)


Article: 18921
Subject: Most micros (PIC/8051 etc) have TCP/IP stacks freely available.
From: #YEO WEE KWONG# <P7102672H@ntu.edu.sg>
Date: Mon, 22 Nov 1999 15:03:31 +0800
Links: << >>  << T >>  << A >>
Hi
Can you elaborate on the statement below which you wrote. 
"Most micros (PIC/8051 etc) have TCP/IP stacks freely available."

Is it in the form of hardware module or software module.


-----Original Message-----
From: Austin Franklin [mailto:austin@darkr99oom.com]
Posted At: 17 November 1999 23:40
Posted To: comp.arch.fpga
Conversation: implementing TCP/IP on PLD
Subject: Re: implementing TCP/IP on PLD


> Forget 'simple' with a TCP/IP stack.
> The simplest would be using datagrams (UDP protocol), which you might
be
> able to squeeze into about 1k of uP code if you are skilful. Full
> implementations you are talking about 25K+ of code on a fast uP.

One of the PIC implementation I have seen is only 512 'bytes' of code.

> What you are trying to do is *very* difficult - to the extent that
(AFAIK)
> only one manufacturer is vending TCP/IP on a chip with no legal
strings
> attached, and that's a custom uP.

Most micros (PIC/8051 etc) have TCP/IP stacks freely available.  Also,
there are a number of embedded chips that have TCP/IP stacks ON them
that
are available now.  It's just not THAT difficult...but I guess it
depends
on what you think is difficult...

Article: 18922
Subject: implementing TCP/IP on PLD
From: #YEO WEE KWONG# <P7102672H@ntu.edu.sg>
Date: Mon, 22 Nov 1999 15:21:26 +0800
Links: << >>  << T >>  << A >>
Where 

-----Original Message-----
From: Jamie Lokier [mailto:spamfilter.nov1999@tantalophile.demon.co.uk]
Posted At: 18 November 1999 01:14
Posted To: comp.arch.fpga
Conversation: implementing TCP/IP on PLD
Subject: Re: implementing TCP/IP on PLD


Austin Franklin writes:
> You can not implement a TCP/IP stack in just a PLD, there simply
aren't
> enough gates, so you must not mean PLD, but something else...possibly
> microprocessor, FPGA.

I heard it's been done on an FPGA, and not an especially large one
either.

-- Jamie

Article: 18923
Subject: Re: Why not Lucent ORCA FGPAs?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 22 Nov 1999 02:41:23 -0500
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> EPIC is _NOT_ a floorplanner.  It is an editor, and a PITA at that.  I'd take the
> old  the Xact 6.0 XDE and floorplanner over the current tools any day if they
> would support the current devices.

Come on Ray, don't hold back. Tell us how you really feel!!!  ;)


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 18924
Subject: Re: Why not Lucent ORCA FGPAs?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Mon, 22 Nov 1999 02:59:48 -0500
Links: << >>  << T >>  << A >>
Robert Sefton wrote:
> 
> I'm a long-time Xilinx user but have been using Orca for the past
> year due to circumstances beyond my control. My overall opinion of
> the 3T and 3L devices is positive, but there many other reasons to
> choose Xilinx over Orca:
> 
> 1. The Orca tools are not as comprehensive as the Xilinx tools.
> Orca has no floorplanner, for example. And the bug-fix cycle is
> much longer for Orca. The huge Xilinx cutomer base and the
> above-average sophistication of most long-time Xilinx customers
> give Xilinx a huge advantage in identifying tool bugs. And to
> Xilinx's credit, they take advantage of this to identify
> workarounds and distribute patches much faster than Lucent.

That is useful information. I have not worked with the current Orca
tools long enough to find out about this yet. 


> 2. Lucent tech support is nowhere near the level of Xilinx. I've
> always found Xilinx FAE support excellent; the on-line answers
> database, app notes, etc., also excellent; the hot-line support is
> better than most, but I hesitate to call it excellent; the
> information available through users groups and forums like this ng
> is excellent due simply to the much larger Xilinx customer base.
> Lucent provides token FAE support and their on-line resouces are
> pitiful.

Again, I don't have enough experience with the Lucent tech support to
rate them fully, but what I have experienced on the hot line is about
the same a Xilinx, adequate, but in need of improvement. You are right
about Lucent's online support, you can't complain about it, because they
don't have any. I browsed their FTP site for about 10 minutes and I
think I checked out everything they have. But I did find a couple of
useful tutorials on the clocking in the OR3T parts which was very useful
since they don't explain it well in the datasheet. 


> 3. Lucent has poor IP support for Orca vs. Xilinx. They don't even
> own a PCI core that they can provide customers. There is a huge
> amount of IP available for Xilinx both directly and through
> 3rd-party partnerships.

You may be right about this, but your example is not good. They likely
don't have an IP for a PCI core because they want to sell you the FPIC
(or whatever acronym they use) that contains a hardware PCI core and
FPGA circuitry. I expect this is a much better way to go than IP anyway
as it needs no consideration by the tools, is much more efficient in
terms of $$ and die size and likely just plain works better at full
speed. 


> 4. Xilinx has a much more clear and agressive road map going
> forward. They're the clear technology leader in the FPGA space in
> my opinion.

I did not see a lot of difference in their products myself. Xilinx may
talk about their future products more, but I just don't see much
difference in their current products. The big reason I am using the Orca
parts now is the difference in IO count for a given package. I consider
this to be a significant reason to go with Lucent myself. 

Can you elaborate on why you feel Xilinx is the techology leader?


> 5. The level of support from other tool vendors (Synplify,
> ModelTech, etc.) is much greater for Xilinx than for Orca. Just
> look at the number of Xilinx-specific app notes on these vendors'
> web sites for an indication of their priority. Again, this is due
> to the large number of Xilinx users vs. Orca.

Yes, I would agree with this claim. I am not using HDLs, but that is
likely in the future. Or not perhaps. I am giving the full schematic
approach a try. Since Lucent provides Viewlogic as a frontend, I get a
lot of nice heirarchical tools with it. I will see if I can emulate the
success of Ray and a few others who won't give up their schematics. 

 
> One other general comment. Xilinx's sole business is programmable
> logic. FPGAs is a very small part of Lucent's business, and it
> shows. If Lucent ever really threw significant development/support
> and marketing resources at Orca I think they could almost compete
> with Xilinx. But the commitment just isn't there. I think you
> would be much happier and successful as a Xilinx customer.

I don't know that I agree with this. I remember when I spoke with the
Lucent people in the past, they seemed very committed to making their
products competitive to Xilinx and others. If you speak with the FPGA
group, they will be just as narrowly focused on FPGAs as anyone at
Xilinx. Then there are a lot of people elsewhere in the company who are
also supporters of the Orca FPGAs. I know because I am working with one
on this project. My DSP programmer (midnight consulting) works for
Lucent and is very excited about getting his hands dirty with their
FPGAs. 

But I will let you know how I feel after I finish this design. It will
be an evolving effort with at least three stages on the current board.
When I design the next board, I will reevaluate the then current
products to see if Xilinx is the better product for my application. 

Thank you for your opinion. I think you are right in many respects. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com


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