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 58500

Article: 58500
Subject: Re: Active Probe
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 24 Jul 2003 16:04:20 -0700
Links: << >>  << T >>  << A >>
Howard Johnson once gave me a nice tip:
Use a 50 Ohm cable driving a 50 Ohm-terminated input to the
oscilloscope. Then solder a 470 Ohm resistor  to the cable front end,
and you have a 10:1 passive probe with GHz bandwidth. Doesn't make the
scope any faster, but avoids the loss of bandwidth in the probe. You pay
for it by throwing away a factor 10 in sensitivity, and you load the
circuit under test with 520 Ohm, but both these restrictions are
acceptable, most of the time...

Peter Alfke
===================
Andy Peters wrote:
> 
> "Basuki Endah Priyanto" <EBEPriyanto@ntu.edu.sg> wrote in message news:<N8auEQZUDHA.3356@exchnews1.main.ntu.edu.sg>...
> > Dear all,
> >
> > Have you ever measured the signal level of your FPGA pin out using
> > Oscilloscope ?
> 
> Yes -- it's the second thing I do when I'm bringing up a new board for
> the first time.  The first thing, of course, is to put a voltmeter on
> each of the power supplies.
> 
> > At the clock speed of 50 MHz, I observed the signal is destroyed. The
> > oscilloscope sales guy pretends that I need to use active probe which is
> > quite expensive.
> >
> > He said it was a circuit loading issues.
> >
> > Is there any such away to overcome this problem without buying the
> > active probe ?
> 
> OK, what's your 'scope's bandwidth?  What's your probe's bandwidth?
> You can't look at a 50 MHz clock signal on a 100 MHz 'scope or with a
> 100 MHZ probe and expect to see anything other than a cruddy sine
> wave.
> 
> Also, what's your probe's ground connection like?  Is it a six-inch
> piece of wire?  Or are you making a very short connection to a nearby
> ground?
> 
> Passive 10x probes are perfectly fine for what you're doing, as long
> as they have sufficient bandwidth.  Sounds like the sales guy needs to
> make another payment on the Porsche.
> 
> -a

Article: 58501
Subject: Re: Active Probe
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Thu, 24 Jul 2003 16:29:19 -0700
Links: << >>  << T >>  << A >>
On Thu, 24 Jul 2003 16:04:20 -0700, Peter Alfke wrote:

> Howard Johnson once gave me a nice tip: Use a 50 Ohm cable driving a 50
> Ohm-terminated input to the oscilloscope. Then solder a 470 Ohm resistor
>  to the cable front end, and you have a 10:1 passive probe with GHz
> bandwidth. Doesn't make the scope any faster, but avoids the loss of
> bandwidth in the probe. You pay for it by throwing away a factor 10 in
> sensitivity, and you load the circuit under test with 520 Ohm, but both
> these restrictions are acceptable, most of the time...
> 
> Peter Alfke
> ===================


Plus 520 Ohms resistive load is a lot better for pulse fidelity than the 159
Ohms capacitive reactance of a 10 PF scope probe at just 100 MHz...

PCW

Article: 58502
Subject: Re: Pricing question....
From: russelmann@hotmail.com (Rudolf Usselmann)
Date: 24 Jul 2003 16:47:35 -0700
Links: << >>  << T >>  << A >>
seannstifler69@hotmail.com (Stifler) wrote in message news:<bf780a06.0307232150.5dc7bcee@posting.google.com>...
> Petey,
> 
> I am curious. Are you sales? Are you Marketing? Are you Applications?
> Why are you vendors even on this board? Who believes all of your spew?

Wow ! Speak for yourself !

Peter Alfke has been providing valuable feedback on this board
for quite some time. So have various people from other companies.
I am glad they are here !

Regards,
rudi               
--------------------------------------------------------
www.asics.ws  --- Solutions for your ASIC/FPGA needs ---
----------------- FPGAs * Full Custom ICs * IP Cores ---
FREE IP Cores --> http://www.asics.ws/ <-- FREE IP Cores

> Your answer was a non answer. Contact your sales person. Oh thank you
> so much for that piece of such valuable information.
> 
> FPGAs are expensive. They are very complicated products that demand a
> high premium. Especially ones like V2 pro. The part has up to 4 PPCs,
> multiple 3.125 rocket IO, and a huge amount of ram and logic. It's
> state of the art chip technology. Do you think it is not worth $1500?
> 
> Pricing goes by volume and time. If you buy 10 per year you will never
> get what you are talking about. It's all about how important you are,
> how many you buy, and what you can negotiate. Time is a factor, but if
> you are low volume you will never get the best prices.
> 
> A sales person will just lie to you to get the socket. That's their
> job. Once they have the socket they have you in their wallet. As if
> you will design it out once you put it on the board.
> 
> My advice, get the deal in writing. Decide what you need the pricing
> to be and make them sign up for your proposal. Negotiate. It's the
> American way. Be a tough negotiator. They are in the driver's seat
> though. The technology is hot.
> 
> If you are Cisco you will get the best price. It goes downhill from
> there.

Article: 58503
Subject: heel needed--Bad format for LOC constraint B8 on leds<6>. To bypass this
From: paraagv@hotmail.com (paraag)
Date: 24 Jul 2003 16:56:32 -0700
Links: << >>  << T >>  << A >>
hi

The solution for this is to 
ERROR:MapLib:30 - Bad format for LOC constraint B8 on leds<6>. To
bypass this
   error set the environment variable 'XIL_MAP_LOCWARN'.

set XIL_MAP_LOCWARN=1 
but where do I do this I mean can anyone tell me the extension of the
file where i have to set this environment variable
Thanx
Paraag

Article: 58504
Subject: Re: FPGA Editor
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Jul 2003 20:48:55 -0400
Links: << >>  << T >>  << A >>
I've also encountered numerous problems on "proven" third party boards with signal,
power and clock integrity issues.  Those ones can be a royal PITA to track down.

Allan Herriman wrote:

>
> We have done "difficult" high speed designs with early silicon, and
> sometimes have found that there are other causes:
>
> - overly optimistic speed files.
> - ES silicon bugs (or "features", if they're documented).
> - (individual) faulty parts.

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 58505
Subject: Re: FPGA Editor
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Jul 2003 20:53:41 -0400
Links: << >>  << T >>  << A >>
Most likely, you were not registering your I/O at the IOBs, and since you did
not constrain the setup and clock to Q times, these vary with the PAR solution.
Since they are not constrained, the I/O timing may or may  not work in the
context of your system.  Registering the I/O at the IOBs isolates the internal
timing from the interfaces, so you should do it if at all possible.

Martin Euredjian wrote:

>
> Perhaps I don't fully understand the mechanism.  I told the tools that the
> module is clocked at 133MHz.  The tools said that timing looked good after
> P&R.  If there were any timing issues (which I obviously had) why didn't it
> report them?  Both sdram controller versions had perfectly good HDL that
> simulated with exactly the same results.
>
> More than eager to learn...
>
> Thanks,
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 58506
Subject: Re: FPGA Editor
From: Ray Andraka <ray@andraka.com>
Date: Thu, 24 Jul 2003 20:55:02 -0400
Links: << >>  << T >>  << A >>
But were the flip-flops pushed to the IOB's?  Break one of the rules and they
are guaranteed to not go in the IOB.

Martin Euredjian wrote:

> "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote:
>
> > "DATA_IN" and "DATA_OUT" are the module I/O.  They are both defined as
> > "wire".  I suppose I could re-define them as "reg" and add one clock of
> > delay to the I/O.  Is this my mistake?  I don't see how this would be
> > affected by changing my burst counter from an up counter to a down counter
> > ... but I'll go with the flow.
>
> I should add that the modules reading and writing from sdram have fully
> registered outputs on the same clock domain.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 58507
Subject: Xilinx Design Manager - Connecting 2 Latches
From: "Triax" <malvric@starhub.net.sg>
Date: Fri, 25 Jul 2003 10:37:42 +0800
Links: << >>  << T >>  << A >>

Hello,
    I have design a circuit using Xilinx Design Manager that require
2 latches as a output. I have tried the following configuration and it
will give me one of the follow error
1) IOPAD Signal XXX represents an unsupported IOB configuration
2) Logical net xxx has multiple drivers

The IOPAD is connected to the input of the latch. I'm using a 4 input 
latch,
each IOPAD is connected to two 4 input latches input pin

The configuration i tried are
1) IOPAD --> latch1 input
               |--> latch 2 input

2) IOPAD --> IBUF --> latch 1 input
                            |--> latch 2 input

3) IOBUF --> IBUF --> latch 1 input
              |--> latch 2 input

4) change IBUF to BUF

Can anyone give me a solution for connection a IOPAD to 2 latches.
It can work if im connecting the IOPAD to one latch, but it will give 
error
when i connect it to two latches.

Thank you




Article: 58508
Subject: Re: Use ICAp iwth a soft IP core to decompress!!!!
From: symon_brewer@hotmail.com (Symon)
Date: 24 Jul 2003 19:41:17 -0700
Links: << >>  << T >>  << A >>
Of course, use MicroBlaze! Good one, John, works for VirtexII and Pro.
Does SpartanIII have ICAP? Can't see it in the datasheet I have. Any
idea of the resource needed for a MicroBlaze and a UnZip program?
   It seems to me that Xilinx might want to implement this for us.
They get to use a known compression standard, Zip, supported by
everybody's computer, so customers can see the likely compression
ratio results.(Up to 5:1 according to Ray's post.) They can showcase
their MicroBlaze, Partial Reconfiguration, ICAP. They beat their
competition's 35% to 60% compression, using a soft, programmable,
retrofittable solution which FPGAs are all about in the first place.
What about it Austin? Are you worried about plunging sales of the
config PROMs? ;-)
        cheers, Syms.

John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bfn953$bl7$1@bunyip.cc.uq.edu.au>...
> Symon wrote:
> > Austin,
> >     Glad you like the idea. Out of curiosity I tried WinZipping some
> > bit files and got >90% compression on my admittedly only 10% full V2
> > design. So, I await the first freebie port of WinZip to VHDL or the
> > PPC. I won't be holding my breath!!
> 
> zlib builds cleanly for microblaze with mb-gcc - it would be very simple 
> to write a simple microblaze program to decompress a bitstream file.
> 
> The trick would be interfacing the microblaze to ICAP and and pumping 
> the bits.  As long as the new (decompressed) bitfile didn't overwrite 
> the microblaze that was actually doing the decompression, you'd be off 
> and running.  If you eventually used the microblaze in your "final" 
> design then this would be quite a neat way to go.
> 
> Regards,
> 
> John

Article: 58509
Subject: Re: FIFO Controller
From: "Stan Lackey" <stanlackey@hotmail.com>
Date: Fri, 25 Jul 2003 00:06:38 -0400
Links: << >>  << T >>  << A >>
That is very easy to get around.  Add an additional upper bit to each
pointer, and do your math including them.  Now for an 8-location fifo, say,
all values from 0 (empty) to 8 (full) are available.  I do it all the time!

As for asynch. FIFOs, depending on the relative clock speeds, several
locations may be unusable because of the time it takes to pass a pointer
across clock domains.  It requires a complete analysis of your situation to
determine how many locations are wasted.

-Stan

"Ralph Mason" <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote
in message news:IhXAa.32629$3t6.476804@news.xtra.co.nz...
> "Muthu" <muthu_nano@yahoo.co.in> wrote in message
> news:28c66cd3.0305272041.4361c105@posting.google.com...
> > Hi,
> >
> > With an N depth RAM, I could build a FIFO of depth N. Right?
> >
> > But this may not be true with asynchrnous FIFO. some where i heard
> > that, for asynchrnous FIFO 1 location is wasted. why? and How?
> >
> > In general all the Circular FIFO documents also, saying that only N-1
> > depth is possible with N location RAM.? why?
> >
> > Thanks in advance
> >
> > Regards,
> > Muthu
>
> You can never fill the FIFO to N because then the write pointer and the
read
> pointer would be equal and it would look like the fifo was empty.
>
>
> Ralph
>
>



Article: 58510
Subject: Re: FIFO Controller
From: "Stan Lackey" <stanlackey@hotmail.com>
Date: Fri, 25 Jul 2003 00:11:53 -0400
Links: << >>  << T >>  << A >>
No one should ever use those cores.  They produce so many warnings during
compilation that you don't see warnings produced by your own code.  -Stan

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3ED4F1E3.45FFDAA@xilinx.com...
> That's not quite true, there are simple ways to avoid this. All "my"
> FIFO designs use all available positions, but some of the available
> cores "waste" one position.  I think this is mainly an "academic"
> issue,( in the bad sense of the word). A FIFO should be big enough so
> that it hardly ever gets full, and whether it has 1023 or 1024 locations
> should be irrelevant, in almost all cases.
> Peter Alfke, Xilinx
>
> Ralph Mason wrote:
> >
> >
> > You can never fill the FIFO to N because then the write pointer and the
read
> > pointer would be equal and it would look like the fifo was empty.
> >
> > Ralph



Article: 58511
Subject: Re: FIFO Controller
From: "Stan Lackey" <stanlackey@hotmail.com>
Date: Fri, 25 Jul 2003 00:16:44 -0400
Links: << >>  << T >>  << A >>
Clearly there's no one-size-fits-all.  The other reason I never use
oregen.  -Stan

"Peter Alfke" <peter@xilinx.com> wrote in message
news:3ED6492D.E3CF97AB@xilinx.com...
>
>
> Marc Randolph wrote:
> >
> > Howdy Peter,
> >
> > This might be more effort than you had in mind, but we've had a need
> > several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32
> > bits out @ 50 MHz.  And the reverse of course.  While I'm dreaming, we
> > could use them in both BRAM and LUT RAM form.
>
> Expect it this fall, but probably only in BRAM form.
> The problem is that 1, 2 or 3 eight-bit words might get left stuck in
> the FIFO when it declares itself empty, because there is no more 32-bit
> word to be read.    :-)
>
> I'll think about the other suggestions, but they may be unlikely.
>
> Peter Alfke
> >
> >



Article: 58512
Subject: Re: temux
From: Andrew Paule <lsboogy@qwest.net>
Date: Thu, 24 Jul 2003 23:40:05 -0500
Links: << >>  << T >>  << A >>
Hi Masoud -

this should in theory be pretty easy, but you need to quantify many 
things befor the decision is made  -  16MHz may be pretty slow, but is 
there a channel to channel synch requirement - crosstalk - jitter - 
others?  Decision should have more data for a basis than is here ( I 
would guess that there is).  I could easily put enough nitrous into my 
car so that the motor was capable of taking it into the 8's in a quarter 
mile,  but the tranny certainly would not take it, and I'd probably 
twist the crank if nothing else.

Andrew

Masoud Naderi wrote:

>Hi all,
>I want to use PMC-Sierra chipset for my STM-1 card. Input to this card
>is 16x16Mhz sync channels that comes from backplane. I can use
>PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to
>PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not
>cost saving and not suitable for this design, because TEMUX can do
>many things that wont use in this application. I think making DS3
>signals from backplane signals (16Mhz) can be done easely in FPGA, so
>bypassing TEMUX chip. It should be noted that single or multi E1
>channels should be extraced from our output STM-1 signal (for example
>from an ADM in SDH ring).
>Please help me in this regard.
>Regards.
>M. Naderi
>  
>


Article: 58513
Subject: Reseting the whole thing
From: "..:: Gabster ::.." <gabsterblue@hotmail.com>
Date: Fri, 25 Jul 2003 00:40:44 -0400
Links: << >>  << T >>  << A >>
Hi,

    I want to use a simple reset circuit to reset my FPGA, but I'm unsure
how to handle it because of the PROM. The point is the PROM has to program
the FPGA before the FPGA is reset. How the reset circuit could to be
implemented considering this. I was thinking about a reset circuit with a
built-in delay, but I'm sure there's a easier way to do it.

thanks,
Gabriel



Article: 58514
Subject: Re: Reseting the whole thing
From: Andrew Paule <lsboogy@qwest.net>
Date: Fri, 25 Jul 2003 00:28:48 -0500
Links: << >>  << T >>  << A >>
Ti makes reset controllers with programmable delay (Ti7733/7705/7725 
etc) that you could either put a simple RC on that gives enough delay - 
make it longer that the programming time, or you could use the done pin 
on a Xilinx or Altera part to kick the reset controller - I'm guessing 
that you are using one of the two, but I'm shooting in the dark

Andrew

..:: Gabster ::.. wrote:

>Hi,
>
>    I want to use a simple reset circuit to reset my FPGA, but I'm unsure
>how to handle it because of the PROM. The point is the PROM has to program
>the FPGA before the FPGA is reset. How the reset circuit could to be
>implemented considering this. I was thinking about a reset circuit with a
>built-in delay, but I'm sure there's a easier way to do it.
>
>thanks,
>Gabriel
>
>
>  
>


Article: 58515
Subject: Re: Use ICAp iwth a soft IP core to decompress!!!!
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 25 Jul 2003 15:30:04 +1000
Links: << >>  << T >>  << A >>
Symon wrote:
> Of course, use MicroBlaze! Good one, John, works for VirtexII and Pro.

> Does SpartanIII have ICAP? Can't see it in the datasheet I have. 

Nope, no ICAP on SpartanIII. Well actually there probably is, but it is 
not accessible via the tools.  spartan3 is basically virtex2 shrunk and 
twiddled.  Maybe with bitstream hacking, but then you're on your own!

> Any
> idea of the resource needed for a MicroBlaze and a UnZip program?

basic microblaze CPU takes about 900 LUTs, plus peripherals.

I just checked and the full libz.a library compiled for microblaze is 
130Kb, but that could certainly shrink if you only included the 
decompression stuff etc.  You might squeeze a cut-down "inflate()" 
function into bram, along with sufficient control program to manage it all.

>    It seems to me that Xilinx might want to implement this for us.
> They get to use a known compression standard, Zip, supported by
> everybody's computer, so customers can see the likely compression
> ratio results.(Up to 5:1 according to Ray's post.) They can showcase
> their MicroBlaze, Partial Reconfiguration, ICAP. They beat their
> competition's 35% to 60% compression, using a soft, programmable,
> retrofittable solution which FPGAs are all about in the first place.

Yes, except for the little hitch of no ICAP on spartan3...

> What about it Austin? Are you worried about plunging sales of the
> config PROMs? ;-)

It's a matter of horses for courses - for some people bitstream 
compression is the key - for others it's startup (and hence 
configuration) time.

Personally I think the best approach to bitstream compression is not so 
much a "commodity" algorithm but rather structural compression.  Say you 
have a CLB configured as a LUT with such and such data, and registered 
output, and so on.  Instead of simply treating the configuration bits as 
a random bitstreamand compressing it, you could instead *describe" the 
configuration of the LUT.  Similarl ideas might apply for the PIPs that 
control the routing resources.

Just an idea - if there's any value in it I'd say someone's already 
looked into it! :)

John


Article: 58516
Subject: Re: Reseting the whole thing
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 25 Jul 2003 15:46:36 +1000
Links: << >>  << T >>  << A >>
..:: Gabster ::.. wrote:
> Hi,
> 
>     I want to use a simple reset circuit to reset my FPGA, but I'm unsure
> how to handle it because of the PROM. The point is the PROM has to program
> the FPGA before the FPGA is reset. How the reset circuit could to be
> implemented considering this. I was thinking about a reset circuit with a
> built-in delay, but I'm sure there's a easier way to do it.

Isn't there a setting in the configuration control whereby the FPGA will 
assert a global reset signal after configuration?  It means you need to 
route said reset signal around your entire design, but you'd have to do 
that anyway if I'm understanding the question properly.


John


Article: 58517
Subject: Re: FPGA Editor
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 25 Jul 2003 05:48:53 GMT
Links: << >>  << T >>  << A >>
Yes, I've been checking this quite often via FPGA Editor.  Part of my design
is generating a source-synchronous bus at more than 160MHz, so it is very
critical that F/F's be located at the IOB's for pretty much all inputs and
outputs on this design.

In fact, relying on the tools to place the F/F's there (even though IOB
packing has been enabled) proved to be unreliable.  It wasn't until I placed
the constraints in HDL that I would reliably see (with no changes in logic
whatsoever) the F/F's pushed to IOB's.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



"Ray Andraka" <ray@andraka.com> wrote in message
news:3F207FE6.33164127@andraka.com...
> But were the flip-flops pushed to the IOB's?  Break one of the rules and
they
> are guaranteed to not go in the IOB.
>
> Martin Euredjian wrote:
>
> > "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote:
> >
> > > "DATA_IN" and "DATA_OUT" are the module I/O.  They are both defined as
> > > "wire".  I suppose I could re-define them as "reg" and add one clock
of
> > > delay to the I/O.  Is this my mistake?  I don't see how this would be
> > > affected by changing my burst counter from an up counter to a down
counter
> > > ... but I'll go with the flow.
> >
> > I should add that the modules reading and writing from sdram have fully
> > registered outputs on the same clock domain.
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Martin Euredjian
> >
> > To send private email:
> > 0_0_0_0_@pacbell.net
> > where
> > "0_0_0_0_"  =  "martineu"
>
> --
> --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
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759
>
>



Article: 58518
Subject: Re: Reseting the whole thing
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 25 Jul 2003 06:09:30 GMT
Links: << >>  << T >>  << A >>
Why is it that you want to reset the FPGA after configuration?  For all
intents and purposes it is coming out of reset after configuration.

If you need to do so in order to wait for an event build that into a startup
state machine.

If you need to guarantee that other portions of the board are ready you can
also build that into a startup state machine.

If you need to ensure that certain flip-flops and logic come-up in a
specific state you can do that through the bitmap itself.

I've read quite a bit about global reset not being a reliable approach.  Do
a Google search of this N.G. using "GSR".  Imagine flip-flops in different
portions of the design coming out of reset at slighly different times.  Or
maybe even flip-flops holding the state of a state machine.  I believe I've
experienced this first hand (not using GSR, but my own global reset) and it
wasn't fun to debug, it took longer than I care to admit to figure out what
was going on.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



"..:: Gabster ::.." <gabsterblue@hotmail.com> wrote in message
news:Vy2Ua.10962$Fo3.164756@weber.videotron.net...
> Hi,
>
>     I want to use a simple reset circuit to reset my FPGA, but I'm unsure
> how to handle it because of the PROM. The point is the PROM has to program
> the FPGA before the FPGA is reset. How the reset circuit could to be
> implemented considering this. I was thinking about a reset circuit with a
> built-in delay, but I'm sure there's a easier way to do it.
>
> thanks,
> Gabriel
>
>



Article: 58519
Subject: Re: Reseting the whole thing
From: Andrew Paule <lsboogy@qwest.net>
Date: Fri, 25 Jul 2003 01:57:42 -0500
Links: << >>  << T >>  << A >>
Martin -

a global reset is one of the foundations of most of the current "big 
iron" (Teradyne, Schlumberger, Agilent) testers - why? -  because it 
brings things into a known state.  Some FPGA's don't have the capability 
to load bitmaps and other things necessary for reliable start 
conditions, and even if yours does, if you were to try to get it through 
test at a company like that, you would be forced to do it anyway 
(probably for good reason).  The processor in the machine you are using 
right now was tested and qualified under these conditions (100% 
guaranteed), and a global reset is required on all the boards in the 
test head that did it. 

Global reset is a reliable approach, and is required for many purposes.

Andrew

Martin Euredjian wrote:

>Why is it that you want to reset the FPGA after configuration?  For all
>intents and purposes it is coming out of reset after configuration.
>
>If you need to do so in order to wait for an event build that into a startup
>state machine.
>
>If you need to guarantee that other portions of the board are ready you can
>also build that into a startup state machine.
>
>If you need to ensure that certain flip-flops and logic come-up in a
>specific state you can do that through the bitmap itself.
>
>I've read quite a bit about global reset not being a reliable approach.  Do
>a Google search of this N.G. using "GSR".  Imagine flip-flops in different
>portions of the design coming out of reset at slighly different times.  Or
>maybe even flip-flops holding the state of a state machine.  I believe I've
>experienced this first hand (not using GSR, but my own global reset) and it
>wasn't fun to debug, it took longer than I care to admit to figure out what
>was going on.
>
>
>  
>


Article: 58520
Subject: Re: Pricing question....
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 25 Jul 2003 07:12:40 GMT
Links: << >>  << T >>  << A >>
> seannstifler69@hotmail.com (Stifler) wrote:

...
>> Why are you vendors even on this board? Who believes all of your spew?
...

Are you for real?  Go over to Google ( http://groups.google.com/ )and read
through the archives.  Go over to the Xilinx site and check out some of
Peter's articles http://www.xilinx.com/xlnx/xweb/xil_tx_home.jsp

Those of us that are not gifted like you (who obviously know it all and
don't need any support) greately appreciate the value in having guys like
Peter (and others in this and related newsgroups) available one email away.
I'm not sure I could attach a value to what I've learned on this newsgroup
in the last two years.

Sounds like you need to take a couple of 'em "humble pills" I heard about.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



Article: 58521
Subject: Re: Reseting the whole thing
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 25 Jul 2003 07:34:35 GMT
Links: << >>  << T >>  << A >>
I'm not disputing the need for reliable reset.  From what I've read on this
N.G. the GSR approach does not seem to be the recommended way to go.

On my current design I implement an "intelligent" global reset module that
issues reset signals to various portions of the design and verifies that the
module being reset is OK before moving forward.  For example, the DCM's need
to be checked for lock before allowing related modules to even think about
intializing, much less operating.  I also have several modules that set a
flag when their state machine enters the "RESET" or "INIT" state.  The reset
generator looks for this flag as confirmation that the particular module is
OK.  Since my design requires modules to be reset/released-from-reset in a
specific sequence this works very well.  There are modules that have their
own reset or startup requirements.

I guess I now think of an external reset signal as just another input that
triggers actions (in my case a state machine) as opposed to the reset inputs
of all the flip-flops within the FPGA.

Are you saying that it is OK to rely on a global reset signal that is
directly connected to all flip-flops within the FPGA?  Again, reading
through the N.G. archives the experts seem to agree on that this is
potentially dangerous.

I only have experience with Xilinx Virtex II, so my field of vision is
seriously impared.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"








"Andrew Paule" <lsboogy@qwest.net> wrote in message
news:Xu4Ua.189$TT2.95507@news.uswest.net...
> Martin -
>
> a global reset is one of the foundations of most of the current "big
> iron" (Teradyne, Schlumberger, Agilent) testers - why? -  because it
> brings things into a known state.  Some FPGA's don't have the capability
> to load bitmaps and other things necessary for reliable start
> conditions, and even if yours does, if you were to try to get it through
> test at a company like that, you would be forced to do it anyway
> (probably for good reason).  The processor in the machine you are using
> right now was tested and qualified under these conditions (100%
> guaranteed), and a global reset is required on all the boards in the
> test head that did it.
>
> Global reset is a reliable approach, and is required for many purposes.
>
> Andrew
>
> Martin Euredjian wrote:
>
> >Why is it that you want to reset the FPGA after configuration?  For all
> >intents and purposes it is coming out of reset after configuration.
> >
> >If you need to do so in order to wait for an event build that into a
startup
> >state machine.
> >
> >If you need to guarantee that other portions of the board are ready you
can
> >also build that into a startup state machine.
> >
> >If you need to ensure that certain flip-flops and logic come-up in a
> >specific state you can do that through the bitmap itself.
> >
> >I've read quite a bit about global reset not being a reliable approach.
Do
> >a Google search of this N.G. using "GSR".  Imagine flip-flops in
different
> >portions of the design coming out of reset at slighly different times.
Or
> >maybe even flip-flops holding the state of a state machine.  I believe
I've
> >experienced this first hand (not using GSR, but my own global reset) and
it
> >wasn't fun to debug, it took longer than I care to admit to figure out
what
> >was going on.
> >
> >
> >
> >
>



Article: 58522
Subject: Re: XST fails to recognize FSM with registered outputs
From: no_spa2005@yahoo.fr (Alain)
Date: 25 Jul 2003 00:48:12 -0700
Links: << >>  << T >>  << A >>
Hi,

I've already arise this question few month ago : Does XST will be able
soon to code FSM in a safe way : ie be able to create a one-hot
encoding and recognize the 'when others" clause.
Ex :
 ...
 when Sate_one =>          
   ...
 when others => My_State <= INIT;

Is very important in case where clock can disappear or other strange
things happen (this case arise in telecom application when user
disconnect or connect fiber or when DCM start...). With 'safe'
encoding we are sure to be in a know state.

For me is a very important feature and a basic feature for a
synthesizer (FpgaExpress had it for many years, the same for Simplify
and others) : that's why synthesizer was created at the beginning:
recognize counter, adder and FSM correctly. Others features came
later.
It's the main reason why I can use XST.

Note : binary coding or a kind of global reset is not a solution for
me and would be a backward step : I don't want to change all my
'correct vhdl' to use xst.

Sergei Storojev <storojev@xilinx.com> wrote in message news:<bfottv$k6b1@cliff.xsj.xilinx.com>...
> Dear Eilert,
> 
> The description style you used in ELIS_Statemachine example will be
> supported in the next release of ISE.
> 
> In the case you replace
>          case NS is
> by
>          case CS is
> 
> in the process
> 
> 	Sync_Output : process (Reset, Clock)
> 
> then XST will be able to recognize FSM (but of course in this case it is
> not the same behavior).
> 
> Thank you,
> Sergei.
> 
> E. Backhus wrote:
> > Hi everybody,
> > while I was trying to create a statemachine with registered outputs
> > which shouldn't be delayed by one clock cycle (as usual when just
> > putting a register behind the outputs of the FSM) I modified some
> > sourcecode from the XILINX ISE Language Templates for sythesis. As an
> > example I tried to recreate the stopwatch statemachine from the ISE 5
> > In depth tutorial.
> > 
> > Everything works fine insofar that the function is correct and
> > itentical to the original design and it also synthesizes fine with one
> > little exeption:
> > 
> > The XST-Synthesis Tool does not recognize my coding style as a FSM,
> > therefore it wont do the neccessary optimizations. For comparision
> > purposes I have added some XST-synthesis report snippets to outline
> > the differences:
> > 
> > While my coding style produces a register and some feedback logic
> > around it, for the original code (Produced by StateCAD) XST inferes a
> > FSM and applies all optimizations on it.
> > 
> > (When I comment out the enum_encoding attributes in my code then
> > register CS will become One-State-Hot encoded, but no OSH-FSM will be
> > created. Instead some clumsy binary FSM with an unreal OSH encoding
> > (all statebits zero!!! - not allowed for OSH encoding!!!) will be
> > generated.
> > 
> > So, what trick makes the XST-Synthesis tool recognize my coding style
> > to be a FSM working in the way I want (that is with registered outputs
> > but no delay by one clock cycle)?
> > 
> > 
> > All help is appreciated.
> > 
> > Thanks 
> > 
> >  Eilert
> > 
> > 
> > 
> > =========================================================================
> > *                           HDL Synthesis                             
> >  *
> > =========================================================================
> > 
> > Synthesizing Unit <elis_statemachine>.
> >     Related source file is
> > S:/ssy_laboratory_test/ssy_stopwatch/ELIS_Statemachine.vhd.
> >     Found 1-bit register for signal <clockenableout>.
> >     Found 1-bit register for signal <resetout>.
> >     Found 3-bit register for signal <cs>.
> >     Summary:
> > 	inferred   5 D-type flip-flop(s).
> > Unit <elis_statemachine> synthesized.
> > 
> > 
> > =========================================================================
> > HDL Synthesis Report
> > 
> > Macro Statistics
> > # Registers                        : 3
> >   3-bit register                   : 1
> >   1-bit register                   : 2
> > 
> > =========================================================================
> > 
> > 
> > 
> > =========================================================================
> > *                           HDL Synthesis                             
> >  *
> > =========================================================================
> > 
> > Synthesizing Unit <stmach>.
> >     Related source file is
> > S:/ssy_laboratory_test/ssy_stopwatch/STMACH.vhd.
> >     Found finite state machine <FSM_0> for signal <sreg>.
> >     -----------------------------------------------------------------------
> >     | States             | 6                                          
> >    |
>   | Transitions        | 11                                         
> >    |
>   | Inputs             | 1                                          
> >    |
>   | Outputs            | 2                                          
> >    |
>   | Reset type         | asynchronous                               
> >    |
>   | Encoding           | automatic                                  
> >    |
>   | State register     | d  flip-flops                              
> >    |
> >     -----------------------------------------------------------------------
> >     Summary:
> > 	inferred   1 Finite State Machine(s).
> > Unit <stmach> synthesized.
> > 
> > 
> > =========================================================================
> > HDL Synthesis Report
> > 
> > Macro Statistics
> > # FSMs                             : 1
> > 
> > =========================================================================
> > 
> > Optimizing FSM <FSM_0> with One-Hot encoding and d flip-flops.
> > 
> > 
> > 
> > Sourcecode of elis_statemachine.vhd:
> > 
> > library IEEE;
> > use IEEE.STD_LOGIC_1164.ALL;
> > use IEEE.STD_LOGIC_ARITH.ALL;
> > use IEEE.STD_LOGIC_UNSIGNED.ALL;
> > 
> > entity ELIS_Statemachine is
> >     Port ( Clock : in std_logic;
> >            Reset : in std_logic;
> >            StartStop : in std_logic;
> >            ClockEnableOut : out std_logic;
> >            ResetOut : out std_logic);
> > end ELIS_Statemachine;
> > 
> > architecture Behavioral of ELIS_Statemachine is
> >   type STATE_TYPE is (Clear,Zero,Start,Counting,Stop,Stopped);	
> >   attribute ENUM_ENCODING: STRING;
> >   attribute ENUM_ENCODING of STATE_TYPE: type is "000 101 010 001 011
> > 100";
> >   signal CS	: STATE_TYPE;
> >   signal NS : STATE_TYPE;
> > 
> > begin
> > 	   
> >     SYNC_PROC: process (CLOCK, RESET)
> >     begin
> >        if (RESET='1') then
> >               CS <= Clear;
> >        elsif (CLOCK'event and CLOCK = '1') then
> >             CS <= NS;
> >        end if;
> >     end process;
> >  
> >     COMB_PROC: process (CS, StartStop)
> >     begin
> >        case CS is
> > 	      when clear => NS <= Zero;
> > 		when Zero  => If StartStop = '1' then
> > 		                NS <= Start;
> > 				  else
> > 				    NS <= Zero;
> > 				  end if;
> > 		when Start  => If StartStop = '0' then
> > 		                NS <= Counting;
> > 				  else
> > 				    NS <= Start;
> > 				  end if;
> > 		when Counting  => If StartStop = '1' then
> >       	                    NS <= Stop;
> > 				      else
> > 					  NS <= Counting;
> >     				      end if;
> > 		when Stop  => If StartStop = '0' then
> > 		                NS <= Stopped;
> > 				  else
> > 				    NS <= Stop;
> >     				  end if;
> > 		when Stopped  => If StartStop = '1' then
> > 		                   NS <= Zero;
> > 				     else
> > 				       NS <= Stopped;
> >     				     end if;
> >             when others =>	NS <= Clear;
> >        end case;
> >     end process;
> >  
> >     Sync_Output : process (Reset, Clock)
> >     begin
> > 	   if (RESET='1') then
> >         ClockEnableOut <= '0';
> > 		  ResetOut <= '1';
> >       elsif (CLOCK'event and CLOCK = '1') then
> >         case NS is
> >    	     when clear =>     ClockEnableOut <= '0';
> > 		                 ResetOut <= '1';
> > 	     when Zero  =>     ClockEnableOut <= '0';
> > 		                 ResetOut <= '0';
> >  	     when Start  =>    ClockEnableOut <= '1';
> > 		                 ResetOut <= '0';
> > 	     when Counting  => ClockEnableOut <= '1';
> > 		                 ResetOut <= '0';
> > 	     when Stop  =>     ClockEnableOut <= '0';
> > 		                 ResetOut <= '0';
> > 	     when Stopped  =>  ClockEnableOut <= '0';
> > 		                 ResetOut <= '0';
> >            when others =>    ClockEnableOut <= '0';
> > 		                 ResetOut <= '1';
> >        end case;
> >       end if;
> >     end process;
> > 
> > end Behavioral;
> > 
> > 
> > 
> > Sourcecode of stmach.vhd :
> > 
> > LIBRARY ieee;
> > USE ieee.std_logic_1164.all;
> > 
> > ENTITY STMACH IS
> > 	PORT (CLK,RESET,strtstop: IN std_logic;
> > 		clkout,rst : OUT std_logic);
> > END;
> > 
> > ARCHITECTURE BEHAVIOR OF STMACH IS
> > 	SIGNAL sreg : std_logic_vector (2 DOWNTO 0);
> > 	SIGNAL next_sreg : std_logic_vector (2 DOWNTO 0);
> > 	CONSTANT clear : std_logic_vector (2 DOWNTO 0) :="000";
> > 	CONSTANT counting : std_logic_vector (2 DOWNTO 0) :="001";
> > 	CONSTANT start : std_logic_vector (2 DOWNTO 0) :="010";
> > 	CONSTANT stop : std_logic_vector (2 DOWNTO 0) :="011";
> > 	CONSTANT stopped : std_logic_vector (2 DOWNTO 0) :="100";
> > 	CONSTANT zero : std_logic_vector (2 DOWNTO 0) :="101";
> > 
> > BEGIN
> > 	PROCESS (CLK, RESET, next_sreg)
> > 	BEGIN
> > 		IF ( RESET='1' ) THEN
> > 			sreg <= clear;
> > 		ELSIF CLK='1' AND CLK'event THEN
> > 			sreg <= next_sreg;
> > 		END IF;
> > 	END PROCESS;
> > 
> > 	PROCESS (sreg,strtstop)
> > 	BEGIN
> > 		clkout <= '0'; rst <= '0'; 
> > 
> > 		next_sreg<=clear;
> > 
> > 		CASE sreg IS
> > 			WHEN clear =>
> > 				clkout<='0';
> > 				rst<='1';
> > 				IF  TRUE THEN
> > 					next_sreg<=zero;
> > 				 ELSE
> > 					next_sreg<=clear;
> > 				END IF;
> > 			WHEN counting =>
> > 				clkout<='1';
> > 				rst<='0';
> > 				IF  NOT ( (( strtstop='0' ) ) OR  (( strtstop='1' ) ) ) THEN
> > 					next_sreg<=counting;
> > 				END IF;
> > 				IF ( strtstop='0' ) THEN
> > 					next_sreg<=counting;
> > 				END IF;
> > 				IF ( strtstop='1' ) THEN
> > 					next_sreg<=stop;
> > 				END IF;
> > 			WHEN start =>
> > 				clkout<='1';
> > 				rst<='0';
> > 				IF  NOT ( (( strtstop='1' ) ) OR  (( strtstop='0' ) ) ) THEN
> > 					next_sreg<=start;
> > 				END IF;
> > 				IF ( strtstop='1' ) THEN
> > 					next_sreg<=start;
> > 				END IF;
> > 				IF ( strtstop='0' ) THEN
> > 					next_sreg<=counting;
> > 				END IF;
> > 			WHEN stop =>
> > 				clkout<='0';
> > 				rst<='0';
> > 				IF  NOT ( (( strtstop='1' ) ) OR  (( strtstop='0' ) ) ) THEN
> > 					next_sreg<=stop;
> > 				END IF;
> > 				IF ( strtstop='1' ) THEN
> > 					next_sreg<=stop;
> > 				END IF;
> > 				IF ( strtstop='0' ) THEN
> > 					next_sreg<=stopped;
> > 				END IF;
> > 			WHEN stopped =>
> > 				clkout<='0';
> > 				rst<='0';
> > 				IF  NOT ( (( strtstop='0' ) ) OR  (( strtstop='1' ) ) ) THEN
> > 					next_sreg<=stopped;
> > 				END IF;
> > 				IF ( strtstop='0' ) THEN
> > 					next_sreg<=stopped;
> > 				END IF;
> > 				IF ( strtstop='1' ) THEN
> > 					next_sreg<=start;
> > 				END IF;
> > 			WHEN zero =>
> > 				clkout<='0';
> > 				rst<='0';
> > 				IF  NOT ( (( strtstop='0' ) ) OR  (( strtstop='1' ) ) ) THEN
> > 					next_sreg<=zero;
> > 				END IF;
> > 				IF ( strtstop='0' ) THEN
> > 					next_sreg<=zero;
> > 				END IF;
> > 				IF ( strtstop='1' ) THEN
> > 					next_sreg<=start;
> > 				END IF;
> > 			WHEN OTHERS =>
> > 		END CASE;
> > 	END PROCESS;
> > END BEHAVIOR;

Article: 58523
Subject: Re: Multi Pass Place & Route
From: martin_euredjian@hotmail.com (Martin Euredjian)
Date: 25 Jul 2003 01:18:20 -0700
Links: << >>  << T >>  << A >>
Vikram Pasham <Vikram.Pasham@xilinx.com> wrote: 

> MPPR is used when PAR fails to meet timing constraints by a small margin with
> the default cost table. Each cost table would serve as a seed for PAR algorithm
> and result in a different placement and routing. One of these results may meet
> your timing constraints, otherwise MPPR will indicate the best placement and
> routing it achieved with the given cost tables.
> 
> In your case all these MPPR results meet your timing constraints, as the timing
> score is zero. Timing score is simply a summation in picoseconds of all timing
> violations. You can use any of these cost table as long as your timing
> constraints are met by PAR. The following solution record explains on how to
> interpret MPPR report

Thanks for your post.  This much I knew, for it is available
information in the documentation.

My question had to do with the procedure to follow after running MPPR.
 Somewhere I saw a blurb about going back to P&R and running it in
"Re-entrant" mode.  But, I couldn't find what this really means and
how it uses the results of MPPR.  It seems to me that the easiest
procedure is to simply re-run P&R with the best seed table (per the
MPPR report).  Is that pretty much the extent fo the relationship
between MPPR and P&R?

Thanks again,

-Martin
(posting from hotmail 'cause sbc/pacbell usenet servers seem to be in
dire need of maintenance or exorcism)

Article: 58524
Subject: Relative placement constraints in VHDL for Virtex multipliers
From: bymanaar@hotmail.com (Jack Stone)
Date: 25 Jul 2003 01:28:58 -0700
Links: << >>  << T >>  << A >>
This question may have been asked before but ...

I often have timing problems when using virtex-II dedicated
multipliers. After synthesis/P&R I have fixed these by looking at the
placement with ISE floorplanner and then constraining the multipliers
and their i/o registers to be packed as close together as possible.
This requires too much effort for this lazy engineer. I must be
possible to do this constraining in my VHDL code via attributes. How?
Does anyone have a bit of example code?

I don't really want to place the multiplier in any certain spot,
rather just make sure that the registers holding its input and
catching its output will be placed in the adjacent slices...

Thanks in advance for your help.



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