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
2017JanFebMarApr2017

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 30475

Article: 30475
Subject: Re: free software
From: Srinivasan Venkataramanan <srini@realchip.co.in>
Date: Tue, 10 Apr 2001 13:51:59 +0530
Links: << >>  << T >>  << A >>
Hi,
  I am not a  FPGA Designer so can't suggest best FPGA, but about the
second question:

> Does there exist some free VHDL software ? Hopefully with simulator.
> 

Try Xilinx Webpack
http://www.xilinx.com/products/software/webpowered.htm

and/or VHDLSimli at http://www.symphonyeda.com -- Best FREE VHDL
Simulator!

HTH,
Srini

Soren 'Disky' Reinke wrote:
> 
> Hi there.
> 
> I am a total FPGA newbie, so i have a few questions.
> 
> What would be the best fpga to start with ?
> I just wanna play with simple things in the beginning like counters, small
> controllers and stuff like that.
> 
> It should be cheap and also easy to connect to a PC to program it.
> 

> Please help me.
> 
> --
> With many Thanks
> 
> Soren ' Disky ' Reinke  ICQ #1413069
> Remove IHSYD from email address when replying by email

-- 
Srinivasan Venkataramanan (Srini)
ASIC Design Engineer,
Chennai (Madras), India

Article: 30476
Subject: Re: Modlesim5.5
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Tue, 10 Apr 2001 14:04:30 +0300
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> Nicolas Matringe wrote:
> 
> > "W.Turk" wrote:
> > >
> > > Hi Gang:
> > >    Now ,i use Modelsim5.5.When i load or run a large design,it
> > > will always close automatic.
> > >    Why?
> >
> > I have the same problem and I think, as Utku suggested, that it is RAM
> > related.
> > It usually happens when I restart the simulation. It works fine after
> > freeing some RAM.
> >
> > -
> 
> Oh dear it looks like the memory leak, fixed in 5.4, has come back. If you
> are running under NT use task manager to see what the vsim memory useage
> is. What used to happen is that on every restart you could see 10-15MBytes
> being added.

  I wonder if this RAM consume increase by restart would also happen
  under UNIX? Or this is restricted to Windows-based OSs?

  Utku

Article: 30477
Subject: Re: Handel-C
From: Jamie Lokier <spamfilter.apr2001@tantalophile.demon.co.uk>
Date: 10 Apr 2001 19:21:49 +0200
Links: << >>  << T >>  << A >>

I've used Handel-C for a few years now, starting with a pre-release
version 2.0 and now adapting code to version 3, the DK1 version.  Our
team here at CERN are going strong with it now.  We build network
testing equipment, that means MACs, memory interfaces, network
protocols, traffic shaping and queueing, timing measurements, that sort
of thing.  One of our boards has 35 Altera Flex10k50s.  For my own part,
I have been involved at most levels of designs from schematics up to
VHDL and Handel-C (on FPGAs and CPLDs), to the software that runs the
show on a cluster of PCs.

I've had to do some very dirty things with Handel-C, because it didn't
(by itself) support all that we needed.  Things like combining with
VHDL, and dual-port RAMs.  But the latest edition "DK1", which is a
much-changed language, seems to have a lot of the needed features built
in now.  (I've not used it enough to be sure, and some dirty things
are still required).

Its about time to clear up a few misconceptions about Handel-C.

Richard Erlacher writes:
> However, if they ever figure out how to make a language operate in
> parallel rather than serial fashion, it may evolve into something
> useful for this task.

Handel-C _is_ a parallel language.

Handel-C has explicit parallel statements, starting with "par".  The
parallelism is very clear and easy to read.  (IMO, what behavioural VHDL
should have been, with clean branch and join points in the control flow).

Judging from the responses here, a lot of hardware types see "C" and
assume that Handel-C is not a hardware language.  You should get
familier with keywords like "par", "signal", "clock", "interface",
"chan" before assuming that Handel-C has much to do with C.

As Adrian E. Lawrence notes, it's thinly disguised Occam.
It's a lot nicer to read than Occam :-)

Actually it used to be that, but newer features are rather unlike Occam.
Version 3 of the language (the DK1 tool) introduces "signals", which
have different timing semantics to variables (not unlike VHDL's
variables and signals).

S. Ramirez <sramirez@cfl.rr.com> writes:
>     I personally think that HDLs will evolve to C eventually, but the
> real problem is that HDL is only a part of FPGA design.  Just ask
> anyone in this newsgroup about all of the problems involved with FPGA
> design.  The majority of them are not HDL problems.  Therefore, one
> cannot take a programmer (read: non hardware engineer), teach him/her
> Handel-C and expect him/her to simply start cranking out FPGA designs.
> That person will have to know about timing problems, metastability,
> floorplanning and a bunch of other skills that are commonly required
> to complete an FPGA design.  Essentially, that person has to be a
> hardware person.

There are levels of hardware knowledge.  If you've been supplied with a
board with FPGAs on, designed by people who knew what they were doing,
you don't need to know about termination resistors, lead inductance etc.
The digital logic simply works to a specified limit.  Until it doesn't,
but then you call in the board designers and get them to fiddle with the
scope :-)

It is _very_ good to have at least one person who understands FPGA
design constraints, floorplanning perhaps (though I don't bother -- I
use Alteras and their current PAR kit ignores most fitting constraints
anyway ;), and what typical Handel-C code maps to on the FPGA.  This
sort of knowledge seems especially important at the I/O interfaces to
other chips, and when explaining the importants of pipelines et al.

Were you to follow the Celoxica "reconfigurable computer" route, you'd
have received delivery of a package where I/O interfaces are also solved
for you, in a library.  I've never used a packet like this: our reality
means that boards are custom-designed for specific problems, and every
board is different.

"niki" <guest@my.net> writes:
> I totally agree with you. HDL is for hardware modelling. It is 100%
> different from what software guys think in C prgramming. It is not that
> different from schematic drawing of hardware components. If you don't have
> a good idea about what hardware should be, you can't be a good HDL
> designer. (designer! not programmer...)

I've noticed the "firmware" folk, who know Handel-C and have a passing
familiarity with VHDL do understand how most of our more sophisticated
I/O interfaces work (written in highly-hacked Handel-C or
multi-clock-domain VHDL), but I'd guess they'd take an age to actually
write them.

I've also noticed that things like barrel shifters and pipelining are
still a big deal to them, so I do see there's still a gulf between
software-level design and thinking in terms of depth of logic.  I've
also noticed that, although they fully understand Handel-C's kind of
parallelism, they are sometimes reluctant to use it.  By contrast, a
VHDL designer prefers parallelism because its simpler than sequencing.

Having someone around who understands the FPGAs well seems to be pretty
helpful for the others.  <ahem> But enough about me ;)

For the day to day "lets histogram the packet latencies today", or "we
need to match the diffserv field", or "can you add VLAN support?",
really no knowledge of the FPGA is required beyond knowing how much RAM
you have.  This is where Handel-C excels at the moment, IMO.

Sometimes it really is a case of "we need feature X, how long?" and the
stunned looks you get when you implement the feature before they've
finished explaining the question are most satisfying :-)

cyber_spook <pjc@cyberspook.freeserve.co.uk> writes:
> Currently I work as a IT suport Eng. (Yuk!) but I'm watching Handle-C
> make a differance were I work - The hardware department look a little
> worried as one of the softy's is going grate guns with his evaluation
> copy of Handle-C.

I think you will see more and more of that.  In my experience, having
worked with both VHDL and Handel-C, writing Handel-C is a rather
speedier process.  I'd bet your softy has a fairly good idea what's
going on at the FPGA level, and if not it will come to them as they get
closer and closer to the timing constraints.  Logic depth, pipelining
and sensible simple parallelism come to mind as Handel-C level concepts
that map well to FPGAs.

Rick Filipkiewicz <rick@algor.co.uk> writes:
> (*) This is not just to do with timing, metastability, etc. My fear
> here is that s/w types do not have the deep, ingrained, awareness that
> from day 1, hour 1, minute 1 of design start any mistake they make
> could be fatal. s/w bug = fix it & put a patch file on the Web, h/w
> bug = a $250K+ ASIC respin.

This _really_ doesn't matter with FPGAs.  10 minute design cycle, about
5 times slower than writing C on a fast day.  Sure you _can_ scrutinise
the code carefully for hours, but sometimes it's easier to write the
obvious code, if it works great otherwise pull out the scope and ask
"what should I be seeing on the scope about here?".

It never costs $250k.  Maybe $2000 when you realise you need a faster
FPGA :-)

> To support hardware modeling, it was necessary to extend C to allow
> the programmer to model the passage of time and the execution of
> statements in concurrent processes.  Not that such a thing couldn't be
> done in C (Verilog is sometimes referred to as "C+-" ;-) , but the C
> extensions need to be done in a "standard" way, to encourage the
> support of third-party vendors (cell libraries, verification,
> synthesis...)

One of Handel-C's characteristics is that passage of time does not
appear explicitly in most programs.  This is a big contrast with
Verilog, and it does (IMHO) make the Handel-C quite nice to read.
There's a "delay" statement but it's not often used.

Robert Carney <bobcarney@worldnet.att.net> writes:
> What I actually don't understand is why the C-based tools are needed ?
> Verilog is so easy to write that at the pure coding level any
> reasonably competent C/C++ programmer could pick it up in a couple of
> days. Then with a couple of years practice they might, if they have
> the right mentality (*), get to produce h/w that's not an embarrasment
> to their company.

Canned answers:

  (a) It doesn't take a couple of years to produce good code with Handel-C
      (IMO it doesn't with Verilog either).

  (b) Handel-C is sometimes verbose than Verilog for similar functionality.

  (c) Verilog expects you to understand the basics of clock signals and
      so on.  As it happens you can get by in Handel-C without
      understanding how the logic is synthesised, nor with much
      awareness of the clock signal.  Don't expect to write a SERDES
      this way of course :-) But it's useful for writing DSP-like
      algorithms or network protocol processing on FPGAs, for example.
      You can still optimise the timing, without the clock signal being
      in your face.

  (d) Counterpoint: You have a good point about Verilog being pretty
      close to these C-like languages though.

Rick Filipkiewicz <rick@algor.co.uk> writes:
> I would agree & I would go further even than Simon. Although looking at
> Handel-C itself it seems that it would do the job it seems that the
> marketing strategy of these C-based HDL tools companies has very little
> to do with the technicalities.  They are mostly trying to talk to
> managers and saying:
>
> ``Hey guys here are some tools that will allow you to throw away all
> those expensive, rare h/w types & replace them with off-the-shelf
> el-cheapo s/w grunts''

I agree.  Before they were called Celoxica, Celoxica's site had
"application notes" with nothing of the technical depth we'd expect.
Thankfully they have renamed them "case studies" now.  Also, don't
expect to learn the Handel-C language from documents on the web site!
(AFAIK you have to register to see the language reference manual).  It
seems very much a marketing and community-building exercise.  To be
fair, they do have an active on-line community via their site, should
you wish to register.

I have similar reservations about C Level Design.  Anyone have a manual
for their Cycle-C product?  I couldn't find anything except brochures,
fluff and screen shots on their web site.  I daresay if I emailed them I
_might_ get a manual and maybe a trial version, but I don't have much
time for the attitude that isn't encouraging me discover the tool for
myself.

Robert Carney <bobcarney@worldnet.att.net> writes some more:
> the C extensions need to be done in a "standard" way, to encourage the
> support of third-party vendors (cell libraries, verification,
> synthesis...)

At the moment each company has its own language, its own GUI, and a big
lack of handy on-line tutorials.  Like they'd rather not have everyone
using their languages.  Perhaps they want hardware engineers kept well
away, you know how they'll just pick on the bad points without
appreciating the good points ;-) At one time, I saw on C Level Design's
web site that they weren't revealing how their Cycle-C language worked:
it was only going to be used by their internal design teams.  This seems
to have changed with their reported new relationship with Altera.

There may be some hope for standards in this field, according to
articles about C Level Design:

  http://www.dacafe.com/DACafe/NEWS/CorpNews2/20010319_2237.html
  http://www.dacafe.com/DACafe/NEWS/CorpNews2/20010319_2213.html

When some kind of standard emerges, if anyone wants to support the
development of an open source tool, do let me know :-)

cheers,
-- Jamie

Article: 30478
Subject: Re: free software
From: Jamie Lokier <spamfilter.apr2001@tantalophile.demon.co.uk>
Date: 10 Apr 2001 19:24:22 +0200
Links: << >>  << T >>  << A >>
Kristian Rye Vennesland writes:

> Hi Soren,
> I would recommend an Altera FPGA, preferrably a MAX. They are easily
> programmed trough a cable, which you can make yourself,
> and the development software is free and easy
> to use. I don't think the free version supports VHDL though.

If you have a little bit of cash and good soldering skills, I don't
recommand a MAX as they're rather small, and if you get any further than
a few counters you'll run out of space.  Go for a Flex instead.  There's
at least one "academic evaluation" board around with a Flex on it and
LEDs etc, maybe you can get hold of one.  Xilinx have something similar.

cheers,
-- Jamie

Article: 30479
Subject: CONTRACTORS
From: "Mark Harrison" <marklisa@erols.com>
Date: Tue, 10 Apr 2001 13:27:35 -0400
Links: << >>  << T >>  << A >>
I am looking for a variety of SW/HW contractors for contracts in the DC
Metro area.  If interested please reply.

-Mark




Article: 30480
Subject: Re: VHDL falling edge in Xilinx Foundation...
From: "Jan Kindt" <jan.kindtnospam@pandora.be>
Date: Tue, 10 Apr 2001 18:43:25 GMT
Links: << >>  << T >>  << A >>
you just use falling_edge instead ofrising_edge...

process (clk)
begin
    if falling_edge(clk then
        synchronous statements on falling edge go here....
    end if;
end process;

"Damir Danijel Zagar" <damir.zagar@tipro.hr> schreef in bericht
news:9as8n5$5h3v$1@as121.tel.hr...
> How to synthesize project which uses falling edge clocking
> using Xilinx Foundation 3.x?
>
> Damir
>
>



Article: 30481
Subject: Obj: Handel-C
From: Fabrice MONTEIRO <fabrice.monteiro@ieee.org>
Date: Tue, 10 Apr 2001 20:50:37 +0200
Links: << >>  << T >>  << A >>
There is a lot of confusion made on what HDL and synthesis are.

When one writes a HDL model, he may be describing an algorithm, an
architecture or both. The abstraction level of the model can range
from technological gates to large abstract functional blocks.

If a model is designed for simulation purpose only, no limits should
apply on the complexity it can reach (except those related to the
performance of the computer on which the simulation is to be done).
In VHDL, for instance, it possible to design a simulable model of a
system, should it be modeled from logical gates or from complex
sequential processes (I suppose this is also true for Verilog). 

If synthesis is considered, an important information must be taken
into account: what are the synthesis tool assumptions applying to the
input time model !...

These assumptions are implicitly contained in what is usually called
"level of modelisation". Indeed, most of the confusion comes from not
explicitly telling what "level of modelisation" is considered.

Actually, most of the synthesis tools rely on RTL modelisation, but
it is not the only modelisation level that can be considered. There
are some major levels applying to modelisation of digital systems:

- logical
- RTL
- behavioral

In a logical level description, all the VHDL processes should describe
only purely combinatorial "blocks" (of any complexity). Each process
describes the "algorithm" of a combinatorial "block". Complex systems
are designed interconnecting all this combinatorial blocks.

-- example of a VHDL combinatorial process
-- where a, b and s are std_logic signals
comb: process (a,b)
begin
  if a=b then
     s <= '1';
  else
     s <= '0';
  end if;
end process comb;

In an RTL level description, the VHDL processes describe combinatorial
"blocks" (as in logic level descriptions) or synchronous "blocks". From
a practical point of view, each "synchronous" process describes a time-
limited algorithm, the algorithm of a clock cycle period. The algorithm
can be as complex as needed, the only limitation being the tool and the
computer limits.

-- example of a VHDL "synchronous" process with asynchronous setup
-- rst, clk, a, b and s are std_logic signals
synch: process (rst,clk)
begin
  if rst='1' then
    s <= '0';
  elsif rising_edge(clk) then
    if a='1' then
      s <= b;
    end if;
  end if;
end process synch;

As all the operations described in the process are processed in the
same clock cycle, all the required hardware must be generated. If three
arithmetic operations are done in the same clock cycle, three operators
must be synthesized (of course, synthesis optimizations can eventually
generate less hardware).

A behavioral description may be compared to a parallel C program with
explicit synchronisations (with semaphores, mutex, signals, etc.). The
VHDL processes can be compared to C threads or processes. Each process
describe a sequential algorithm, not time-limited. For a synchronous
design, this means that the algorithm can spread on several clock
cycles.

-- example of a VHDL "behav" process
-- clk, a, b and s are std_logic signals
behav: process (clk)
begin
  wait until clk='1';
  s <= '0';
  for i in 0 to 3 loop
    wait until clk='1';
    s <= (not s) and (a or (not b));
  end loop;
  while true loop
    wait until clk='1';
  end loop;
end process synch;

Much more complex behaviors can be described, and if the model is not
synchronous, it may be very hard to find what hardware can match the
algorithm. Most of the time, there can be several different solutions.

Indeed, it is possible to write an asynchronous model that will be
implemented in a synchronous way. The synthetiser will have to determine
simultaneously, the number of cycles and the hardware ressources. That
is, find an architecture and match the algorithm on this architecture
!...
And this is a quite complicated task. This is a reason for which this
kind
of synthetiser is not yet the industry standard.

When behavioral synthetisers will be a standard, it will be possible to
use C-like languages or VHDL or Verilog (or else) indiferently.

However, if one still needs to control the generated architecture in its
model, he will still need to use RTL or logical modelisation. And this
is
not possible (yet?) with traditional algorithmic languages as C or C++.

--

+-----------------------------------------------+
Fabrice MONTEIRO
LICM / CESIUM
Universite de METZ
7, rue Marconi
57070 METZ / FRANCE

Phone:	+33 (0)3.87.54.73.11
FAX:	+33 (0)3.87.54.73.01
Email:	fabrice.monteiro@ieee.org
+------------------------------------------------+

Article: 30482
Subject: help with ABEL-HDL and CPLDs
From: Richard Knispel <richard@sacher-laser.com>
Date: Tue, 10 Apr 2001 21:05:03 +0200
Links: << >>  << T >>  << A >>
Dear NG!

I have started recently with CPLDs and ABEL-HDL and need some advice on
how to continue.

For my first steps I have been using the starter kit offered by
Lattice/Vantis and did the tutorials on the CD. I was then able to do a
4-digit BCD up/down counter with clear, which is the obvious thing to
try first, since the kit includes a board with four 7segment displays
and 3 keys for user entry. Great so far.

But now I'm stuck with syntax questions and timing problems that I can't
solve with the manuals. So now I need some more advanded literature or
example designs for evaluation.

Can anybody help with that?

--
many thanx
Richard Knispel



Article: 30483
Subject: Re: Handel-C
From: cyber_spook <pjc@cyberspook.freeserve.co.uk>
Date: Tue, 10 Apr 2001 21:05:17 +0100
Links: << >>  << T >>  << A >>
the basic "par" statments looks somthing like this... Please correct me
if im wrong... I'll post some real code If I can get my hands on it.

par
{
    this responds to the first clk and runs in paralle with the next bit
below.
}

par
{
    in parralle with bit above on first clk..

    par
    {
        nested parralle functions that respond to the second clk..
    }
    par
    {
        ......
    }
}



Article: 30484
Subject: Re: free software
From: cyber_spook <pjc@cyberspook.freeserve.co.uk>
Date: Tue, 10 Apr 2001 21:16:32 +0100
Links: << >>  << T >>  << A >>
I used altera. I first used the MAX7128 (2500 gates) in the PLCC format - that
way you can plug it into a PLCC though hole socket on a bit of vero board.

Next was a FLEX10K (10,000 gate version) that you can also get in a 84pin PLCC
package. I used a EPC2 which a device that 'configures' the FLEX10K each time
you power up with your code (the FLEX10K is SDRAM based not EEROM like the
MAX7000's) and the EPC2 can be programed just like the MAX7000's though the
byte blaster (cct diagram can be found on altera to make your own - which I
did!).

Software - Downloaded the MAX+Plus v10 and FPGA Express from Altera (Both
FREE). Use the FPGA Express to complie the VHDL and generate a EDIF file that
MAX+Plus can then make into a floor plan to program the chips with and you can
then simulate it. Both are limited but will do a fine job on the smaller
chips.

A better simulater is ModleSim which you can get on a 30day tril but will set
you back 5k ish - however I belive that if you get Qualtus (Altera) wich will
complie you code - you get a 'Altera only' vertion of Modle Sim though in too!
(1.5k ish).

cyber_spook

Soren 'Disky' Reinke wrote:

> Hi there.
>
> I am a total FPGA newbie, so i have a few questions.
>
> What would be the best fpga to start with ?
> I just wanna play with simple things in the beginning like counters, small
> controllers and stuff like that.
>
> It should be cheap and also easy to connect to a PC to program it.
>
> Does there exist some free VHDL software ? Hopefully with simulator.
>
> Please help me.
>
> --
> With many Thanks
>
> Soren ' Disky ' Reinke  ICQ #1413069
> Remove IHSYD from email address when replying by email


Article: 30485
Subject: Re: small, fast, w/ PECL?
From: "Geoffrey G. Rochat" <geoff.nospam@nospam.pkworks.com>
Date: Tue, 10 Apr 2001 16:32:06 -0400
Links: << >>  << T >>  << A >>

>> Any suggestions for an FPGA or CPLD that can do the following?
>>
>> slow I/O: 10 Mhz TTL/LVTTL inputs (4), clock (1), and outputs(18).
>> fast I/O: 200 Mhz PECL clock (1) producing 100 Mhz output (1). [I
want
>> plenty of margin on this, not just squeeking by at 200 Mhz.]
>>
>> Basically, a small PLD that can do fast PECL as well as traditional
>> slower TTL.
>>
>> Any ideas?
>
>Do you also need PECL output?
>I am experimenting with PECL input to Spartan-II FPGA by configuring
the
>input as GTL and using a higher VREF.
>I have no results yet, but it should work.
>
>There are also affordable CMOS level clock synthesizers available at
200
>MHz.


Here's something you might try if you to want your non-LVPECL 3.3V PLD
to drive LVPECL without having to go through level converter chips.
IIRC, LVPECL inputs can swing from ground to a diode drop below the 3.3V
rail.  Start with a non-LVPECL 3.3V PLD, such as something in the
Lattice 5K-series, Altera 7K-series, Xilinx CoolRunner, etc. - whatever
is fast enough and properly sized to your needs.  Make the non-LVPECL
output of your PLD open-drain and connect it to your LVPECL load along
with the following odd pullup:  Take a silicon diode and attach its
anode to the 3.3V rail.  From its cathode add a resistor (330 Ohms or so
as a guess) paralleled by a 0.1uF bypass cap to ground.  Call the
cathode side of the diode V_HIGH.  The resistor to ground makes sure the
diode is always on, and the cap minimizes noise on V_HIGH by making
V_HIGH appear to be a low-impedance source at your clocking frequency.
Add a resistor of the characteristic impedance of the LVPECL signal line
you're dealing with (to minimize ringing and reflections) from V_HIGH to
your LVPECL load.  With this setup your non-LVPECL PLD, along with the
odd pullup, will drive the LVPECL load within "legal" bounds, although
those bounds will be outside the normal LVPECL operating range on the
low side.  The devil is in the details, of course, and it would be
interesting to see if this odd passive pullup is sufficient to work at
the speed you have in mind.  A further refinement might be to cut the
voltage swing seen at the LVPECL load by adding a series resistor
between the PLD open-drain output and the LVPECL load, and putting the
odd pullup at the LVPECL load side of the series resistor.  This way the
diode sets the high LVPECL voltage, and the resistor divider made up of
the resistor from V_HIGH to the LVPECL load and the series resistor sets
the low LVPECL voltage.  Some experimentation is called for.

You might want to grab Motorola Application Notes AN1404, AN1406 and
AN1672 off the On Semiconductor (formerly a division of Mot.,
www.onsemi.com ) website for interesting thoughts on PECL.

As for getting an LVPECL clock into your non-LVPECL PLD..., well, no
clever ideas come to mind.  It may be that the output swing of an LVPECL
gate with a resistor to ground is sufficient to clock a non-LVPECL PLD,
but that is "an exercise left for the reader."  <grin>  On Semiconductor
recommends you use their MC100EPT21 chip, or some other member of that
family.

Good luck and please e-mail or post your results, whatever you end up
doing.



Article: 30486
Subject: Re: How to specify Spartan2 GSR/GTS for Synthesis
From: yuryws@banet.net
Date: Tue, 10 Apr 2001 17:34:59 -0400
Links: << >>  << T >>  << A >>
Thanks, Ray.

--Yury Wolf

Ray Andraka wrote:

> The power on reset happens whether you specify a global reset or not, and
> regardless of whether or not your logic has async resets on it or not.  For
> synthesis, you needn't do a thing if you don't have a reset pin on your design.
> If you want to simulate it however, then use the ROC component in the unisim
> library.  It gets connected to your Global reset net.  You can leave it in there
> if you want.  Synthesis will put the ROC in your design as a black box, and the
> xilinx software will ignore it.
>
> yuryws@banet.net wrote:
> >
> > Would like to implement Power-On-Reset. Use no external Reset pin.
> > Asynchronous RST is used throughout the design on all flops/memories.
> >
> > What is the procedure for tying GSR to RST during synthesis (FPGA
> > Express user)?
> >
> > Thnx.
>
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com


Article: 30487
Subject: Re: Why FPGA/CPLDs draw a lot current?
From: Frank Wirtz <frankw@xilinx.com>
Date: Tue, 10 Apr 2001 16:48:13 -0500
Links: << >>  << T >>  << A >>
Hi Jim!

Could you please elaborate on your application?  I am interested in learning
how the Atmel part draws less power than the CoolRunner at low frequencies.  I
have heard that the CoolRunner devices may have some competition at ultra high
frequencies, but not at the bottom end.  (Maybe if there are no signals to
process?)

In one of Atmel's data sheets for their device (
http://www.atmel.com/atmel/acrobat/doc1409.pdf ) on page 16 they show a power
consumption vs. frequency that 'starts out' at about 35mA or so.  The test
cases are typically synchronous counters... I poked around looking for a
description of the test but did not find one.  CoolRunner devices "start out"
at well below 100uA and linearly ramp.  You have to clock the 64mc CR parts at
about 90MHz before they draw the same amount of power that the Atmel part draws
_at_quiescent_.

It appears that the ATF1504ASVL parts have a very complex power management
system... PD pins, "L" mode, automatic shutdown, etc.  While these do look
appealing initially, it seems that you have to put up with a fairly hefty
latency period before the part can actually process the data.  With the PD
mode, it appears that the entire device ignores any transitions on the inputs
until released from PD, which takes 1us to get out of.  Surprisingly, the
device can still draw as much as 5mA while in this mode.  I can't imagine the
headache of doing a timesim for this device.

But... people needing ultra low power designs (at ultra-low bandwidths) might
be willing to put up with all the hoops.  If absolute low power is the ultimate
concern, the best solution might be a PIC processor.  But that opens up a whole
bunch of other issues.

Best Regards,

Frank 'I ain't biased' Wirtz
Xilinx Staff Applications Engineer
7801 Jefferson St. NE
Albuquerque, NM 87109
(505) 798-4812

> Jim Granville <jim.granville@designtools.co.nz> wrote in message
> news:3ACE8160.F3@designtools.co.nz...
>
> >  It depends a lot on your frequency, and on the technology.
> > All devices have a DC current, and a mA/MHz slope.
> >  As the clock frequency increases, all logic will draw more current.
> >
> >  We are studying CPLD for LCD drivers, and sub 10uA (typ) is looking
> > feasible,
> > in ATF1504ASVL series - at low freqs these draw less than coolrunner,
> >
> >  So, if you are using these as IO, and not at tens of MHz, look at the
> > ATF15xx family.
> >
> > Also, given CMOS process nature, VERY low Idd will be easier at 3V than
> > 5V.
> >
> > - jg
> > --
> > ======= 80x51 Tools & PLD IP Specialists  =========
> > = http://www.DesignTools.co.nz


Article: 30488
Subject: Re: Why FPGA/CPLDs draw a lot current?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 10 Apr 2001 16:30:51 -0700
Links: << >>  << T >>  << A >>
Frank,

Not to wade in, but I can't help it.  A long time ago, I was fooled into buying the
"new lower power" part from aa competitor.  It had all of the problems you
mentioned:  intitial DC current was greater (not true CMOS), it had a start up
transient that required even more current (it had charge pumps), and it had a
"sleep" mode to save power.

Suffice it to say, after wasting about a month, we gave up, and went back to the
original part that did not have any of this personality,

Austin

Frank Wirtz wrote:

> Hi Jim!
>
> Could you please elaborate on your application?  I am interested in learning
> how the Atmel part draws less power than the CoolRunner at low frequencies.  I
> have heard that the CoolRunner devices may have some competition at ultra high
> frequencies, but not at the bottom end.  (Maybe if there are no signals to
> process?)
>
> In one of Atmel's data sheets for their device (
> http://www.atmel.com/atmel/acrobat/doc1409.pdf ) on page 16 they show a power
> consumption vs. frequency that 'starts out' at about 35mA or so.  The test
> cases are typically synchronous counters... I poked around looking for a
> description of the test but did not find one.  CoolRunner devices "start out"
> at well below 100uA and linearly ramp.  You have to clock the 64mc CR parts at
> about 90MHz before they draw the same amount of power that the Atmel part draws
> _at_quiescent_.
>
> It appears that the ATF1504ASVL parts have a very complex power management
> system... PD pins, "L" mode, automatic shutdown, etc.  While these do look
> appealing initially, it seems that you have to put up with a fairly hefty
> latency period before the part can actually process the data.  With the PD
> mode, it appears that the entire device ignores any transitions on the inputs
> until released from PD, which takes 1us to get out of.  Surprisingly, the
> device can still draw as much as 5mA while in this mode.  I can't imagine the
> headache of doing a timesim for this device.
>
> But... people needing ultra low power designs (at ultra-low bandwidths) might
> be willing to put up with all the hoops.  If absolute low power is the ultimate
> concern, the best solution might be a PIC processor.  But that opens up a whole
> bunch of other issues.
>
> Best Regards,
>
> Frank 'I ain't biased' Wirtz
> Xilinx Staff Applications Engineer
> 7801 Jefferson St. NE
> Albuquerque, NM 87109
> (505) 798-4812
>
> > Jim Granville <jim.granville@designtools.co.nz> wrote in message
> > news:3ACE8160.F3@designtools.co.nz...
> >
> > >  It depends a lot on your frequency, and on the technology.
> > > All devices have a DC current, and a mA/MHz slope.
> > >  As the clock frequency increases, all logic will draw more current.
> > >
> > >  We are studying CPLD for LCD drivers, and sub 10uA (typ) is looking
> > > feasible,
> > > in ATF1504ASVL series - at low freqs these draw less than coolrunner,
> > >
> > >  So, if you are using these as IO, and not at tens of MHz, look at the
> > > ATF15xx family.
> > >
> > > Also, given CMOS process nature, VERY low Idd will be easier at 3V than
> > > 5V.
> > >
> > > - jg
> > > --
> > > ======= 80x51 Tools & PLD IP Specialists  =========
> > > = http://www.DesignTools.co.nz


Article: 30489
Subject: Re: VHDL falling edge in Xilinx Foundation...
From: Andy Peters <"apeters <"@> noao [.] edu>
Date: Tue, 10 Apr 2001 16:34:03 -0700
Links: << >>  << T >>  << A >>
Damir Danijel Zagar wrote:
> 
> How to synthesize project which uses falling edge clocking
> using Xilinx Foundation 3.x?

Simply write your code so that it looks at the falling edge of the
clock:

process (clk) is
begin
    if falling_edge(clk) then
 ...

or

always @(negedge clk) ...

Note that FPGA Express v3.4 is brain dead, and instead of taking
advantage of the FPGA's clock-polarity select mux, it will infer an
inverter on the clock, run the output of the inverter through a BUFG,
and THAT'S what clocks your flop.  I don't know if it was fixed in v3.5,
nor do I care.

--andy

Article: 30490
Subject: Re: Handel-C
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Wed, 11 Apr 2001 00:45:48 GMT
Links: << >>  << T >>  << A >>
> cheers,
> -- Jamie

Jamie,
    You've covered a lot of ground, so I won't bother to elaborate on what
you said; however, I really do appreciate your insight into Handel-C, since
you have knowledge of this language AND VHDL and Verilog.
     Thanks for your explanations.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA



Article: 30491
Subject: Re: Why FPGA/CPLDs draw a lot current?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 11 Apr 2001 13:36:22 +1200
Links: << >>  << T >>  << A >>
Frank Wirtz wrote:
> 
> Hi Jim!
> 
> Could you please elaborate on your application?  I am interested in learning
> how the Atmel part draws less power than the CoolRunner at low frequencies.  I
> have heard that the CoolRunner devices may have some competition at ultra high
> frequencies, but not at the bottom end.  (Maybe if there are no signals to
> process?)

So you learn something new every day :-)

The 5V coolrunners we checked ( I believe now dropped ? ) have a just
under 100uA
static current (typ), whilst the ATF1504 is around 8uA at 5V, and appx
3uA at 3V
(typ)

I couldn't find TYP numbers for the 3V Coolrunners ?

From there, the mA/MHz slope is higher on ATF than coolrunner, but this
was for a LCD app, so you don't move far up the MHz scale! 
64-128Hz backplane freq are LCD regions, which is close to 
your 'no signals to process'.

Our design target is to have the LCD display 'alive' and everything else
asleep, as that determines long term battery life.

<snip>
> It appears that the ATF1504ASVL parts have a very complex power management
> system... PD pins, "L" mode, automatic shutdown, etc.  While these do look
> appealing initially, it seems that you have to put up with a fairly hefty
> latency period before the part can actually process the data.  With the PD
> mode, it appears that the entire device ignores any transitions on the inputs
> until released from PD, which takes 1us to get out of.  Surprisingly, the
> device can still draw as much as 5mA while in this mode.  I can't imagine the
> headache of doing a timesim for this device.

 I've never used this 'legacy' mode, it's far easier to use the smarter 
Automatic 'L' mode, which has a simple <10nS time adder.
 
> But... people needing ultra low power designs (at ultra-low bandwidths) might
> be willing to put up with all the hoops. 

No hoops, just cut the code...
 But to chase uA operations with any CMOS device, you do need to ensure
Vcc signal
swings, or the input buffers draw significant ( in uA terms ) current. 

> If absolute low power is the ultimate concern, the best solution 
> might be a PIC processor.  But that opens up a whole bunch of other issues.
 
 Nope, PICs struggle to meet our power and price targets.

-jg

Article: 30492
Subject: Re: High Speed PLA/FPGA
From: Peter Alfke <palfke@earthlink.net>
Date: Wed, 11 Apr 2001 03:07:37 GMT
Links: << >>  << T >>  << A >>
Ouch, that hurts. I want to be considered a 100% reliable, honest source of
information, and I goofed. Sorry for that!

But there is a silver lining:
When we first found out that the dynamic phase adjust sometimes locks up, we
immediately added this "function not available" into the errata sheet. Better
safe than sorry, for Murphy never sleeps.
In the meantime, we have analyzed the behavior, scratched our heads
individually, found the root cause and fixed it ( together with the other
limitations mentioned in the errata sheet) for the production ( non-ES )
silicon, to be available in a few months.
If you want to try out the dynamic phase shift feature, it works almost all the
time, but it can lock up under very specific circumstances. Good enough for lab
work, but I do not recommend it for a production design.
As I said, the problem is well-understood and fixed for non-ES silicon.

Peter Alfke, eating humble pie
===================================================
Erik Widding wrote:

> "Peter Alfke" <peter.alfke@xilinx.com> wrote in message
> news:3ACDFFEC.BEFA4706@xilinx.com...
> > Yes, yes: The phase can be programmed by configuration, but the phase can
> also
> > be adjusted during normal operation by pulsing the increment/decrement
> input of
> > the DCM. See the description on pages 171...175 of the Virtex-II Handbook.
>
> I think to be accurate, this should be a qualified "yes".  The engineering
> samples of the XC2V40 and XC2V1000 do not support this feature.  According
> to the errata we received with some XC2V1000-4FG256CES parts, last week:
>      "DCM Fine Phase shift operation - the "variable" shift mode of the DCM
> Fine Phase Shift feature is not available in these devices.  "Fixed" shift
> mode is available for use."
>
> If you need the feature, you will probably have to wait for the next die
> revision.  Admittedly, I have not yet checked for a possible workaround, as
> we weren't planning on playing with this feature for at least a couple of
> weeks.
>
> Regards,
> Erik Widding.
>
> --
> Birger Engineering, Inc.  --------------------------------  781.481.9233
> 38 Montvale Ave #260; Stoneham, MA 02180  -------  http://www.birger.com


Article: 30493
Subject: Re: Handel-C
From: "niki" <guest@my.net>
Date: Wed, 11 Apr 2001 03:51:24 GMT
Links: << >>  << T >>  << A >>
I am afraid that you mixed design domains and levels of abstraction into
the same concept. Levels of abstraction contains (1) architectural (2)
algorithmic (3) functional blocks (4) logical (5) circuit levels from
highest to lowest. Design domains are comprised of (1) behavioural (2)
structural (3) physical modelling.

Usually, when they talk about synthesis, this means logical abstraction
level. It is called RTL in terms of structural modelling. Behavioural
modelling doesn't necessarily mean that there is no logical abstraction.

This is well explained in the chapter 1 of "Principles of CMOS VLSI design"
by Weste and Eshraghian.

-Niki

Article: 30494
Subject: Re: Dist_ram :Memory instantiation
From: "niki" <guest@my.net>
Date: Wed, 11 Apr 2001 04:29:17 GMT
Links: << >>  << T >>  << A >>
You may have a better result using Coregen.

-Niki

Article: 30495
Subject: Re: How to specify Spartan2 GSR/GTS for Synthesis
From: Kolja Sulimma <kolja@prowokulta.org>
Date: Wed, 11 Apr 2001 10:25:13 +0200
Links: << >>  << T >>  << A >>
I have an additional questions to this:

If I have no explicit reset signal in my design, how do I specify the reset value of a
DFF?

Thanks,
            Kolja

> > The power on reset happens whether you specify a global reset or not, and
> > regardless of whether or not your logic has async resets on it or not.  For
> > synthesis, you needn't do a thing if you don't have a reset pin on your design.
> > If you want to simulate it however, then use the ROC component in the unisim
> > library.  It gets connected to your Global reset net.  You can leave it in there
> > if you want.  Synthesis will put the ROC in your design as a black box, and the
> > xilinx software will ignore it.
> >
> > yuryws@banet.net wrote:
> > >
> > > Would like to implement Power-On-Reset. Use no external Reset pin.
> > > Asynchronous RST is used throughout the design on all flops/memories.
> > >
> > > What is the procedure for tying GSR to RST during synthesis (FPGA
> > > Express user)?
> > >
> > > Thnx.
> >
> > --
> > -Ray Andraka, P.E.
> > President, the Andraka Consulting Group, Inc.
> > 401/884-7930     Fax 401/884-7950
> > email ray@andraka.com
> > http://www.andraka.com


Article: 30496
Subject: Re: help with ABEL-HDL and CPLDs
From: Bertram Geiger <bgeiger@aon.at>
Date: Wed, 11 Apr 2001 10:53:21 +0200
Links: << >>  << T >>  << A >>
Richard Knispel schrieb:
> 

> For my first steps I have been using the starter kit offered by
> Lattice/Vantis and did the tutorials on the CD. I was then able to do a
> 4-digit BCD up/down counter with clear, which is the obvious thing to
> try first, since the kit includes a board with four 7segment displays
> and 3 keys for user entry. Great so far.
> 
> But now I'm stuck with syntax questions and timing problems that I can't
> solve with the manuals. 

Do you have the comlete ABEL reference and design manuals and als looked
at them ?
When yes, what syntax question ist still unsolved ?
(i cannot say anything about timing issues)

greetings,  Bertram


-- 
Bertram Geiger,  bgeiger@aon.at
HTL Bulme Graz-Goesting - AUSTRIA

Article: 30497
Subject: Re: DLL locking problem
From: kahhean@bigfoot.com
Date: 11 Apr 2001 10:59:56 GMT
Links: << >>  << T >>  << A >>

Hi all,

Mmm, I didn't get any reply for my previous posting.  But anyway, after I
upgraded to Servie Pack 7, the DLLs are locking OK.

Thanks.

TA TA
kahhean

 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

Article: 30498
Subject: Re: Handel-C
From: Fabrice MONTEIRO <fabrice.monteiro@ieee.org>
Date: Wed, 11 Apr 2001 13:03:27 +0200
Links: << >>  << T >>  << A >>
Well, I was trying to discuss about the different levels of abstraction,
not on design domains.

If all processes on which rely a hierarchical VHDL model are RTL
compliant,
the model is RTL compliant. Thus, in order to design RTL models, one
must
write RTL processes.

Different architectures can match an given algorithm. In RTL, each
process
describes the architecture of a "sub-block" of the design. Note that i
am
not talking of structural VHDL.

I give in the following, examples of different architectures for the
same
algorithm. All are synchronous clocked designs. Let the algorithm be the
following:

algorithm:

  -> wait until a wait_signal is reset
  -> compute the sum of stored integer numbers
  -> set an end_signal


-- VHDL design nr 1

  addOne: process (rst,clk)
    variable i: integer;
  begin
    if rst='1' then -- asynchronous initialisation
      total <= 0;
      i:=0;
      end_signal <= '0';
    elsif rising_edge(clk) then
      if wait_signal='1' then -- synchronous initialisation
        total <= 0;
        i:=0;
        end_signal <= '0';
      else
        if i<size_of_my_array then
          total <= total+my_array(i);
          i:=i+1;
        else
          end_signal <= '1';
        end if;
      end if;
    end if;
  end process addOne;


-- VHDL design nr 2:

  addTwo: process (rst,clk)
    variable i,j: integer;
  begin
    if rst='1' then -- asynchronous initialisation
      total <= 0;
      i:=0;
      j:=1;
      end_signal <= '0';
    elsif rising_edge(clk) then
      if wait_signal='1' then -- synchronous initialisation
        total <= 0;
        i:=0;
        j:=1;
        end_signal <= '0';
      else
        if i<size_of_my_array then -- supposing size_of_my_array is even
          total <= total+my_array(i)+my_array(j);
          i:=i+2;
          j:=j+2;
        else
          end_signal <= '1';
        end if;
      end if;
    end if;
  end process addTwo;


-- VHDL design nr 3:

  addAndShift: process (rst,clk)
    variable i: integer;
  begin
    if rst='1' then -- asynchronous initialisation
      total <= 0;
      i:=size_of_my_array;
      end_signal <= '0';
    elsif rising_edge(clk) then
      if wait_signal='1' then -- synchronous initialisation
        total <= 0;
        i:=size_of_my_array;
        end_signal <= '0';
      else
        if i/=0 then
          total <= total+my_array(0)
          my_array <= my_array(0) & my_array(size_of_my_array-1 downto
1);
          i:=i-1;
        else
          end_signal <= '1';
        end if;
      end if;
    end if;
  end process addAndShift;


All the designs implement the same algorithm but not the same
architecture.

On the first design, once the start_signal is set, size_of_my_array
clock
cycles are required to compute the sum. The stored data my_array is in a
single ROM or RAM (only one address must be reached at a time). Only one
adder is required to add the data to the total. The data addresses are
generated by a counter.

Only (size_of_my_array/2) clock cycles are required on the second
design.
But the data must be partitionned into two different ROMs or RAMs (as
two
addresses must be reached at a time), one for the odd addresses, the
other
for the even addresses. Two adders are required to add the data to the
total. The data addresses are generated by two counters.

In the third design, the data is stored in a cyclic shift register. The
number
of clock cycles required to compute the sum is (size_of_my_array). The
counter
i is only used to know if all data was processed, as no ROM or RAM
address
must be generated.

--

+-----------------------------------------------+
Fabrice MONTEIRO
LICM / CESIUM
Universite de METZ
7, rue Marconi
57070 METZ / FRANCE

Phone:	+33 (0)3.87.54.73.11
FAX:	+33 (0)3.87.54.73.01
Email:	fabrice.monteiro@ieee.org
+------------------------------------------------+

Article: 30499
Subject: FPGA Express 3.5 One hot state machine Synthesis problem
From: kahhean@bigfoot.com
Date: 11 Apr 2001 11:09:21 GMT
Links: << >>  << T >>  << A >>

Hi all,

Recently, I had problems with DLL locking.  After upgrading to Service Pack 7,
and FPGA Express (3.5.0.6013), the DLLs are locking fine.  

However, the very same vhdl code that used to be synthesized to be under 8 ns,
is now 18ns component delay alone.

After checking in Timing Analysis, I observed that FE seems to be giving me
rubbish.  I have a 38-state state machine.  I specified one-hot encoding. 
The result is that I get 38 flip flops for the state machine (which looks
like one-hot), but I also get each state talking to every other state.  Since
each of my state transits to only a few other states, FE must be giving me
rubbish.  Anyway, the very same vhdl code synthesized well using FGPA Express
3.4.

Does anybody have the same experience too?

Thanks in advance.

TA TA
kahhean

 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net



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
2017JanFebMarApr2017

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