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 8650

Article: 8650
Subject: Xilinx software for less than 70 bucks
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 16 Jan 1998 12:13:19 -0800
Links: << >>  << T >>  << A >>
Please excuse this commercial message, but there has been so much
complaining about the "high cost of software" that I want to bring this
good deal to your attention.

XC4000 and XC9500 M1.3-based software
plus a good tutorial book for less than $ 70.

If you are interested, you can find a description at

http://www.prenhall.com/search.html

enter
xilinx
in the search box, then click on
Xilinx Student Edition
 

If you want to buy it, you might go to
http://www.amazon.com
enter the keyword
xilinx
into the search box near the bottom of the page, press search and read:
The Xilinx Student Edition ~ Ships in 2-3 days
                                   Prentice Hall / Paperback / Published
1997
                                   Our Price: $66.67

Good deal .
Just the tutorial book might be worth the money, so the software is
"free".
Presently, the upper device-size limit is XC4008 ( XC4000E as well as
XC4000XL ).

Peter Alfke, Xilinx Application

Article: 8651
Subject: Re: Using Xiling schematic library macro from VHDL
From: Terry Graessle <graessle@vlsi.gsfc.nasa.gov>
Date: Fri, 16 Jan 1998 15:39:51 -0500
Links: << >>  << T >>  << A >>
Remek Lipinski wrote:
<snip>
> 
> I get the following error :
> 
> ERROR:basnu - logical block "U1/CNT" of type "cc8cle" is unexpanded.
>

  I've seen similar errors occur when the ngdbuild program can't find a
component specified in your xnf file. You can specify an additional
search path with the -sd command line parameter to ngdbuild.  Type:

ngdbuild -sd <path to .xnf or .ngo files for components>  design.xnf

from the command line.  

  There is also a way to add to the search path through the M1 graphical
interface but I don't remember exactly how.  

  If you look in log file written out by ngdbuild (<design>.bld) it may
give you more information about what is causing the problem.

Hope this helps.

-- 
Terry L. Graessle         
Lockheed Martin - Space Mission Systems
NASA Code 564/ Microelectronics & Signal Processing Branch
graessle@vlsi.gsfc.nasa.gov                 (301) 286-9698
Article: 8652
Subject: Digital Signal Processing Help
From: bbkierst@aol.com (BBKierst)
Date: 16 Jan 1998 22:17:22 GMT
Links: << >>  << T >>  << A >>
Im in Denver Colorado and have 4 open positions in dsp.....is it ok to leave
this type of msg here...if not i apologize
Article: 8653
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Fri, 16 Jan 1998 19:08:03 -0500
Links: << >>  << T >>  << A >>
<snip>

> for example, for
> an xor tree (important for pci)

You must be referring to the PCI parity checking/generation, I guess that 
could be an XOR 'tree'....but it's hardly big or difficult....it takes 4 
CLBs to do...it would be a very wide and short tree (kind of like the 
Danny DiVeto of XOR trees ;-).

Is there any other XOR 'tree' you think is needed for PCI?  Just 
curious...

<snip>

Austin
Article: 8654
Subject: High Speed Digital Designers...
From: "Hunter Int." <cleaner@starnetinc.com>
Date: Fri, 16 Jan 1998 21:21:56 -0600
Links: << >>  << T >>  << A >>
Hi,

We have an opportunity for an individual who has done some complex Circuit
Board/FPGA design to work at a place where cutting edge technology is the
norm, and one of the very best design staffs in the country awaits.

This position is for someone who has between 3-10 years of high performance
custom circuit design under his/her belt.  You will be working on some of
the "neatest" projects you've ever seen, and will become a stellar hardware
designer for your efforts.

Some of the "buzz":  We are looking for High Speed Digital Designers,
having some experience with PLD's, FPGA's (ASICS), complex designs (nothing
simple at this place), understands timings, etc...  Not a person who still
needs a lot of instruction, we are hoping to find an individual who can
stand alone and bring a project in from scratch to production.

This is a great company!  Our guarantee is this:  If you go in and chat
with these people, you WILL want to work there, especially if you can do
this type of work.

They are located on the North side of Chicago, near Skokie or Evanston,
just off the Kennedy.  Salary will be very nice, they're not cheap, as
they're looking for the best we can bring in.

Please E-mail or Fax us at:

Hunter International
E-mail: cleaner@starnetinc.com
Fax: (815)356-9225

Thanks,

Dave...

















Article: 8655
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 17 Jan 1998 04:09:55 GMT
Links: << >>  << T >>  << A >>
Austin Franklin <dark7room@ix.netcom.com> wrote in article
<MPG.f29c06cfe051e3d989693@nntp.ix.netcom.com>...
: <snip>
: 
: > for example, for
: > an xor tree (important for pci)
: 
: You must be referring to the PCI parity checking/generation, I guess that

: could be an XOR 'tree'....but it's hardly big or difficult....it takes 4 
: CLBs to do...it would be a very wide and short tree (kind of like the 
: Danny DiVeto of XOR trees ;-).

hi austin,

well, part of the big snip was a discussion about portable designs,
schematic vs. hdl, etc., and some techniques you used for schematics to
make the basic macros more portable.  if i got the posts confused, then hit
the X in the upper right hand corner now. :-)

now, let's say it's doable in 4 CLB's.  but CLB's are not in all
architectures.  say you were using a pasic3, an act 3, a qyh500 (chipx
2-input nand gates only), a cx2001 (chipx module based architecture),
at6000, etc.  no CLB's.  but you gotta do, say, a 36-bit xor.  and do it
fast.  and if i remember what i wrote, that is a case that doesn't always
translate so well.  doing this fast in the act 3 architecture (which i had
to do) was not the most obvious thing in the world and in this case the
higher level tools did a really good job.  interestingly, my vhdl compiler
on home pc (166 MHz, 32 meg ram) complained and said, "no mas!"  the
obvious schematic version was ok but not that fast.  the macro generator
did a really good job and looking at the schematic it generated, really
exploited the architecture well and did it quickly.  a minute or so and it
was done.  doing this one by hand and trying to beat it would have taken a
lot of time.

anyways,

i think this was a point some of the other posters made about portability. 
if the tools are good, then it gives you the flexibility to change devices
without having to invest a lot of time in porting the design or even in
trading off different manufacturers.  and, interestingly, atmel has become
xilinx footprint compatible, perhaps offering some nice tradeoffs w/out
having to do a new board.

personally, i prefer to read schematics.  but i like the higher level tools
for doing the labor intensive blocks.  and i always put together the lower
level blocks on a schematic - drives me nuts when they are pasted together
in hdl as humans aren't that good at reading netlists.

--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8656
Subject: Re: Call for Papers: FPL-98
From: "N. Gat" <nahum@oksi.com>
Date: Fri, 16 Jan 1998 23:04:36 -0800
Links: << >>  << T >>  << A >>
Hello,

You may want to post your announcement at the TechExpo Calendar of
Science &Technology events at www.techexpo.com (select TechCALENDAR).
The site is visited daily by 1,000 to 3,000 scientists, engineerrs, and
technical managers.  Posting is free to qualified organizations.

Regards,

N. Gat, Ph.D.

(I apologise if this message reached you twice, or if I miised your
prior posting at TechExpo)



Article: 8657
Subject: Re: Xilinx software for less than 70 bucks
From: z80@ds.com (Peter)
Date: Sat, 17 Jan 1998 09:27:33 GMT
Links: << >>  << T >>  << A >>
Why not XC3000?
I mean, I *have* to find something to quibble about :)

Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiXYZserve.com but
remove the XYZ.
Article: 8658
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Sat, 17 Jan 1998 08:32:26 -0500
Links: << >>  << T >>  << A >>
> doing this fast in the act 3 architecture (which i had
> to do) was not the most obvious thing in the world and in this case the
> higher level tools did a really good job.  interestingly, my vhdl compiler
> on home pc (166 MHz, 32 meg ram) complained and said, "no mas!"  the
> obvious schematic version was ok but not that fast.  the macro generator
> did a really good job and looking at the schematic it generated, really
> exploited the architecture well and did it quickly.

I would like to believe that given an intimate understanding of the 
architecture and features of an FPGA, I should be able to understand how 
to do what ever it is I need to do...optimally.  Granted, some times the 
optimal way isn't obvious at first glance.

My opinion is that software currently is not good enough (as an example, 
placement algorithms still aren't anywhere near as good as a human can 
do....in both PC layout, and ASIC/FPGA layout...getting better though...) 
to 'rely' on it to provide an optimal solution.

As with PC software, (and a lot of ASIC designs), the only reason they 
work, is sheer size and speed....certainly NOT efficient, well done 
design.  FPGAs required efficient, well done design because they were 
slow, and small, kind of like coding for a microprocessor in assembler.

With the advent of very large, fast FPGAs, people will be able to get 
away with doing inefficient, poorly done designs.  What is called 'code 
bloat' (you really believe a word processor needs to be 150 MEGA BYTES?) 
will propagate to FPGA design.

No more having to understand the architecture and how to use it, just let 
the tools do it for you!  Less people will be able to blame the tools 
when their designs don't work...the FPGA size and speed will make up for 
their lack 'experience' (not my first choice of words though...;-)!

I have nothing against using 'advanced' tools if they are appropriate for 
the job, they just shouldn't supplant good engineering (understanding).  
Just because you can write some lines of HDL doesn't make you an 
engineer...

Remember a day (not so long ago...) when people who wrote code (as in C 
code) were called 'programmers'?  Well, today, anyone who writes a line 
of code is called a 'Software Engineer'....where's the engineering?  Not 
to say someone can't be a software engineer, but most truely aren't...

Austin
Article: 8659
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 17 Jan 1998 20:44:11 GMT
Links: << >>  << T >>  << A >>
hi austin,

here are some comments - i think we're actually in pretty good agreement
(more or less :-).  i'm sort of an "in the middle guy" and my designs are a
mix of schematics, generated macros, and hdl code.  and they are always put
together on a schematic, not structural vhdl.

it turns out that this approach is rewarded, by certain individuals at day
job, with heaps of scorn as all must be text hdl.  schematics are
blasphemy, crime against humanity, etc. etc.  and to have schematics in the
design flow makes some shudder.

with that said, on to more comments.

rk previously said:
: > doing this fast in the act 3 architecture (which i had
: > to do) was not the most obvious thing in the world and in this case the
: > higher level tools did a really good job.  interestingly, my vhdl
compiler
: > on home pc (166 MHz, 32 meg ram) complained and said, "no mas!"  the
: > obvious schematic version was ok but not that fast.  the macro
generator
: > did a really good job and looking at the schematic it generated, really
: > exploited the architecture well and did it quickly.

austin responded:
: I would like to believe that given an intimate understanding of the 
: architecture and features of an FPGA, I should be able to understand how 
: to do what ever it is I need to do...optimally.  Granted, some times the 
: optimal way isn't obvious at first glance.

rk follows up:
yeah, me too. and inside sort of hate it that the macro generator did so
good, so fast.  damn machine!  but for certain circuits the macro generator
and the vhdl synthesizer do well and do it fast.  i, for one, got really,
really tired of drafting large multiplexors and counters.  and don't mind
pushing those chores off on the macro generator or vhdl compiler.  we all
know how to do them but it's much faster to specify the counter or mux
(#bits, gray, prbs, linear, ripple, etc.) than to draft it.  notice the
word 'draft' because after a billion of the same type of circuits, it's not
engineering anymore.

the rk challenge:
well, here's an example, we can pit man against machine, for a
speed-critical circuit that is conceptually simple and using a logic block
that is relatively small.  this might be interesting, everybody can play
and use their favorite tools or a pencil and berol's logic template.  how
fast can a 36-bit xor be made in act 3?  there's not much to the
architecture for combinational circuits, here it is: a 4:1 mux, one select
line being the AND of two inputs, the other select line being the OR of two
inputs, and a single output.  i'll buy and mail a coke to whoever (or is it
whomever) has the fastest design.

austin continues:
: My opinion is that software currently is not good enough (as an example, 
: placement algorithms still aren't anywhere near as good as a human can 
: do....in both PC layout, and ASIC/FPGA layout...getting better though...)

: to 'rely' on it to provide an optimal solution.

rk responds:
placement algorithms for pcb layout and i have never gotten along.  do 100%
manual placement.  for pcb routing, pre-route critical stuff manually, and
finish with the auto-routers, which now do a pretty good job but their
output needs a bit of checking. the can, of course, be manually overridden.
 the one they use now at day job is really, really good and we've pretty
much abandoned hand routing boards.  router typically finishes in < 1 hour,
even for really dense boards.

for fpga, most of my p&r experience has been witht he actels, which have a
relatively low resistance connection relative to the sram and greater than
the q-logic stuff.  but, from route to route, i've seen pretty consistent
timing.  and, it has been outstanding at successfully completing a good
quality p&r for full chips (> 90%) that have needed major design changes as
a result of specification changes.  the one concession i give to the p&r
tool is to let it initally select the pins.  the ability to lock the pins
early and get conistent timing has been successful and they do do a good
job.  while pcb's typically contain dozens of ic's and are not bad to place
by hand, the number of modules in an fpga are typically > 500, making a
manual job too time consuming.  but i agree the user should be able to go
in and over-ride the placement of the tool.  actel started offering this
(chip edit) a number of years ago and it was nice to have, in fact more
than nice.  when they started their timing driven layout the didn't ship
this tool and let us say, er, there were a couple of emails and phone
calls.  and we used older software for a while longer.  eventually it came
back and is used.  for routing fpgas, i have no experience with that -
although it is observed that once in a while a particular net takes a
looooooooooooooong time to get through.  while i do not know that this is a
function of the router or the architecture, it usually takes a change of
netlist (like adding a redundant parallel buffer or gate to stay off of the
long tracks) to get things moving quickly.  perhaps you could relay your
experience with other technologies.


austin goes on: 
: As with PC software, (and a lot of ASIC designs), the only reason they 
: work, is sheer size and speed....certainly NOT efficient, well done 
: design.  FPGAs required efficient, well done design because they were 
: slow, and small, kind of like coding for a microprocessor in assembler.

rk says:
with regard to PC s/w, i'm almost embarrassed to say what kind of machine
we bought for the better half to do her dissertation on.  just running word
and sigma plot.  to run that, you need something that basically has cycle
times roughly equivalent to that of the cray-1!  for fpgas, the designs do
have to be relatively tight although my experience is that most designs
tend to be pin-limited, not gate limited, allowing some slop in the design.
 back before fpgas when we put gates on the boards, we would really crank
and have design-offs to shave off a fraction of an ic.  things are rarely
that important any more.  being 82% full or 88% full doesn't really matter
all that often and if new requirements come back in, you can always go back
and do a bit of scrubbing, replacing soft macros with hand coded macros,
for instance.  this kind of flexibility didn't exist w/ board designs.  as
for coding real-time uP's in assembler, that's not done too much anymore -
it's usually a mixture of C and assembler.  performance monitors (and i've
used some nice ones from hp) can tell you how long it takes to get through
a routine or what percentage of your time is in particular spot.  then you
know where to go in and do the more labor-intensive hand coding.  same for
fpga's.  the timing and size analysis tells you what is important to
optimize and what isn't.  and, getting back to the subject line, a slightly
less efficient vhdl design, for example, that is done much more quickly, is
a correct engineering choice over an optimized hand-crafted schematic
design.  also, as has been observed over the years, the assembler output of
a good compiler approaches that of a good humanoid.


back to austin after that long ramble: 
: With the advent of very large, fast FPGAs, people will be able to get 
: away with doing inefficient, poorly done designs.  What is called 'code 
: bloat' (you really believe a word processor needs to be 150 MEGA BYTES?) 
: will propagate to FPGA design.

rk agrees:
sadly, that is true.  less engineering on good algorithms.  less
engineering on good design.  just buy your way into a solution by getting
the bigger and faster chips.  and run down to the 'puter store for upgrades
everytime a new version of design software comes in.

austin: 
: No more having to understand the architecture and how to use it, just let

: the tools do it for you!  Less people will be able to blame the tools 
: when their designs don't work...the FPGA size and speed will make up for 
: their lack 'experience' (not my first choice of words though...;-)!

rk says:
had one case at day job where an engineer lived in the world of the tools,
was completely ignorant of the architecture.  actually, more than one case
;)  anyways, let us say the design was "less than successful."  problems in
observed cases ranged from poor designs to simply non-functional ones.  and
for performance-oriented applications, an INCREDIBLE amount of time and
person-power was spent trying to get it to work.  but, hmmm, ...,  i see
who just got the big-shot promotion :(

austin: 
: I have nothing against using 'advanced' tools if they are appropriate for

: the job, they just shouldn't supplant good engineering (understanding).  
: Just because you can write some lines of HDL doesn't make you an 
: engineer...

rk:
100% agreed.  i think we all remember, back in the '80s, the promises of
the silicon compiler ppl who claimed that any system engineer can design a
mega-chip by specification.  i still run into some of those articles when
cleaning up the basement.

austin: 
: Remember a day (not so long ago...) when people who wrote code (as in C 
: code) were called 'programmers'?  Well, today, anyone who writes a line 
: of code is called a 'Software Engineer'....where's the engineering?  Not 
: to say someone can't be a software engineer, but most truely aren't...

rk:
software engineer? jumbo shrimp? we used to distinguish between computer
scientists and computer programmers (b.s. comp sci, math; m.s. ee, so i'm
allowed a shot at s/w ppl). and then software engineering came up, we read
all the stuff, and well, i do mostly hardware now ;)

 
: Austin

have a nice weekend,

-------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
 
Article: 8660
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Sat, 17 Jan 1998 22:11:14 -0500
Links: << >>  << T >>  << A >>
> my designs are a
> mix of schematics, generated macros, and hdl code.  and they are always put
> together on a schematic, not structural vhdl.

Same here...

> austin responded:
> : I would like to believe that given an intimate understanding of the 
> : architecture and features of an FPGA, I should be able to understand how 
> : to do what ever it is I need to do...optimally.  Granted, some times the 
> : optimal way isn't obvious at first glance.
> 
> rk follows up:
> yeah, me too. and inside sort of hate it that the macro generator did so
> good, so fast.  damn machine!

You can design FOR an FPGA by understanding it's constraints/features...I 
guess that's my point.  One example is I have done a full PCI interface 
in a 4005...which DOES NOT have 32 long lines in it to implement the 32 
bit PCI bus...but each long line is a SPLIT long line...so I implemented 
half the chip in one side, and mirrored the other 16 bits in the 
other...and the control logic in the middle...workes VERY well..and is 
CHEAP!

> i, for one, got really,
> really tired of drafting large multiplexors and counters.

Cut and Paste....cut and paste....

> i'll buy and mail coke to whoever (or is it

It's bad form to promote drug use in a public forum ;-)

> rk responds:
> placement algorithms for pcb layout and i have never gotten along.  do 100%
> manual placement.  for pcb routing, pre-route critical stuff manually, and
> finish with the auto-routers, 

Agree completely....

> the one concession i give to the p&r
> tool is to let it initally select the pins.

Disagree completely.  I assign the pins always.  If I don't, I get pins 
in non-optimal, non-logical places.  I want my busses to be consistent, 
and it is always obvious how to group pins...  Also, I hand place ALL 
regular structures (bus elements...such as registers, counters, tri-state 
buffers etc.) and let the tools place the random logic...

> as
> for coding real-time uP's in assembler, that's not done too much anymore -
> it's usually a mixture of C and assembler.  performance monitors (and i've
> used some nice ones from hp) can tell you how long it takes to get through
> a routine or what percentage of your time is in particular spot.  then you
> know where to go in and do the more labor-intensive hand coding.  same for
> fpga's.

Understood, and agree completely.

> a slightly less efficient vhdl design

These words hardly go in the same sentence... ;-)  Certainly not when 
optimization, timing and architecture features are needed....

> software engineer? jumbo shrimp?

ROTFLMAO....thanks, made my night...

> have a nice weekend,

You too...

Austin

Article: 8661
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: "richard katz" <stellare@erols.com.NOSPAM>
Date: 18 Jan 1998 03:55:16 GMT
Links: << >>  << T >>  << A >>
lazy-man rk said:
: > i, for one, got really,
: > really tired of drafting large multiplexors and counters.

an energetic austin said:
: Cut and Paste....cut and paste....

tired, old rk says:
gets a bit tiring, making it fit, and then labelling all the instances and
nets (which i like to do, helps to communicate with the tools better, i
hate instance 3$I102 which is invisible on the schematic.


rk, who can't type well said: 
: > i'll buy and mail coke to whoever (or is it
 
eagle-eye austin says:
: It's bad form to promote drug use in a public forum ;-)

rk embarrassed, realizes he should have said, "diet coke" :-)

 
rk states:
> the one concession i give to the p&r
: > tool is to let it initally select the pins.

austin returns:
: Disagree completely.  I assign the pins always.  If I don't, I get pins 
: in non-optimal, non-logical places.  I want my busses to be consistent, 
: and it is always obvious how to group pins...  Also, I hand place ALL 
: regular structures (bus elements...such as registers, counters, tri-state

: buffers etc.) and let the tools place the random logic...

rk wonders:

hmmmm ... wonder if it's a difference in fpga architecture.  the actel doc
always said to let it pick the pins for the initial design.  many years
ago, first started with fpgas, i did some experimenting, picked the i/o
pins in a 'logical' bus configuration.  p&r didn't like it - one of the few
times it didn't complete.  so, i let the pcb router work a bit harder and
this works quite well.  the only draw back is you can't check out a bus on
the scope w/out having the pin list or schematic handy, it's all over the
place.

for hand placing the registers, counters, etc., ..., i almost never do
that.  that's the machine's job.  but, if an area needs improvement (i.e.,
increase hold times - a1020) or i want to do something special (i.e., make
all flip-flop clocks come off of the same segment) or if i want to optimize
a path for speed (say high-speed counter input) then i go in and do it by
hand.  but normally the tools should do that job and they do a reasonable
one, at least the ones that i use. 

anyways, interesting to compare methodologies.

 
rk stated:
: > a slightly less efficient vhdl design

austin makes wise-*ss remark: 
: These words hardly go in the same sentence... ;-)  Certainly not when 
: optimization, timing and architecture features are needed....

rk re-thinks:
perhaps a bit more than slightly - i looked at a bunch of the output and it
could definitely and easily be improved in some cases - others it was fine,
did a nice job.  but i haven't seen any cases yet where things got wildly
out of control.  now, the vhdl compiler i use is bundled with the vendor's
software and 'knows' about it to at least a certain extent.  and it has the
capability of recognizing key structures (i.e., counters, etc.) and calling
the optimized macro generators.  

just read an article (well, really an ad ;^) in electrical engineering
times called "synopsis overhauls strategy in fpga synthesis."  p. 46, dec
15, '97.  they addressed to a certain extent some of the issues you raised.


	"timing-optimization capabilities ahve gained a substantial boost
	with time tracker, a utility based on synopsys' primetime static
	timing analyzer.  time tracker estimates preroute delays and claims
	accuracy within 5 per cent to 15 per cent, depending on architecture.

i don't have first-hand experience with this but (if you choose the right
architecture) 5% estimate accuracy is pretty good.  i see vendor claims of
increasing prediction accuracy with their devices (dl5000, spga, etc.,
iirc) and that will further help this issue.

 
--------------------------------------------------------------
rk

"there's nothing like real data to screw up a great theory" 
- me (modified from original, slightly more colorful version)
--------------------------------------------------------------
Article: 8662
Subject: ByteBlaster
From: Gabby Shpirer <gabby@isv.dec.com>
Date: Sun, 18 Jan 1998 13:49:35 +0200
Links: << >>  << T >>  << A >>
Hi.

  Dose any one of you has the schematics of the ByteBlaster Plug.


Gabby

Article: 8663
Subject: VGA controller model needed
From: fangbin@public.bta.net.cn (Bin Fang)
Date: Sun, 18 Jan 1998 14:31:45 GMT
Links: << >>  << T >>  << A >>
Hello,

I'm looking for the VGA controller VHDL/Verilog model.
Does anyone have this model for free?

Thanks in advance.

B.Fang
Article: 8664
Subject: ahdl to vhdl
From: kkhan@airmail.net
Date: Sun, 18 Jan 1998 12:02:58 -0600
Links: << >>  << T >>  << A >>
Hi:

I am used to AHDL (Altera) but now I am required to do stuff in VHDL.  I
really don't want to waste time by converting my AHDL files to VHDL.  Is
there such a thing which will help me convert AHDL (Altera) to VHDL.
Article: 8665
Subject: Re: Foundation or Workview Office?
From: Nikos Mouratidis <nmo@teletel.gr>
Date: Mon, 19 Jan 1998 10:48:55 +0200
Links: << >>  << T >>  << A >>
Thank you very much for your quick answer. It really does help a lot.
I work for a greek company and we are in the process of selecting which
of the
mentioned packages to purchase.

>The VHDL-Schematic Interface is one of the best I have seen (the best being 
>Mentor Graphics).

Have you used Digital Fusion too?

>The only problem with foundation is its simulator. Viewsim has the edge
>but no by a wide margin.

Please, if it is not too much trouble, tell me if the problem you
mentioned has
to do with the user interface, the efficiency, the accuracy, or the
speed (or
any combination) of the simulator. Also, since there are occasional
problems
with the reception of news from our ISP, could you please answer me by
e-mail?

Thank you very much for your help. Although I do not know your exact
field of
interest, please feel free to ask us in case there is anything we might
be able
to help you with.

Best regards,

Nikos Mouratidis.
Article: 8666
Subject: Re: ASIC and PCB makers for Hobbyists wanted
From: dbl@hydra1.tyrvos.caltech.edu (Daniel Lang)
Date: 19 Jan 1998 01:49 PST
Links: << >>  << T >>  << A >>
In article <34C12FFB.6F6B@cyberjunkie.com>, XenoPhantom@cyberjunkie.com writes...
>Yes, after taking a look at the prices, I think I will reconsider FPGA,
>PLD, etc. The thing is, I wanted to integrate some analog circuitry in
>the system, so programmable logic will not allow that.
> 
>So, any more ideas? Still if someone has the key to ASICs, please let me
>know. I'm not talking about REALLY cheap, I mean anything reasonable,
>say within $400 or something. In fact, if there are any companies
>willing to make just one ASIC, whatever the price, tell me about them.
> 
>Hesham M Wahby
>Computer Engineering
>Cairo University
> 

As someone else mentioned, an ASIC will run $40,000 and up due to
NRE charges.  I do not know of any user programmable chips that
combine digital and analog on one chip but IMP makes an EPAC
programmable analog IC.  Digi-Key (www.digikey.com) sells an
EPAC device development starter kit for $256.

Lattice and Cypress make low cost digital CPLD development
software ($99 or so).  You may also be able to get a low cost
digital CPLD/FPGA development kit with a CPLD/FPGA on a PC/AT
board with digital I/O connectors.  You would then have to make
a daughterboard with the analog components.

I trimmed some of the newsgroups and added comp.arch.fpga which
deals with FPGA software.

Daniel Lang  dbl@anemos.caltech.edu

Article: 8667
Subject: Xilinx X3000: Does XACT6 accept the "L" or "SC=n" attribs?
From: z80@ds.com (Peter)
Date: Mon, 19 Jan 1998 13:28:11 GMT
Links: << >>  << T >>  << A >>
Hello,

I have been using Viewlogic 4 (DOS) and XACT6 PPR for XC3000 designs.

It has occurred to me that XACT6 might be ignoring these net
attributes, as attached to certain wires in Viewdraw.

I don't want to clutter a simple question, but the reason this came up
is that years ago, Xilinx app engineers were recommending that (if one
cannot use the global clock nets) it is OK to use a long line for it,
by using the L attribute. One could also put in a very tight skew
spec, like SC=1. This worked fine with the old APR (and with the
slower devices of the day), but with XACT6 PPR it often fails. I
recently heard that XACT6 now ignores these net attributes.

I know that the Xilinx preferred method today is timespecs.


Peter.

Return address is invalid to help stop junk mail.
E-mail replies to z80@digiXYZserve.com but
remove the XYZ.
Article: 8668
Subject: Re: FPGA core for ASIC?
From: "D.H. Chung" <dhchung@soback.kornet.nm.kr>
Date: Mon, 19 Jan 1998 23:10:52 +0900
Links: << >>  << T >>  << A >>
You can have the IP vendor list from Altera's AMPP partner catalog, who
provide core for Altera PLDs.

Thanks
D.H.
Dmitry Cherniavsky ÀÌ(°¡) ¸Þ½ÃÁö¿¡¼­ ÀÛ¼ºÇÏ¿´½À´Ï´Ù...
>  There are now a lot of IP cores makers around, that make business on
>providing cores for the system-on-a-chip. Does anybody produce FPGA
>cores, since FPGA is also part of system often. Does it possible at all?
>--
> Dmitry Cherniavsky,
> ASIC designer.
> MailTo:cdm@javad.ru


Article: 8669
Subject: Do you know ATMEL?
From: "Eric Kim / ±èÀÀȯ" <erickim@netsgo.com>
Date: Tue, 20 Jan 1998 00:12:31 +0900
Links: << >>  << T >>  << A >>
If you want to find out better solutions than MAX7000, XC4000, XC5000,
and Proms for FPGA due to matters of performance and price, visit to
www.atmel.com. You can meet a lot of EPLD and a new architecture
FPGA based on Flash technology.

Go to enjoy it right now.


Article: 8670
Subject: Vantis Enters FPGA Market Unveiling New Variable-Grain-Architecture Devices With Industry Leading Performance
From: scott.thomas@vantis.nospam.com (Scott Thomas)
Date: Mon, 19 Jan 1998 15:14:20 GMT
Links: << >>  << T >>  << A >>

    New Product Family, Expandable to 250,000 Gates, Combined With
    Internally Designed Software Delivers Total Customer Solution

    Vantis, an AMD company, today is entering the FPGA market with an
innovative family of Variable-Grain-Architecture(TM) devices, the VF1
Series, and powerful new Design-Direct(TM) software.
    With 250 MHz pipeline performance, the VF1 family provides 50-100
percent faster system speed than any other mainstream FPGA vendor's
devices. Vantis' new architecture employs a variable grain structure
critical for the highest silicon efficiency and performance. The
unique architecture provides the ability to vary the FPGA logic block
configuration to adapt to a large variety of possible applications and
design styles.
    Based on 0.18 micron process technology, the first VF1 product
family announced today, with accompanying software, includes devices
up to 36,000 gates (functionally equivalent to 50,000 gates when
on-chip memory is included). The Variable-Grain-Architecture is
expandable up to 250,000 gates in this process generation.
    "This announcement makes Vantis the only full-line PLD supplier
that can service the needs of the most demanding customers in the
marketplace today," said Rich Forte, president and CEO at Vantis. "In
addition, through our relationship with AMD, Vantis has access to
AMD's most advanced process technologies, enabling us to provide the
highest performance programmable logic solutions in the industry."
    Vantis also introduced today its new Design-Direct software, an
internally developed implementation software that exploits the
performance of the new architecture. The combination of Vantis'
Variable-Grain-Architecture and robust implementation software results
in synthesis-friendly, easy-to-use tools which produce high quality
results. The Design-Direct software is a push-button, out-of-the-box
design solution that supports standards-based, high level design
methodologies such as VHDL and Verilog. Design-Direct software is
available on UNIX, Win95 and WinNT operating systems.
    "We took a software-centric approach to the design of the device
architecture," said Andy Robin, vice president of marketing at Vantis.
"As a result, the combination of our new software and FPGAs provides
better integration and Ease-of-Success(TM) solutions, delivering fast
time-to-market for our customers."
    Key architecture features of the VF1 family include: the
Variable-Grain-Block(TM) (VGB(TM)), high-performance embedded memory,
and Variable-Length-Interconnect(TM) features.

Variable-Grain-Block (VGB)

    At the core of the Vantis architecture is the VGB. Each logic
region in the VGB is capable of efficiently implementing all possible
fine-grained three-input functions to many very coarse-grained
16-input functions, all providing extremely high performance. In
addition, two VGBs may be combined through dedicated high-speed logic
and interconnect to form 32-bit wide functions. The ability of the
architecture to vary its width from three to 32 inputs enables the
most efficient and high-speed implementation of customer logic
possible.

High Performance Embedded Memory

    The VF1 chip is designed with 200 MHz memory. The memory is
optimized for two-port configurations and is programmable for one-
port and two-port applications. It is capable of simultaneous
read/write operation and synchronous or asynchronous operation.
Additionally, it has 128 bits per block, can be parameterized for
increased width and/or depth. It is strategically located in vertical
channels of the device providing maximum connectivity for the
surrounding logic. Also, it has dedicated routing resources to aid in
memory configuration and connection to the surrounding logic, and can
access the general routing resources as needed.

Variable-Length-Interconnect

    The routing system provides extremely fast and flexible routing
resources that compliment hierarchical design styles. It allows for
highly predictable performance and Fit-First-Time(TM) designs without
manual intervention. There are four groups of general routing
hierarchy available to the router. In addition, global connectivity
includes four clocks that go to every flip-flop in the device allowing
multiple clock domains within designs. On-chip phase locked loops
manage these clocks to frequencies up to 200 MHz and also provide
system level, chip-to-chip de-skewing capability.
    Among other powerful features, variable length resources are
available between sets of VGBs. These resources vary in length from
connecting adjacent VGBs to connecting all VGBs in any row or column.
To ensure maximum performance, an Inter-VGB Direct-Connect routing
hierarchical level has been integrated within the architecture. It
allows direct high-speed routing up to two VGBs away in both vertical
and horizontal directions.
    In addition to higher performance, this provides improved
routability and less timing variability.


First VF1 Products
                       VF1012      VF1020      VF1025      VF1036(a)
                       ------      ------      ------      ------ 
Logic Gates            12,000      20,000      25,000      36,000
RAM Bits                3,584       4,608       5,120       6,144
Logic FFs                 784       1,296       1,600       2,304
User I/Os                 172         208         244         292

(a) Functionally equivalent to 50,000 gates when on-chip memory is 
included




Pricing and Availability

    Device samples will be available in 2Q98. Volume production is
planned for 3Q98. Pricing for the VF1 family of devices starts at $46
for volume quantities in 2H98.

A Total Solution

    The integration of industry standard tools with concurrently
developed VF1 architecture-optimized software has resulted in Vantis
design kits that produce high performance and high quality-of-results
with minimal design time. Design-Direct software has proved to deliver
competitive run-times while fitting the first time on over 95 percent
of qualified designs.
    Design-Direct software leverages leading synthesis tools for
synthesizing, mapping and optimizing high-level descriptions to the
most efficient structure needed for designers' applications. Supported
simulation tools include Synopsys, Exemplar, ViewLogic, Synplicity and
Synario. High level design languages include Verilog and VHDL formats.

Hierarchical Design

    The Vantis design system supports hierarchical design
methodologies. Hierarchical design begins with applying system-level
requirements to the FPGA design. System specifications for
performance, power and size are budgeted to the FPGA and then sub-
budgeted to the various hierarchical blocks of the design. As the
design moves up the established hierarchy, lower-level blocks are
combined with other blocks and support logic to create higher-level
blocks until the entire design is captured.
    Final hierarchical layout begins after completion of design
capture and preliminary simulation. The Vantis design manager manages
the timing-driven implementation phase of the design process accepting
netlists and constraint files and returning back-annotated netlists.
Incremental design is supported throughout, enabling fast design
updates with minimal interruption.

Core Program

    Industry standard timing-critical cores, such as PCI (Peripheral
Component Interface), are developed and optimized for the Vantis
architecture in partnership with third-party intellectual property
providers. The first fully-verified cores for the Vantis FPGA family
will be 66 MHz PCI master/target and target cores, available with beta
Design-Direct software.

Design Manager

    The Vantis design manager is a powerful, easy-to-learn tool that
manages the overall design within the Vantis design environment. It
provides designer control over design selection and processing. The
designer simply specifies the effort level and the design manager
selects the appropriate algorithms and controls best suited for the
design and architecture. 
    The design flow can be fully automatic or the user can be as
involved in each step as desired. Some of the design steps controlled
by the design manager include: design optimization, floorplanning,
timing-driven placement, mapping and routing, timing generation, back
annotation and bit-stream generation.

Pricing and Availability

    Vantis Design-Direct beta software is currently available to
selected customers enabling designs on all device sizes. Vantis FPGA
software solutions start at $1,495. Production software is planned for
2Q98.

About Vantis

    Vantis, an AMD company, provides the industry's broadest offering
of high performance field programmable gate array (FPGA) and
programmable logic device (PLD) solutions for communications,
computing and industrial applications. Vantis was formed in March 1996
with a focus on designing and manufacturing advanced programmable
logic products that satisfy the speed, density and ease of use
requirements for today's logic designs. As an AMD company, Vantis has
access to AMD's world class process technology, state-of-the-art
manufacturing facilities and worldwide customer support.

Cautionary Statement

    This news release contains forward-looking statements regarding
programmable logic products that involve risks and uncertainties that
could cause actual results to differ materially, including, the timely
development and market acceptance of new programmable logic products,
the impact of competitive products and pricing, the timely development
of wafer fabrication process technologies, the effect of changing
economic conditions, and such risks and uncertainties detailed from
time-to-time in the company's SEC reports.

    WORLD WIDE WEB: Press announcements and other information about
Vantis are available on the Internet via the World Wide Web. Type
http://www.vantis.com at the URL prompt.
    NOTE TO EDITORS: Readers may obtain additional information by
calling 1-888/826-8472 or 408/732-0555. 
    Variable-Grain-Architecture, Design-Direct, Ease-of-Success,
Variable-Grain-Block, Variable-Length-Interconnect and First-Time-Fit
are trademarks of Vantis.
    GENERAL NOTICE: Other product names used in this publication are
for identification purposes only and may be trademarks of their
respective companies.

Article: 8671
Subject: Re: hdl, schematic, simulation, graphical front ends: (was xilinx stock)
From: dark7room@ix.netcom.com (Austin Franklin)
Date: Mon, 19 Jan 1998 11:23:19 -0500
Links: << >>  << T >>  << A >>
> gets a bit tiring, making it fit, and then labelling all the instances and
> nets (which i like to do, helps to communicate with the tools better, i
> hate instance 3$I102 which is invisible on the schematic.

Agree, hence, the use of labels on all structured instances.....  You can 
reference the hierarchical labels when doing placement....works very 
well.

> 
> rk, who can't type well said: 
> : > i'll buy and mail coke to whoever (or is it
>  
> eagle-eye austin says:
> : It's bad form to promote drug use in a public forum ;-)
> 
> rk embarrassed, realizes he should have said, "diet coke" :-)

My drug of choice ;-)

>  
> rk states:
> > the one concession i give to the p&r
> : > tool is to let it initally select the pins.
> 
> austin returns:
> : Disagree completely.  I assign the pins always.  If I don't, I get pins 
> : in non-optimal, non-logical places.  I want my busses to be consistent, 
> : and it is always obvious how to group pins...  Also, I hand place ALL 
> : regular structures (bus elements...such as registers, counters, tri-state
> 
> : buffers etc.) and let the tools place the random logic...
> 
> rk wonders:
> 
> hmmmm ... wonder if it's a difference in fpga architecture.  the actel doc
> always said to let it pick the pins for the initial design.

AH!  As does the Xilinx doc!  They are wrong, it is certainly better to 
do pin assignment your self, given, of course, an intimate understanding 
of the architecture and design, and how it should be placed...

> many years
> ago, first started with fpgas, i did some experimenting, picked the i/o
> pins in a 'logical' bus configuration.  p&r didn't like it - one of the few
> times it didn't complete.

Probably because you didn't do internal placement...I've seen that too...

> so, i let the pcb router work a bit harder and
> this works quite well.  the only draw back is you can't check out a bus on
> the scope w/out having the pin list or schematic handy, it's all over the
> place.

Hence my reason for assigning pins my self.  It makes the inside, as well 
as the outside of the chip cleaner, faster, and use less resources.

> for hand placing the registers, counters, etc., ..., i almost never do
> that.  that's the machine's job.

Cough, cough....  well, you are missing out on the best performance 
and resource enhancement technique you can possibly to for an FPGA.  
Almost every job I take that is a re-do of a failed design due to timing 
gets a floorplan, and magically, it all makes timing....and routes in 
minutes...

<snip>

> just read an article (well, really an ad ;^) in electrical engineering
> times called "synopsis overhauls strategy in fpga synthesis."  p. 46, dec
> 15, '97.  they addressed to a certain extent some of the issues you raised.
> 
> 
> 	"timing-optimization capabilities ahve gained a substantial boost
> 	with time tracker, a utility based on synopsys' primetime static
> 	timing analyzer.  time tracker estimates preroute delays and claims
> 	accuracy within 5 per cent to 15 per cent, depending on architecture.

That doesn't really say anything....  That's like saying 'this new 
product has 300% less calories and improves your outlook on life' both 
amorphous statements when NOT compared to a baseline.....  I'm sure pork 
rinds have 300% less calories than something, and eating pork rhinds 
after eating leaves might just improve your outlook on life, unless 
you're a giraffe....;-)

Austin
Article: 8672
Subject: Xilinx Info.
From: Srikanth Gurrapu <gurrapu@ti.com>
Date: Mon, 19 Jan 1998 10:46:13 -0600
Links: << >>  << T >>  << A >>
Hi, All,

We are currently doing  a project which requires implementation of
around 
25K gate-logic and 2K-byte RAM.

We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software.
But, looks like the XACT5.2.1 has support only upto XC4025E with 25K
gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can
somebody 
recommend how much would be fetch factor when we put the logic
into the Xilinx CLBs?

So, we need to split the logic into two FPGAs which we don't want to do
now. 
Also, one more disadv of XACT5.2.1 is no support for back-annotation if
we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler.
After synthesis, is there any way to do a pre-layout functional
simualtion to make sure the design netlist is Ok?

Also, can somebody recommend if there are any Altera devices which can
do this efficiently 
than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM...

We can buy Xilinx new software M1.3 which has support for larger FPGAs
and VITAL-support
for backannotation, but is any Altera-approach going to be cheaper?

Any opinions, suggestions or pointers are welcome.

Thanks,
Srikanth Gurrapu,
Texas Instruments, Inc.
gurrapu@ti.com.
Article: 8673
Subject: Xilinx Info.
From: Srikanth Gurrapu <gurrapu@ti.com>
Date: Mon, 19 Jan 1998 10:48:39 -0600
Links: << >>  << T >>  << A >>
Hi, All,

We are currently doing  a project which requires implementation of
around 
25K gate-logic and 2K-byte RAM.

We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software.
But, looks like the XACT5.2.1 has support only upto XC4025E with 25K
gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can
somebody 
recommend how much would be fetch factor when we put the logic
into the Xilinx CLBs?

So, we need to split the logic into two FPGAs which we don't want to do
now. 
Also, one more disadv of XACT5.2.1 is no support for back-annotation if
we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler.
After synthesis, is there any way to do a pre-layout functional
simualtion to make sure the design netlist is Ok?

Also, can somebody recommend if there are any Altera devices which can
do this efficiently 
than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM...

We can buy Xilinx new software M1.3 which has support for larger FPGAs
and VITAL-support
for backannotation, but is any Altera-approach going to be cheaper?

Any opinions, suggestions or pointers are welcome.

Thanks,
Srikanth Gurrapu,
Texas Instruments, Inc.
gurrapu@ti.com.
Article: 8674
Subject: FPGA Info.
From: Srikanth Gurrapu <gurrapu@ti.com>
Date: Mon, 19 Jan 1998 10:50:21 -0600
Links: << >>  << T >>  << A >>
Hi, All,

We are currently doing  a project which requires implementation of
around 
25K gate-logic and 2K-byte RAM.

We initially planned to use Xilinx FPGAs as we have XACT5.2.1 software.
But, looks like the XACT5.2.1 has support only upto XC4025E with 25K
gate capacity.. The 2K RAM itself is taking around 510 CLBs. Can
somebody 
recommend how much would be fetch factor when we put the logic
into the Xilinx CLBs?

So, we need to split the logic into two FPGAs which we don't want to do
now. 
Also, one more disadv of XACT5.2.1 is no support for back-annotation if
we use a Cadence Leapfrog VHDL simluator and Synopsys FPGA compiler.
After synthesis, is there any way to do a pre-layout functional
simualtion to make sure the design netlist is Ok?

Also, can somebody recommend if there are any Altera devices which can
do this efficiently 
than Xilinx FPGAs, like 25 K gate count + 2K-byte RAM...

We can buy Xilinx new software M1.3 which has support for larger FPGAs
and VITAL-support
for backannotation, but is any Altera-approach going to be cheaper?

Any opinions, suggestions or pointers are welcome.

Thanks,
Srikanth Gurrapu,
Texas Instruments, Inc.
gurrapu@ti.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