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 74125

Article: 74125
Subject: Re: Altera SDRAM controller - Only 2 words burst???
From: zohargolan@hotmail.com (zg)
Date: 4 Oct 2004 09:46:49 -0700
Links: << >>  << T >>  << A >>
Hi Kemmeth,

Thank you again for your help.
What is the part number of the SDRAM chip you are using. Maybe the
difference is that I am simulating a different (Maybe slower) chip.

Zohar

"Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10lqi8vegegit29@news.supernews.com>...
> Hi Zohar,
> 
> My system is running at 75 MHz right now.  My fmax is 90+ so I may try a
> little higher too.
> I didn't simulate, but I used SignalTapII to verify that I was indeed
> dma'ing the contents of an external fifo into sdram at a rate of 1 clock per
> 32bit word. (480 words in ~485 cpu clocks)
> This was while my system was running out of the same sdram and operating on
> other sdram data simultaneously - so very good results!
> 
> I'd like to add that I got these perfect results with the help of the Altera
> Nios team.  I'll be posting this setup on the IP section of the Nios Forum.
> 
> This was *writing* to sdram, and I haven't really looked at reads yet.
> Hopefully I'll be just as pleased with those results.  In my case reads are
> not quite as critical as writes, as the data streaming in is real time and
> waits for no one.
> 
> Ken
> 
> 
> "zg" <zohargolan@hotmail.com> wrote in message
> news:e24ecb44.0409301615.7b8bccaf@posting.google.com...
> > Hi Ken,
> >
> > Thank you for your response.
> > What frequncy are you running the NIOS? I tried simulating at 72MHz
> > and I got only 2 words bursts.
> > Are you using NIOS II?
> >
> > Regards,
> > Zohar
> >
> > "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message
>  news:<10lg0aca67jseaa@news.supernews.com>...
> > > "zg" <zohargolan@hotmail.com> wrote in message
> > > news:e24ecb44.0409241455.340ba130@posting.google.com...
> > > > Hi All,
> > > >
> > > > I am trying to use the SDR SDRAM controller that is comming with the
> > > > NIOS II development package. In the simulation it looks like this core
> > > > supports only 2 words bursts. I couldn't find anything in the
> > > > documentations.
> > > > Am I correct?
> > > > If this core supports bigger bursts then 2 words, any ideas what am I
> > > > doing wrong?
> > > >
> > > > Thank you all
> > > > Zohar
> > >
> > > Zohar,
> > >
> > > I'm working on a design that uses one 16MB sdram chip for most of its
> > > instruction and data memory.  I rely heavily on dma and other burst
>  reads
> > > and writes (ie cache) to get the performance I need.
> > >
> > > The sdram controller you're talking about is good enough to burst 480 32
>  bit
> > > words in under 485 cpu clocks.  It's a beautiful thing to watch in
>  Signal
> > > Tap as I get this performance.  (Haven't explored the lenght limits
>  above
> > > 480 - my external fifo's AlmostFull level)
> > >
> > > I'm hammering that sdram (through the Altera sdram controller) nines
>  ways to
> > > Sunday and it performs flawlessly.
> > >
> > > I have some serious issues with the whole NiosI/II chain, but the sdram
> > > controller has been a champ.
> > >
> > > Ken

Article: 74126
Subject: question on interfacing FPGA with a sensor
From: viswan_1981@hotmail.com (Viswan)
Date: 4 Oct 2004 09:49:03 -0700
Links: << >>  << T >>  << A >>
hi,

I have a doubt on using inout ports in FPGA design. I am implementing
an application on FPGA, that should be interfaced to SHT71(Sensirion
humidity and temperature sensor). My FPGA gets the value of
temperature and humidity from the sensor and calculates
moisture(output) using certain equations.

I have designed the arithmetic unit required to calculate the moisture
value in VHDL, and synthesized on to FPGA.  But now I have to
interface this unit to the sensor(SHT71), and the sensor needs to have
a controller(any microcontroller as specified in the SHT71 datasheet)
to control its operations and get the values of temperature and
humidity. The sensor has a bidirectional data signal as one of the
ports, and that should be connected to the controller to send and
receive data.  I want to implement the controller also on the same
FPGA itself.  But is it possible?  Is it possible to handle a
bidirectional port from an FPGA to send and receive data? I am using
Virtex XCV800 HQ240I. Or is it suggestible to use any standard
microcontroller as an interface between sensor and FPGA?

Any suggestion on this is highly appreciated.

Thanks

Article: 74127
Subject: Re: Removing set/reset logic for shift register (HDL ADVISOR )
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 04 Oct 2004 16:53:52 GMT
Links: << >>  << T >>  << A >>
"Dave" <gretzteam@hotmail.com> wrote in message
news:yt2dnW1FjtkfzsLcRVn-jg@comcast.com...
> Ok I understand...but isn't it better to have a reset for all our flip
flop?
> If something goes wrong - or when I press the reset button...- the
> controller can always reset everything to zero before we start again...
>
> Thanks,
> David

If something goes wrong - or when you press the reset button...- would you
be willing to wait for the FPGA to reprogram itself?  If you design the
system to boot the FPGA from a PROM or reprogram it from the processor, the
"clean" state would be guaranteed after the system reset and would allow
proper "initialization" or SRL and BlockRAM contents.  The async resets are
more a leftover from ASIC designs than a sincere need for FPGAs.



Article: 74128
Subject: Re: M*Blaze in Cyclone ! End of What? ;)
From: "Antti Lukats" <antti@case2000.com>
Date: Mon, 4 Oct 2004 09:58:53 -0700
Links: << >>  << T >>  << A >>
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message
news:cjqu87$pf2$1@bunyip.cc.uq.edu.au...
> Antti,
>
> Antti Lukats wrote:
>
>  > the M*Blaze/uCLinux has already received first donation offers, but
more
>  > donations are welcome of course, specially in form of FPGA development
>  > hardware.
>
> > PS I am not the author of the open-source M*Blaze, neither is the
M*Blaze
> > IP-Core downloadable from openchip, the primary download location for
the
> > M*Blaze IP-Core is the opencores website, project name aeMB.
>
> You are also not the author of a single line of source code in the
> microblaze-uclinux project.

You are right that there is no source from me in the uCLinux project, except
that I wrote and made available for free to anyone a bootloader from
SystemACE for uCLinux image, there is also source code to test the system to
mbvanilla compliance, both source codes are available for downloads

http://xilinx.openchip.org/index.php?page=3&action=category&cat_id=9

since february 2004, I also have ported uCLinux/MicroBlaze to different FPGA
platforms and helped others in such porting. If that doesnt count as
contributing to the project in your eyes so be it.

> I would appreciate it if you did not make
> comments that could be misunderstood as representing me or any other
> contributor to that project.

I have not made such comments, I am not stupid you know. Besides uCLinux is
not your project.

I want to see aeMB based system to be mbvanilla compliant, thats all !

If I cant use uCLinux in that context then I will use uC*Linux if that
pleases you?

> There is no such thing as M*Blaze. The author of aeMB has wisely avoided
> any direct reference to Microblaze.  If the Leon core had been called
> SP*RC, it would have lasted about 10 minutes before Sun jumped on it.

sure there is no M*Blaze so why get upset?

> Please let the people who do the work, speak for themselves.

Did I disturb you doing your work? Sorry if I did wasnt my intent.

> Thanks,

gee John, sorry to get you upset! That really was not my intent!

have abreak have kit-kat take look at the bright side :)

antti













Article: 74129
Subject: Re: FSL Read Data Out Problem
From: "Roger Planger" <ernte23@gmx.at>
Date: Mon, 4 Oct 2004 18:03:07 +0100
Links: << >>  << T >>  << A >>
Thanks for your help, I have updated the file as you said, but unfortunately 
I have still the same problem, I only get 0 values thats so strange...

Cheers
Roger

"Goran Bilski" <goran@xilinx.com> wrote in message 
news:cjrovc$ihq2@cliff.xsj.xilinx.com...
> Hi,
>
> The problem is that the Write signal is not a ready signal for MicroBlaze 
> but it's a write signal into a FIFO.
> So what you have done is to write new values EVERY clock cycle into the 
> FIFO which will get full very fast.
>
> If you only want to write back the value that you read, then you should do 
> this instead.
> FSL0_M_Write <= FSL_S_Read_i;
>
> This will ensure that you only write when you have valid input data.
>
> Göran
>
> Roger Planger wrote:
>
>>Hello Everybody.
>>
>>First of all thanks antti for your FSL File, now I understand the Read in 
>>Process.
>>
>>http://xilinx.openchip.org
>>
>>But for me also very important is to write the data out after the 
>>calculation is finished. Here is my actual
>>VHDL Code, so the readin should be okay, and then I only assign the output 
>>value the input value after this
>>valid. Then I want to read it out, but unfortunately I always get Output = 
>>0, althought I write different values from 1 up to 5 at the data input 
>>port!
>>So can perhaps someone give me a hint what is wrong here? Antti do you 
>>have a solution for this perhaps?
>>
>>begin  -- architecture IMP
>>  FSL0_S_Read <= FSL_S_Read_i;
>>  FSL_S_Read_i <= FSL0_S_Exists;
>>  FSL0_M_DATA <= FSL0_S_Data;     -- Output = Input
>>  FSL0_M_Write <= '1';                          -- Indicates Data is 
>> available for reading
>>end architecture IMP;
>>
>>Test Code
>>
>>int data_to_local_link[] = { 1,2,3,4,5 };
>>int data_back_local_link[5];
>>
>>for (k=0;k<5;k++){
>>        microblaze_nbwrite_datafsl(data_to_local_link[k],0);
>>        microblaze_nbread_datafsl(data_back_local_link[k],0);
>> xil_printf("Testvalue :%x\n\r",data_back_local_link[k]);
>>
>>Output:
>>
>>Testvalue :0
>>Testvalue :0
>>Testvalue :0
>>Testvalue :0
>>Testvalue :0
>>
>>Cheers
>>Roger
>>
>>
>>
>>
> 



Article: 74130
Subject: Re: FPGA vs ASIC area
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 04 Oct 2004 10:04:39 -0700
Links: << >>  << T >>  << A >>

> From: rickman <spamgoeshere4@yahoo.com>
> Reply-To: john@bluepal.net
> Newsgroups: comp.arch.fpga
> Date: Sun, 03 Oct 2004 00:28:04 -0400
> Subject: Re: FPGA vs ASIC area
> 
>
> 
> Austin, Peter sends me private emails asking me to ignore your
> nonsense.  

This is a blatant lie (plus a breach of confidence). I had only asked Rick
to make peace with Austin, and accept the fact that he has a different style
than mine.. Nobody will push a wedge between me and Austin. We are
neighbors, partners, and friends, and complement and help each other every
day in many ways.

This thread seems to have run its course. The original question about the
area ratio between ASICs and FPGA was (as I wrote) meanigless and cute.
Which one is smaller, uses which process, and takes how long to test is all
reflected in one single number, the price charged by the vendor. And there
is intense competition which keeps us all on our toes...

The user (that is most of the people in this newsgroup) should only be
interested in cost, performance, power consumption, design effort,
reprogrammability, time to market, availability, and general risk.
Smart engineers will know how to make a rational choice.

ASICs will be the right choice sometimes, FPGAs will be the right choice in
most cases. But we know that in spite of less than 2000 new ASIC designs
worldwide per year(!), the high-volume ASIC business is still much larger
than the FPGA business. That gives FPGAs a tremendous opportunity to grow.
We like that!  

Peter Alfke


Article: 74131
Subject: Re: FPGA vs ASIC area
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 04 Oct 2004 17:06:41 GMT
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:415F7FD4.F74A300C@yahoo.com...
> austin wrote:
> Austin, Peter sends me private emails asking me to ignore your
> nonsense.  He tells me you are a valuable asset to this group because
> you have significant knowledge.  But your BS is enormous.  This comment
> is the sort of thing that is not welcome in the group, at least by me.
> If you want to discuss the issues, then leave the crap at home.  I find
> you to be a very unprofessional representative for Xilinx and I have
> even told my local sales people that.  I don't know if this ever makes
> it back to your managers, but I sincerly hope that I never have to
> depend on you for any sort of support.  In fact, you personally are one
> of the reasons that I keep looking at the solutions offered by Altera,
> and have ended up filling at least one of the sockets on our boards with
> an Altera part.

rickman,

As one of the many people that see the convesations back and forth between
the two of you, please consider that you *may* be predisposed to consider
Austin's comments as argumentative.

It is the view of this engineer that Austin's behavior on this board is very
professional and only suffers occasionally from the frustrations of the
inability to communicate clearly what he knows whether due to the
limitations of written communications or the receptiveness of the audience.

Please try to make your points, not argue them.  It's typical of your posts
to others to be informative as it is with Austin's.  If either of you come
to a post by the other as a challenge to his manhood, the conversation won't
be productive for anyone.

It takes two to tango.

Respectfully,
John_H



Article: 74132
Subject: Re: Is it possible to Reverse-Engineer an FPGA Output file?
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 04 Oct 2004 10:10:11 -0700
Links: << >>  << T >>  << A >>
Jock wrote:
> Is it possible to take the FPGA.hex file, for example and given that you
> know the device, reverse-engineer it into either it's CLB map or back to
> it's high-level HDL code?
> 
> 

Austin replies:

In a word, yes.

Given that with the FPGA_Editor tool you can create test designs (a 
single input through a LUT to a single output), you can eventually map 
every bit to its corresponding function.  The question here is time.

Once you have a hardware FPGA_Editor view of the design, you still do 
not have the HDL representation.

The HDL is similar to a high level programming language like c++, but it 
is dissimilar in that synthesis tools perform logic optimization.  The 
original HDL to the bitstream is a 'many to one' mapping.  Many 
different HDL designs could result in an identical bitstream.

So one can then examine the FPGA_Editor 'schematic' and reverse engineer 
a HDL representation.  One then verifies the HDL by synthesizing it, and 
seeing how it matches the FPGA_Editor view.

Since there is no security in obscurity, the bistream in unencrypted 
form is not considered secure.  If someone wants to reverse engineer the 
design, it might now be possible to do it without expending a lot of 
time and money.  If the obective is to clone the design without 
analyzing it, or performing only enough analysis to change one or two 
parameters (ie the clock divisor in the DCM) is quite simple.

But to steal the IP for a core, so you could implement it in an ASIC, 
would be a difficult task to be sure.  Do-able, but pretty tough.  Might 
be easier to just re-engineer the core and use the FPGA version to 
verify it.  That, at least, is legal.

It is almost certainly true that the reverse engineered HDL would not 
look at all like the original source code, so copyright on the source 
would be unenforceable.  Copyright on the bitstream (or in China, a 
mask), would be an enforceable way to take legal action against a clone. 
  Legal action is the last and worst remedy, so I suggest using 
encryption if the IP is worth protecting.

There are a number of companies out there, who do reverse engineering 
for a living.  Sometimes it is for legal reasons (to see if a competitor 
is infringing on a patent), and sometimes it is done because a company 
loses its original design, and has to continue maintaining it.  These 
companies do not reverse engineer a design for illegal purposes 
(otherwise they might be held liable in a lawsuit).

I would very much like to be able to apply a cost to reverse engineering 
a FPGA, however, no one is willing to step up and state how much time 
(or money) it took to reverse engineer a particular design.  I can only 
speculate.

Others on this board have proposed that there are better and faster 
methods to get the design which I will refer to as 'social engineering'.

Austin

Article: 74133
Subject: Re: Altera Quartus II 4.1 double-click on QPF-File doesn't work
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Mon, 4 Oct 2004 17:12:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <ca4d800d.0408251537.2cf96975@posting.google.com>
By author:    sdatta@altera.com (Subroto Datta)
In newsgroup: comp.arch.fpga
> 
> Hi Manfred,
> 
>   Can you elaborate some more. When you say there is a Link, where is
> the link and how did your create it? I have the following entries for
> my environment variables
> 
> PATH %QUARTUS_ROOTDIR%\bin;
> QUARTUS_ROOTDIR D:\quartus41
> 
> I have been double clicking on qpf's and launching Quartus II 4.1
> without any problems. Also the Quartus II shortcut on my desktop
> points to D:\quartus41\bin\quartus.exe.
> 

I've seen this same problem.  If I clock on the .qpf file it tries to
open the wrong application; trying to change which application is
bound to this extension shows a list of applications which doesn't
include Quartus; specifying the Quartus path directly via the browse
interface doesn't work either.

This is with WinXP SP2 (spit.)

	-hpa

Article: 74134
Subject: Re: FSL Read Data Out Problem
From: Goran Bilski <goran@xilinx.com>
Date: Mon, 04 Oct 2004 19:36:55 +0200
Links: << >>  << T >>  << A >>


Hi,

Sorry I didn't look careful enough on your C code.
You are using the nonblocking version of the FSL macros but in this case 
you should do the blocking versions.
use "microblaze_bread_datafsl" instead of the "microblaze_nbread_datafsl".

Could you also share the .mhs file so I could see that everything is 
connected correctly?

Göran

Roger Planger wrote:

>Thanks for your help, I have updated the file as you said, but unfortunately 
>I have still the same problem, I only get 0 values thats so strange...
>
>Cheers
>Roger
>
>"Goran Bilski" <goran@xilinx.com> wrote in message 
>news:cjrovc$ihq2@cliff.xsj.xilinx.com...
>  
>
>>Hi,
>>
>>The problem is that the Write signal is not a ready signal for MicroBlaze 
>>but it's a write signal into a FIFO.
>>So what you have done is to write new values EVERY clock cycle into the 
>>FIFO which will get full very fast.
>>
>>If you only want to write back the value that you read, then you should do 
>>this instead.
>>FSL0_M_Write <= FSL_S_Read_i;
>>
>>This will ensure that you only write when you have valid input data.
>>
>>Göran
>>
>>Roger Planger wrote:
>>
>>    
>>
>>>Hello Everybody.
>>>
>>>First of all thanks antti for your FSL File, now I understand the Read in 
>>>Process.
>>>
>>>http://xilinx.openchip.org
>>>
>>>But for me also very important is to write the data out after the 
>>>calculation is finished. Here is my actual
>>>VHDL Code, so the readin should be okay, and then I only assign the output 
>>>value the input value after this
>>>valid. Then I want to read it out, but unfortunately I always get Output = 
>>>0, althought I write different values from 1 up to 5 at the data input 
>>>port!
>>>So can perhaps someone give me a hint what is wrong here? Antti do you 
>>>have a solution for this perhaps?
>>>
>>>begin  -- architecture IMP
>>> FSL0_S_Read <= FSL_S_Read_i;
>>> FSL_S_Read_i <= FSL0_S_Exists;
>>> FSL0_M_DATA <= FSL0_S_Data;     -- Output = Input
>>> FSL0_M_Write <= '1';                          -- Indicates Data is 
>>>available for reading
>>>end architecture IMP;
>>>
>>>Test Code
>>>
>>>int data_to_local_link[] = { 1,2,3,4,5 };
>>>int data_back_local_link[5];
>>>
>>>for (k=0;k<5;k++){
>>>       microblaze_nbwrite_datafsl(data_to_local_link[k],0);
>>>       microblaze_nbread_datafsl(data_back_local_link[k],0);
>>>xil_printf("Testvalue :%x\n\r",data_back_local_link[k]);
>>>
>>>Output:
>>>
>>>Testvalue :0
>>>Testvalue :0
>>>Testvalue :0
>>>Testvalue :0
>>>Testvalue :0
>>>
>>>Cheers
>>>Roger
>>>
>>>
>>>
>>>
>>>      
>>>
>
>
>  
>




Article: 74135
Subject: Re: Asynchronous reset timing problem
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 04 Oct 2004 10:40:22 -0700
Links: << >>  << T >>  << A >>

> From: Laurent Gauch <laurent.gauch@DELETEALLCAPSamontec.com>
> Newsgroups: comp.arch.fpga
> Date: Mon, 04 Oct 2004 16:51:12 +0200
> To: David <david.lamb@gmail.com>
> Subject: Re: Asynchronous reset timing problem
> 
> 
> One solution would be to synchronize your asynchronous reset by one
> flip-flop with his D input connected to the VCC and his RST input
> connected to your actual asynchronous reset, and the Q output is your
> new pseudo-asynchronous reset of your actual design.
> 
> Larry
> www.amontec.com

The objective is to eliminate the effect of a long and uncertain delay in
the asynchronous reset driven throughout the chip. One single flip-flop
might help, but I would augment it with an SRL16 delay of 16 clock ticks,
which effectively is free, using the LUT in front of the flip-flop.
Peter Alfke


Article: 74136
Subject: Re: Removing set/reset logic for shift register (HDL ADVISOR )
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Mon, 04 Oct 2004 10:50:45 -0700
Links: << >>  << T >>  << A >>
(In a discussion about reset and SRL16)

Ray Andraka wrote:

> Depends on your design and what you are willing to settle for.  Technically
> speaking, all you really need to do is provide a way of clearing stuff in your
> design tht is inside hardware loops.  For example, a state machine or an IIR
> filter have a 'loop' that needs to be broken in order to bring the hardware to a
> known state.  In many cases, it is perfectly acceptable to clear only key points
> in the design, and sometimes even require the reset be asserted for some minimum
> number of clock cycles to achieve a known state.  Yes, the easy methodology is
> to reset every flip-flop, but it is not necessary and can cost you dearly in
> terms of both gates and reset signal fan out (and therefore delay).

I believe it is important for testing purposes that a known state be
reached with a known combination of reset, clocks, and other signals.

It might be that a design would work perfectly well in any of the
possible reset states, but it wouldn't be testable.

Well, that is mostly for ASICs where test vectors need to be
supplied to the fab.  For FPGAs it might not be necessary,
though test vector sets are nice to have.

-- glen


Article: 74137
Subject: Re: question on interfacing FPGA with a sensor
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 04 Oct 2004 17:53:57 GMT
Links: << >>  << T >>  << A >>
Bidirectional communications are fine.

You probably don't need a full-blown microcontroller for the implementation,
you just need the intelligence in the FPGA to perform the proper setup and
interrogation over the link.

You could probably interface the sensor to the smallest CPLDs available with
a simple state machine.  Your FPGA choice is fine.


"Viswan" <viswan_1981@hotmail.com> wrote in message
news:c9cb3993.0410040849.608c9f4f@posting.google.com...
> hi,
>
> I have a doubt on using inout ports in FPGA design. I am implementing
> an application on FPGA, that should be interfaced to SHT71(Sensirion
> humidity and temperature sensor). My FPGA gets the value of
> temperature and humidity from the sensor and calculates
> moisture(output) using certain equations.
>
> I have designed the arithmetic unit required to calculate the moisture
> value in VHDL, and synthesized on to FPGA.  But now I have to
> interface this unit to the sensor(SHT71), and the sensor needs to have
> a controller(any microcontroller as specified in the SHT71 datasheet)
> to control its operations and get the values of temperature and
> humidity. The sensor has a bidirectional data signal as one of the
> ports, and that should be connected to the controller to send and
> receive data.  I want to implement the controller also on the same
> FPGA itself.  But is it possible?  Is it possible to handle a
> bidirectional port from an FPGA to send and receive data? I am using
> Virtex XCV800 HQ240I. Or is it suggestible to use any standard
> microcontroller as an interface between sensor and FPGA?
>
> Any suggestion on this is highly appreciated.
>
> Thanks



Article: 74138
Subject: Re: [NIOS-II SOPC] SDRAM Read Burst Cycle Length ...
From: zohargolan@hotmail.com (zg)
Date: 4 Oct 2004 11:00:20 -0700
Links: << >>  << T >>  << A >>
Hi david,

Apperently we have similar problems.
I am designing my own peripheral that needs to read/Write a word in
every clock cycle. This peipheral is connected to the SDRAM controller
as a master on the Avalon bus. What I see in simulation, when I am
connecting to the SDRAM controller, is bursts of 2 words and then 2 or
3 clocks delay etc.
I think the difference between my application (and I guess yours too)
and Kenneth's, is that Kenneth is using a DMA to burst data whereis we
are using a simple master to slave transactions. Maybe by
instantiating the DMA in the SOPC builder, the SDRAM contoller is
configured to longer bursts. I started develpoing my own SDRAM
controller that will support full page bursts, but if I will find a
way the SDRAM controller is working, I might return to it.

Zohar

"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<cjrh8o$ck5$1@news.netpower.no>...
> "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message
> news:10lnrtjlg7sff75@news.supernews.com...
> >
> > "Markus Meng" <meng.engineering@bluewin.ch> wrote in message
> > news:aaaee51b.0409290819.a6020e5@posting.google.com...
> > > Hi all [SOPC users],
> > >
> > > is there a way a can configure the read burst length of the
> > > standard SDRAM controller within SOPC 4.1?
> > >
> > > Best Regards
> > > Markus
> >
> > Hi Markus,
> >
> > You might try asking this over on the Nios Forum (www.niosforum.com).  I'd
> > like to know the answer as well.  I looked through the controller's
> > class.ptf file and even the verilog source and don't see anything.
> >
> > On writes however, I'm getting bursts of at least 480 long words at one
> > clock per word.  (my system is running at 75MHz)
> >
> 
> Did you have to do anything special to achieve that?  I have a custom
> peripheral that is writing as fast as it can to the sdram, but I'm getting
> one 32-bit write every 3 clocks.  With the prototype system I have at the
> moment, that's good enough, but I'd like to improve on it when we start
> making the real thing.  When reading, I'm getting one read every 2 clocks -
> again, it's not ideal but it works.  I'd expect one read/write per clock for
> most of the burst, with some waits while changing banks or refreshing.
> 
> Also, my reader and writer peripherals are independant, so sometimes they
> coincide.  The Avalone bus arbitration apparently cannot take bursting into
> account, and swaps between the two accesses.  Is there any way this can be
> improved upon, or do I have to implement my own mini-arbitrator to control
> the two peripherals?

Article: 74139
Subject: Re: Asynchronous reset timing problem
From: info@bostonsemiconductor.com (Chris Alexander)
Date: 4 Oct 2004 11:08:45 -0700
Links: << >>  << T >>  << A >>
david.lamb@gmail.com (David) wrote in message news:<4b5ddf5.0410040548.21c08f01@posting.google.com>...
> When I perform a post-place and route simulation, I get some timing
> errors depending on when I de-assert 'resetb' in the testbench. If it
> is too close to a rising clock edge, everything becomes red in the
> waveform. I understand there are some setup/hold conditions, but I
> wonder what will happens in real life since at 200Mhz, it looks like I
> get timing errors most of the times...actually, I need to de-assert
> resetb very close to the falling edge of the clock. Anywhere else
> gives errors. Are there any solutions to this?

I have always used asynchronous resets with an "asynchronous assert /
synchronouse de-assert" circuit.  This makes timing of the reset
release deterministic and allows asynchronous assertion.

For timing analysis it is most straightforward to just synchronize the
signal and feed your async flop resets with the synchonrous reset.

Article: 74140
Subject: Re: XC2V1000 Block RAM size
From: "Antti Lukats" <antti@case2000.com>
Date: Mon, 4 Oct 2004 12:15:55 -0700
Links: << >>  << T >>  << A >>
"Thomas Reinemann" <thomas.reinemann@masch-bau.uni-magdeburg.de> wrote in
message news:cjr0r2$jf4$1@fuerst.cs.uni-magdeburg.de...
> Hello,
>
> according Xilinx Homepage
> http://www.xilinx.com/products/tables/fpga.htm#v2 my FPGA (XC2V1000)
> should have 720 kbit Block-RAM. But if I look into it, using the FPGA
> Editor a Blockram has two units each 2048*9 bits e.g. furthermore the
> whole FPGA has 4x10 RAM blocks. This results in
> 2048*9 * 2 * 4 * 10 = 1440 kbit, of course twice of Xilinx'
> specification. Since 4 columns and 10 rows are surely right, the
> presumption of 2 units per block has to be wrong.
>
> Please point me out where I'm wrong!
>
> Bye Tom.

blockram has 2048*9 bits that look like to blocks because its dual ported
ram, the amount of bits is 2048*9 what makes the math match again right?

antti



Article: 74141
Subject: Re: Asynchronous reset timing problem
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 04 Oct 2004 13:24:14 -0600
Links: << >>  << T >>  << A >>
David wrote:
> Hello everyone, 
> I have a very basic master state machine that is clocked at 200Mhz in
> a virtexII-pro. It has an asynchronous reset input that comes from a
> push-button on the board. Code looks like this:
> 
> always @ (posedge mclk or negedge resetb)
> begin
> 	if (~resetb) begin	
> 		state <= rst;
> 	end	 
> 	else begin
> 		case(state)
> 		rst : 
> 		begin 
> 		     state <= rstInputStage;
> etc...
> 
> When I perform a post-place and route simulation, I get some timing
> errors depending on when I de-assert 'resetb' in the testbench. If it
> is too close to a rising clock edge, everything becomes red in the
> waveform. I understand there are some setup/hold conditions, but I
> wonder what will happens in real life since at 200Mhz, it looks like I
> get timing errors most of the times...actually, I need to de-assert
> resetb very close to the falling edge of the clock. Anywhere else
> gives errors. Are there any solutions to this?
> Thanks,
> David

There are two issues here:  a design issue and a tool issue.  To address 
the tool issue, if you are using ModelSim, you probably want to use the 
-notimingchecks option.  Look this up in the documentation.  This will 
prevent setup errors from being propagated as X's.  -Kevin

Article: 74142
Subject: Re: FPGA servo motor controller
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Mon, 04 Oct 2004 13:30:39 -0600
Links: << >>  << T >>  << A >>
iceman wrote:

> ei anyone can help me with the algorithm on how to control a
> servomotor... cause we are gonna use it on our thesis... by the it's
> called "FPGA based intravenous infusion monitoring and control system"
> 
> can anyone help us out on how to control a servomotor...will be using
> the servomotor to clamp the tube of an I.V.(intravenous) tube... the
> flow of the algorithm will bw this... first a personnel will input how
> many dosage a patient gets and then the servomotor will clamp the I.V.
> tube so that the desired dosage is achive... by the way will be using
> optical sensors to monitor the drops of the I.V. fluid i will be
> placed at the outside of the drip chamber...
> 
> but we have a problem what if the drip of the fluid change how will
> the servomotor adjust it so that the dosage will be maintained...will
> use a feedback but how are we gonna implement it on FPGA..
> 
> got any suggestion on the algorithm... or any sites that can help us
> solve this problem

Is the volume of a drop constant no matter the drip rate?

Controlling R/C servomotors is pretty easy.  There is lots of info on 
the web.  I think the position is controlled by the length of an input 
pulse.  Maybe a better method would be to use a stepper motor connected 
to a wormscrew clamp.  Then you could control the absolute position 
(rather than relative) better.  -Kevin

Article: 74143
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Mon, 4 Oct 2004 13:57:34 -0700
Links: << >>  << T >>  << A >>

"Paul Leventis (at home)" <paulleventis-news@yahoo.ca> wrote in message
news:_6KdnS3Cx_w3m8PcRVn-iQ@rogers.com...

> Hi Martin,
[snip]
>
> > Both devices used are the fastest speed grade available. Is the Cyclone,
> > although 'older', faster than the Spartan-3?
>
> Yes.  This performance result is actually pretty poor as far as Cyclone
vs.
> Spartan-3 goes.  We see an average of 80% better performance -- yes,
that's
> 1.8X Fmax -- when comparing the fastest speed grades of the two chips with
> default "push-button" results from Quartus & ISE over a suite of 49
designs.
> Another way of looking at it is the slowest Cyclone speed-grade
out-performs
> the fastest Spartan-3 speed-grade by a considerable margin.  See
>
http://www.altera.com/products/devices/performance/lowcost_performance/per-lowcost_performance_fpga.html
> for details.

Danger, Danger, Will Robinson, my B.S. sensors have detected significant
marketing content.  :-)

As made famous by Philip Freidin (www.fliptronics.com), "There are four
kinds of lies.

1.  Lies
2.  Damn lies
3.  Statistics
4.  Benchmarks  <--- *****

and in a category all by themselves, 'expense reports'".

Like Altera, Xilinx marketing has a benchmark suite showing that Spartan-3
performs better than Cyclone (shocking, I know).  My own personal suite uses
more typical customer designs and shows a healthy mix of wins and losses,
very much depending on the characteristics of the design.

If Cyclone were _really_ 80% faster on _average_ than Spartan-3 comparing
fastest to fastest speed grades, do you _really_ think that this real-world
customer design, using out-of-the-box, default "push-button" settings, is
all that pathological?  The two out-of-the-box results were roughly the same
when you compare the slowest speed grades for each family.

Cyclone -8 speed grade (slowest speed grade):  77.5 MHz
Spartan-3 -4 speed grade (slowest speed grade):  77.8 MHz

This is further borne out when you consider that Xilinx chose to have only
two speed grades for Spartan-3.  For Xilinx devices, a speed grade
represents about a 15% speed difference.

Cyclone -6 speed grade (fastest of 3 speed grades):  98 MHz
Spartan-3 -5 speed grade (fastest of 2 speed grades):  82 MHz
15% over Spartan-3 -5 would result in 96.5 MHz

The comments about tweaking the default settings is very appropriate.
Changing a few of the default settings can have dramatic effect.  Likewise,
small changes in coding can shave a layer or two of logic in a critical
clock path.

We cover some of these techniques at the upcoming Programmable World seminar
series.  (Danger, danger, Marketing content follows!)

Programmable World 2004
http://www.xilinx.com/events/pw2004/

In specific, check out Workshop 3 in the Logic track.

Workshop 3:  Spartan-3 and Low-Cost FPGA Design Techniques.
http://www.xilinx.com/events/pw2004/tracks/logic.htm
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC








Article: 74144
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Mon, 4 Oct 2004 14:04:05 -0700
Links: << >>  << T >>  << A >>

"Martin Schoeberl" <martin.schoeberl@chello.at> wrote in message
news:sjA7d.330096$vG5.66679@news.chello.at...
> > As a quick aside, Cyclone has three speed grades, Spartan-3 only two.
> In
> > general, a speed grade represents about a 15% difference in
> performance.
> >
> > Slowest vs. slowest speed grade would be interesting.
>
> Ok, here it is:
> Cyclone slowest (-8): 77.5MHz
> Spartan slowest (-4): 77.8MHz
> Looks now better for X....

Thank you.  The results were about what I expected.

> And now let's throw in some price numbers. Prices are single units from
> arrow.com and avnet.com, both devices in the same package (tqfp144):
> Cyclone: EP1C6T144C6: $41.60
> Cyclone: EP1C6T144C8: $27.70
> Spartan-3: XC3S200-4TQ144C: $19.93
> no price for -5 speed grade
>
> And relate the price to density and speed in a 'funny' way:
> price / 1000 LCs / MHz:
>
> EP1C6-6: 41.60$ / 5.980 kLC / 98 MHz = 7.1 cent / kLC / MHz
> EP1C6-8: 5.98 cent / kLC /MHz
> XC3S200-T: $19.93 / 3.840 kLC / 77.8 MHz = 6.7 cent / kLC /MHz
> and now it looks again better for A...

[snip]

Be careful with this kind of analysis.  Yes, it's helpful from an academic
point.  However, the Spartan-3 XC3S1000 offers a sweet spot on cost per
logic cell.  Does this mean that everyone should use the XC3S1000 when a
smaller part will do?  No, you want to choose the lowest cost part that gets
the job done.

BTW, nice job on the Java processor!  Very cool.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC



Article: 74145
Subject: Re: JOP on Spartan-3 Starter Kit
From: "Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com>
Date: Mon, 4 Oct 2004 14:14:26 -0700
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:wBG7d.6267$mZ2.556191@news02.tsnz.net...
> Martin Schoeberl wrote:
> > Btw, does somebody know why the lead free devices are more expensive. I
> > did'n know up to now that semiconductors contain lead. I only know that
> > it's part of the solder and when it's forbidden will probably increase
> > production cost of PCBs.
> >>The alloid used are more complex and uses more precious metals. (for
> >>the solder balls and solder plating of terminal)
> >>Sn/Pb before
> >>and now, like Nickel/Palladium
> >
> >
> > Solder balls ok, but that difference in QFP packages?
>
>   That's an easy one : because they can.
> It's a good place to do a little cost recovery/price racking,
> as users will have designed in the devices, and are thus captive
> by both the legistation and the layout, plus many do not
> compare Pb/PbFree prices, so that's the ideal time to nudge the
> prices!

There are two reasons behind the price difference between the standard Sn/Pb
packages and the Pb-free packages.

The number one price difference is due to volume.  I don't have specific
data at my fingertips but the Sn/Pb packages are produced in significantly
larger quantities.  In the semiconductor business, bigger volumes mean lower
unit cost.  The Pb-free packages are a relatively recent addition.  I would
expect that prices will drop to a certain extent as these packages become
more the norm.

The second reason is content.  Sn and Pb are inexpensive.  The Ag and Cu in
the Pb-free alloy is more expensive.

For more information, check out the following Xilinx application note.  Note
that the standard and Pb-free packages may require different assembly
techniques.

XAPP427:  Implementation and Solder Reflow Guidelines for Pb-Free Packages
http://www.xilinx.com/bvdocs/appnotes/xapp427.pdf

Also, just FYI for those that care, all Spartan-3 devices are available in
Pb-free versions of all supported package types.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3:  Make it Your ASIC



Article: 74146
Subject: Re: [NIOS-II SOPC] SDRAM Read Burst Cycle Length ...
From: kempaj@yahoo.com (Jesse Kempa)
Date: 4 Oct 2004 14:34:03 -0700
Links: << >>  << T >>  << A >>
> Did you have to do anything special to achieve that?  I have a custom
> peripheral that is writing as fast as it can to the sdram, but I'm getting
> one 32-bit write every 3 clocks.  With the prototype system I have at the
> moment, that's good enough, but I'd like to improve on it when we start
> making the real thing.  When reading, I'm getting one read every 2 clocks -
> again, it's not ideal but it works.  I'd expect one read/write per clock for
> most of the burst, with some waits while changing banks or refreshing.
> 
> Also, my reader and writer peripherals are independant, so sometimes they
> coincide.  The Avalone bus arbitration apparently cannot take bursting into
> account, and swaps between the two accesses.  Is there any way this can be
> improved upon, or do I have to implement my own mini-arbitrator to control
> the two peripherals?

Hi David,

There are a number of factors that affect SDRAM performance in the
general sense. Typically you'll achieve best performance (approaching
one clock per word read or write) if the accesses to SDRAM that are
presented by your peripheral are burst-like. That is, you are reading
from or writing to sequential accesses without interruption; this
applies to our SDRAM controller.
Even when transactions are optimal, you'll still face the occasional
bank-switch delay when your address causes a bank changes, and of
course, the inevitable refresh delay every so often.

By contrast "thrashing" SDRAM, like thrashing a microprocessor cache,
will have negative performance consequences... by thrash I mean
accesses that are all over the place, requiring the SDRAM controller
to take time switching banks continuously.

To address your concerns: first, we have some enhancements to Avalon
in the works that will address a lot of these problems for the case
you present (wanting to achieve burst-performance between multiple
peripherals). If the results you're getting are good enough for now,
I'd suggest waiting for the next SOPC Builder release as it will
include these Avalon enhancements.

If you need better performance right now with your setup, feel free to
send me an email and I'd be happy to give you a few pointers (about
avalon arbitration and a couple other things) that may help.

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 74147
Subject: Re: [NIOS-II SOPC] SDRAM Read Burst Cycle Length ...
From: Ben Twijnstra <btwijnstra@chello.nl>
Date: Mon, 04 Oct 2004 21:37:54 GMT
Links: << >>  << T >>  << A >>
Kenneth Land wrote:

> 
> "Markus Meng" <meng.engineering@bluewin.ch> wrote in message
> news:aaaee51b.0409290819.a6020e5@posting.google.com...
>> Hi all [SOPC users],
>>
>> is there a way a can configure the read burst length of the
>> standard SDRAM controller within SOPC 4.1?
>>
>> Best Regards
>> Markus
> 
> Hi Markus,
> 
> You might try asking this over on the Nios Forum (www.niosforum.com).  I'd
> like to know the answer as well.  I looked through the controller's
> class.ptf file and even the verilog source and don't see anything.
> 
> On writes however, I'm getting bursts of at least 480 long words at one
> clock per word.  (my system is running at 75MHz)
> 
> Ken

Have you guys looked at increasing the arbitration priority for the SDRAM
controller? The NIOS needs to fetch opcodes every once in awhile.

Ben


Article: 74148
Subject: Re: JOP on Spartan-3 Starter Kit
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 05 Oct 2004 11:38:07 +1300
Links: << >>  << T >>  << A >>
Steven K. Knapp wrote:
> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> news:wBG7d.6267$mZ2.556191@news02.tsnz.net...
> 
>>Martin Schoeberl wrote:
>>
>>>Btw, does somebody know why the lead free devices are more expensive. I
>>>did'n know up to now that semiconductors contain lead. I only know that
>>>it's part of the solder and when it's forbidden will probably increase
>>>production cost of PCBs.
>>>
>>>>The alloid used are more complex and uses more precious metals. (for
>>>>the solder balls and solder plating of terminal)
>>>>Sn/Pb before
>>>>and now, like Nickel/Palladium
>>>
>>>
>>>Solder balls ok, but that difference in QFP packages?
>>
>>  That's an easy one : because they can.
>>It's a good place to do a little cost recovery/price racking,
>>as users will have designed in the devices, and are thus captive
>>by both the legistation and the layout, plus many do not
>>compare Pb/PbFree prices, so that's the ideal time to nudge the
>>prices!
> 
> 
> There are two reasons behind the price difference between the standard Sn/Pb
> packages and the Pb-free packages.
> 
> The number one price difference is due to volume.  I don't have specific
> data at my fingertips but the Sn/Pb packages are produced in significantly
> larger quantities. 
<snip>

  I thought one of the targets of PbFree was to try and get a 
package/alloy solution that could be used in either flow ( and
so the Pbfree would be phased in, to replace the older ones )

  Is that turning out to not be practical ?

  Also IIRC 'PbFree' actually means < 0.1% by weight ?

-jg


Article: 74149
Subject: Re: FPGA vs ASIC area
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 04 Oct 2004 19:09:10 -0400
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> > From: rickman <spamgoeshere4@yahoo.com>
> > Reply-To: john@bluepal.net
> > Newsgroups: comp.arch.fpga
> > Date: Sun, 03 Oct 2004 00:28:04 -0400
> > Subject: Re: FPGA vs ASIC area
> >
> >
> >
> > Austin, Peter sends me private emails asking me to ignore your
> > nonsense.
> 
> This is a blatant lie (plus a breach of confidence). 

Which is it, a lie or a breach of confidence???  Besides, I don't recall
you asking that I keep it a secret.  You just asked me not to argue with
him.  


> I had only asked Rick
> to make peace with Austin, and accept the fact that he has a different style
> than mine.. 

Perhaps I didn't get the words exactly right, but you acknowledge the
concept.  My point was that even you understand that he goes beyond the
norm in his posts.  


> Nobody will push a wedge between me and Austin. We are
> neighbors, partners, and friends, and complement and help each other every
> day in many ways.

No one is trying to spilt you two up.  You can sit next to each other as
much as you want.  


> This thread seems to have run its course. The original question about the
> area ratio between ASICs and FPGA was (as I wrote) meanigless and cute.
> Which one is smaller, uses which process, and takes how long to test is all
> reflected in one single number, the price charged by the vendor. And there
> is intense competition which keeps us all on our toes...
> 
> The user (that is most of the people in this newsgroup) should only be
> interested in cost, performance, power consumption, design effort,
> reprogrammability, time to market, availability, and general risk.
> Smart engineers will know how to make a rational choice.

Yes, that is the opinion I have stated exactly.  The end user does not
care about the details of how results are obtained since there are far
too many details for any one to be an indicator. 


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX



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