Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 105550

Article: 105550
Subject: Re: 2Khz clock signal from 50Hz main frequency with ADPLL
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 26 Jul 2006 08:10:09 +1200
Links: << >>  << T >>  << A >>
raso wrote:
> Dear Jan,
> 
> This part is not a problem at all.
> 
> What I need to do is to keep the number of 2Khz pulses
> same as the main 50Hz changes. In perfect condition
> there are fourty 2Khz cycles within one 50Hz period  (20ms/500us).
> When 50Hz changes (+/- 0.5Hz), 2KHz pulse period should also
> chance accordingly to stay in lock.
> 
> My system clock is 60MHz. I implemented a JK phase detector, a
> K-counter and a DCO in order to generate 2KHz pulses and this system
> operates at system clock. The
> output locks to exact 50Hz very quickly (fed from signal generator),
> but when I change the reference clock to, lets say, 50.1Hz it starts
> drifting.

  You will also get phase jitter on Mains 50Hz references, as well as
the frequency drifts - in most countries they try and keep the number of
cycles in a day correct, for operating clocks.
  So, you need to realise this will always be a historical-fit based 
lock. What you decide for the next mains cycle might not actually be 
correct, but you can make a best guess based on the pevious ones.

With MHz to burn, and FPGA, why not use a
Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking 
Up/down coounter on the index.
It can be 100% digital, and the tracking speed becomes the PLL-LPF.

Looks like you need to track 1% dF, keeping a nominal 40 clocks / cycle,
with a possible divide of 30,000 (!), that should be do-able :)

Many mains systems use zero crossing phase lock, and do not bother about 
the small freqency variations.

-jg


Article: 105551
Subject: uClinux on Virtex-4 Mini-Module
From: "Guru" <ales.gorkic@email.si>
Date: 25 Jul 2006 14:00:30 -0700
Links: << >>  << T >>  << A >>
Hi Folks,

Does anybody has any experience with uClinux running on Virtex4FX12
(ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to
the OS if I have a normal Linux version drivers?
I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module,
because FLASH for standalone operation is only 4MB deep. This is not
enough for any other OS with TCP/IP support (or a TCP/IP stack).

Cheers,

Guru


Article: 105552
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: "EEngineer" <maricic@gmail.com>
Date: 25 Jul 2006 15:17:35 -0700
Links: << >>  << T >>  << A >>

Finally after two weeks I have configured the board for the first time.
I was misled that software update was performed every time I start the
ISE with WebUpdate, but that was not the case - after you mentioned SP
(it was not the one for Windows XP) I went to the update section of the
web site and installed SP 3. I am able to generate ACE files that work.

Can I interface the board's J6 header single ended  signal connections
with the parallel port on the PC with no buffer and what constrains
should be asserted for those pins?
Thanks for all your help,

Dan

Ed McGettigan wrote:
> EEngineer wrote:
> >  I use:
> >
> > Service Pack 1
> >
>
> I would definitely try upgrading to Service Pack 3.
> 
> Ed McGettigan
> -- 
> Xilinx Inc.


Article: 105553
Subject: Re: 2Khz clock signal from 50Hz main frequency with ADPLL
From: "raso" <rasit.sahin@yahoo.co.uk>
Date: 25 Jul 2006 15:58:07 -0700
Links: << >>  << T >>  << A >>
Hi Jon,

Falk Brunner sent me his VHDL implementation of 74LS297. I modified it
so that K-counter and I/D counter (DCO) run at system clock which is
30MHz.

The system has following blocks;

- The first component is an JKFF based phase detector.
- Then, there is a K-counter operating at 30MHz. With 30MHz clock, a
full 50Hz
period means M=30e6/50=600000 ticks. For minimum jitter, modulus of K
counter is set M/2 which is 300000. The borrow pulse decreases the
modulus of I/D counter (2KHz DCO) while carry pulse increases it by 1.
So in locked condition, it generates 1 carry and 1 borrow pulse within
one 50Hz period and they cancel each other.
- I/D counter is a DCO (modulus counter). It operates  at 30MHz. When
it is locked to 50Hz it has modulus of 15000. When 50Hz changes, the
borrow and carry pulses should adjust the modulus of I/D counter (carry
pulse increases the modulus by 1, and borrow decreases it by 1). By
this way, period of 2kHz pulses is adjusted according to 50Hz input.
- N-Counter which devides 2Khz clock by 40.

The only parameter that I can play with is the modulus of K counter.

I can't use direct implementation of 74LS297. Because, it syncronises
f_in and f_out by inserting or deleting 2KHz pulses (I/D pulses). I
can't tolerate inserting or deleting 2KHz pulses. It has to keep the
number of 2kHz pulses as 40 in each 50Hz period.

Isa

Jon Elson wrote:
> raso wrote:
>
> >Hello everyone,
> >
> >I would like to ask if it is possible to generate 2Khz clock signal
> >from 50Hz main frequency
> >using an ADPLL. I have tried SN297 circuit implementation, but couldn't
> >achieve it.
> >
> >
> The 74LS297 has a VERY narrow lock range, compared to traditional
> analog PLL's.  It is generally a fraction of a percent, but I think there
> is a setting that gives you a couple percent range.  It works fine for
> syncing between a data source running on one xtal clock, from another
> xtal clock.  You would need a digital clock (quartz crystal) that is at
> some multiple of 50 Hz (not too hard).  Then, you'd need a couple of
> long counter chains to do the divide down.
>
> Are you using an HLL library version of the 74LS297 circuit?  If so,
> where did you get it?  I happen to use the real TI chip in one device I
> built, and a synthesizable version might be good to know about.
> 
> Jon


Article: 105554
Subject: Re: 2Khz clock signal from 50Hz main frequency with ADPLL
From: "raso" <rasit.sahin@yahoo.co.uk>
Date: 25 Jul 2006 16:00:07 -0700
Links: << >>  << T >>  << A >>
Dear Jim,

Could you please explain your idea below?

>> With MHz to burn, and FPGA, why not use a
>> Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking
>> Up/down coounter on the index.
>> It can be 100% digital, and the tracking speed becomes the PLL-LPF.

Many thanks,
Isa

Jim Granville wrote:
> raso wrote:
> > Dear Jan,
> >
> > This part is not a problem at all.
> >
> > What I need to do is to keep the number of 2Khz pulses
> > same as the main 50Hz changes. In perfect condition
> > there are fourty 2Khz cycles within one 50Hz period  (20ms/500us).
> > When 50Hz changes (+/- 0.5Hz), 2KHz pulse period should also
> > chance accordingly to stay in lock.
> >
> > My system clock is 60MHz. I implemented a JK phase detector, a
> > K-counter and a DCO in order to generate 2KHz pulses and this system
> > operates at system clock. The
> > output locks to exact 50Hz very quickly (fed from signal generator),
> > but when I change the reference clock to, lets say, 50.1Hz it starts
> > drifting.
>
>   You will also get phase jitter on Mains 50Hz references, as well as
> the frequency drifts - in most countries they try and keep the number of
> cycles in a day correct, for operating clocks.
>   So, you need to realise this will always be a historical-fit based
> lock. What you decide for the next mains cycle might not actually be
> correct, but you can make a best guess based on the pevious ones.
>
> With MHz to burn, and FPGA, why not use a
> Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking
> Up/down coounter on the index.
> It can be 100% digital, and the tracking speed becomes the PLL-LPF.
>
> Looks like you need to track 1% dF, keeping a nominal 40 clocks / cycle,
> with a possible divide of 30,000 (!), that should be do-able :)
>
> Many mains systems use zero crossing phase lock, and do not bother about
> the small freqency variations.
> 
> -jg


Article: 105555
Subject: Re: Virtex 4 ACE Compact Flash configuration problem
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 25 Jul 2006 16:25:21 -0700
Links: << >>  << T >>  << A >>
EEngineer wrote:
> Finally after two weeks I have configured the board for the first time.
> I was misled that software update was performed every time I start the
> ISE with WebUpdate, but that was not the case - after you mentioned SP
> (it was not the one for Windows XP) I went to the update section of the
> web site and installed SP 3. I am able to generate ACE files that work.
> 
> Can I interface the board's J6 header single ended  signal connections
> with the parallel port on the PC with no buffer and what constrains
> should be asserted for those pins?
> 

I'm glad that you are moving forward with your design work.

On the second item the answer is no as a parallel port is 5V and the
IOs on the headers are 2.5V (or 3.3V if you move a jumper).

Ed McGettigan
--
Xilinx Inc.

Article: 105556
Subject: Re: Virtex4 Rocket I/O. Power filtering.
From: Mark McDougall <markm@vl.com.au>
Date: Wed, 26 Jul 2006 10:23:54 +1000
Links: << >>  << T >>  << A >>
Symon wrote:

> From this, and if I don't use any receivers in the column, I deduce that I 
> can leave AVCCAUXRXA unfiltered. Right?

From the paragraph immediately above the one you quoted, I'm assuming so
in my design as well...

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 105557
Subject: Re: 2Khz clock signal from 50Hz main frequency with ADPLL
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 26 Jul 2006 12:49:14 +1200
Links: << >>  << T >>  << A >>
raso wrote:
> Dear Jim,
> 
> Could you please explain your idea below?
> 
> 
>>>With MHz to burn, and FPGA, why not use a
>>>Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking
>>>Up/down coounter on the index.
>>>It can be 100% digital, and the tracking speed becomes the PLL-LPF.

In broad terms:

Table method:

Measure 50Hz (half?) period. appx 50KHz timebase resolves to 0.1%
eg gets 20.2ms : Trim and Scale the result, into a lookup table, that
then loads the 2KHz divider.
( Suppose you target improve of +/- 1% to +/- 0.1%, that is a ~20 entry 
table.

Keeping to 0.1%, 2KHz to 0.1% is 2MHz Clock, with ~1000 divider values.

Table/ROM has 20 entries, of 11 bit binary values.

Each new cycle uses the last cycles period, to get a best fit of 40 
'2Khz' clocks.

  Tracking counter Method :
Count the 2KHz clocks you actually get, in a 50Hz period.

  For 2KHz, create an 11 bit Divider(from 2MHz), fed from an 11 bit 
Up/Dn counter.
  If the Counts_2Khz is ABOVE 40, then Increment the Up/Dn counter, if it
is BELOW 40, decrement the Up/Dn counter.
( for higher precision, you might count higher in the divider than 2Khz 
- you have not given desired jitter/precision values )

  These lock frequecy, or cycles, but do not lock phase.

Most main systems will reset/load the 2KHz on zero cross, to phase lock
that. You also want to freqency lock, to have a known phase stepping.

-jg






> 
> 
> Many thanks,
> Isa
> 
> Jim Granville wrote:
> 
>>raso wrote:
>>
>>>Dear Jan,
>>>
>>>This part is not a problem at all.
>>>
>>>What I need to do is to keep the number of 2Khz pulses
>>>same as the main 50Hz changes. In perfect condition
>>>there are fourty 2Khz cycles within one 50Hz period  (20ms/500us).
>>>When 50Hz changes (+/- 0.5Hz), 2KHz pulse period should also
>>>chance accordingly to stay in lock.
>>>
>>>My system clock is 60MHz. I implemented a JK phase detector, a
>>>K-counter and a DCO in order to generate 2KHz pulses and this system
>>>operates at system clock. The
>>>output locks to exact 50Hz very quickly (fed from signal generator),
>>>but when I change the reference clock to, lets say, 50.1Hz it starts
>>>drifting.
>>
>>  You will also get phase jitter on Mains 50Hz references, as well as
>>the frequency drifts - in most countries they try and keep the number of
>>cycles in a day correct, for operating clocks.
>>  So, you need to realise this will always be a historical-fit based
>>lock. What you decide for the next mains cycle might not actually be
>>correct, but you can make a best guess based on the pevious ones.
>>
>>With MHz to burn, and FPGA, why not use a
>>Freqency Counter/IndexCounter/LoadableDivider, with a slow tracking
>>Up/down coounter on the index.
>>It can be 100% digital, and the tracking speed becomes the PLL-LPF.
>>
>>Looks like you need to track 1% dF, keeping a nominal 40 clocks / cycle,
>>with a possible divide of 30,000 (!), that should be do-able :)
>>
>>Many mains systems use zero crossing phase lock, and do not bother about
>>the small freqency variations.
>>
>>-jg
> 
> 


Article: 105558
Subject: Designing a matrix multpier block using existing xilinx toolbox
From: "sirisha.aluru@gmail.com" <sirisha.aluru@gmail.com>
Date: 25 Jul 2006 17:55:29 -0700
Links: << >>  << T >>  << A >>
hi everyone,
for my class project i need to build a model in simulink , using xilinx
system generator blocks..which computes matrix multiplication about
512X512 size...can anyone help me how to do it with black box.........i
tried Mcode but didnt work...........
thanks in advance


Article: 105559
Subject: Spartan 3 clock to output tristate timing
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 25 Jul 2006 18:14:42 -0700
Links: << >>  << T >>  << A >>
I've got a problem at work where the FPGA group is at war with the
hardware group and I am sick and tired of ducking the punches.  I
designed the board although there was not a lot of original design.  I
was told what main chips to use since they had done a similar design
before.  So I pretty much copied the design which uses an XC3S400-4 and
a TMS320VC5510 with a combined SRAM/Flash chip.  I am being asked for a
proper bus timing analysis and I need the data on the FPGA.  That is
where the punches start flying!

The bus is asynchronous, but for whatever reason, the FPGA designers
originally chose to use the CLKOUT from the DSP as the interface clock
rather than the other clock being provided to the FPGA.  This may be
because although the DSP memory interface is designed to work with
async bus devices like RAMs and Flash, all the timing parameters are
WRT the DSP CLKOUT.  However, the timings are such that you can't use
CLKOUT to clock in the signals in a synchronous manner.  The signal
transitions are on the rising clock edge +- a few ns.  The clock is
about 10 ns period.  When it is matched to the FPGA IO timing I don't
think you can meet the setup and hold times from what I have seen and I
am told the design double clocks all inputs to remove metastability.

To do the timing analysis, I have asked the FPGA group to provide
timing data on the FPGA.  I expected them to come back with the data
they are using for timing constraints.  Instead they basically told me
"you don't need no stinkin' timing data".  They seem to feel that
because we are using lots of clock cycles on the bus cycle, the
detailed timing is not important.  We have gone around a few times and
I continue to assert that there are a few parameters that I need from
the FPGA design such as the time from the RD_N signal rising to the
data out going high-Z.  After half a dozen emails, I finally got an
answer of 16 ns.  But I realized that I can't believe this since it was
presented as a measurement from one iteration of the design.  I looked
at the timing constraints and they don't have any other than the
clocks!

Today in a meeting the FPGA supervisor told me that this timing
parameter was from the Spartan data sheet since it is the time from a
clock input through an IOB FF that controls the tristate buffer.  When
I checked the data sheet I can't find such a timing parameter and the
data I do find says the time in the IOB itself is less than 1 ns under
the given conditions.

"Time from the active transition at the OTCLK input of the Three-state
Flip-Flop (TFF) to when the Output pin enters the high-impedance state
(LVCMOS25, 12mA output drive, Fast slew rate) All 0.28 0.74 0.85 ns"

Our interface is 3.3 volts and the worst case adjustment I can find is
"LVTTL Slow 2 mA 2.76 7.27 8.36 ns".  So we still end up at well less
than 10 ns without counting the clock delay.  They seem to be using the
DCMs, but I can't say how they have them set up.  Even so, with the DCM
the clock input to output pin (through an IOB FF) is under 2 ns and
even without the DCM it is under 5 ns.  So giving the most leeway I
possibly can I still come up with less than 15 ns for clock to output
high-Z compared to 16 ns.

That leaves these possibilities...
1) I don't know what I am doing and the above rational is full of
holes.
2) This supervisor is incompetent.
3) This supervisor is deliberately misleading us to cover someone
else's incompetence.
4) ???

I am getting so tired of having to sift through the BS that the other
departments are feeding me that I am close to quitting.  But before I
do, I want to get to the bottom of this.  Have I completely
misunderstood how the tristate outputs work somehow?  Is there a number
in the data sheet that justifies the 16 ns number somewhere?

In reality I expect this signal path is going through logic inside the
chip and is not being clocked in the IOB.  The 16 ns number most likely
came from a measurement of one iteration of the chip.  I may take the
time to dig into the design files at some point.  But first I would
just like to get a sanity check on the idea that the 16 ns number came
from the data sheet as a path from the clock input to an output going
high-Z.  

So who is nuts, me or the other guy???  (or is it both?  ;^)


Article: 105560
Subject: Re: Spartan 3 clock to output tristate timing
From: "RobJ" <rob@abc.net>
Date: Wed, 26 Jul 2006 04:36:35 GMT
Links: << >>  << T >>  << A >>
First of all, calm down! Next, it's not clear from your post what the 
interface timing requirements are. Does the FPGA terminate the bus cycles or 
is the cycle timing fixed (either hard-wired or programmed in the DSP)? 
Regardless, there are only a few critical timing parameters on an interface 
like this. On write cycles the FPGA has to latch the write data before it 
goes away, and on read cycles it has to present valid data to the DSP when 
the DSP is latching it, and it has to get off the bus before another device 
tries to drive it.

On write cycles I usually try to detect the start of the write cycle (e.g., 
falling edge of cs/ with the rd_wr/ line low), synchronize it, and turn it 
into a 1-cycle pulse used as a clock enable to latch the write data. The 
only analysis needed is to make sure the write data is still valid at the 
latching flip-flops when the 1-cycle pulse is asserted under all possible 
timing circumstances. And you have to know how to generate that pulse 
correctly.

On reads, I don't understand the obsession with an exact number for the OBUF 
turn-off time. Personally I wouldn't even do that synchronously. I would 
just use the cs/ from the DSP directly as the oe/ for the OBUFs (qualified, 
of course, so that the FPGA only drives the bus during read cycles). Making 
that path combinational makes the timing contraints easier, and the static 
timing report will indicate clearly for each re-route if you made the 
constraint or not. All you need is a max pad-to-pad delay such that the FPGA 
quits driving within ??ns of the deassertion of cs/. The tools will take 
into account the worst-case OBUF turn-off time. The timing analysis and 
constraints get more complicated with an async bus if you generate a clocked 
oe/.

As the board designer you should be telling the FPGA group the interface 
timing they have to meet, so what you're doing sounds like the tail wagging 
the dog anyway. You give them numbers and they tell you whether or not they 
can meet them. I've seen you post before about these "wars" at work. Sounds 
like a bunch of b.s. turf wars to me. Do yourself a favor and move on.

Rob

"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:1153876482.253224.323960@s13g2000cwa.googlegroups.com...
> I've got a problem at work where the FPGA group is at war with the
> hardware group and I am sick and tired of ducking the punches.  I
> designed the board although there was not a lot of original design.  I
> was told what main chips to use since they had done a similar design
> before.  So I pretty much copied the design which uses an XC3S400-4 and
> a TMS320VC5510 with a combined SRAM/Flash chip.  I am being asked for a
> proper bus timing analysis and I need the data on the FPGA.  That is
> where the punches start flying!
>
> The bus is asynchronous, but for whatever reason, the FPGA designers
> originally chose to use the CLKOUT from the DSP as the interface clock
> rather than the other clock being provided to the FPGA.  This may be
> because although the DSP memory interface is designed to work with
> async bus devices like RAMs and Flash, all the timing parameters are
> WRT the DSP CLKOUT.  However, the timings are such that you can't use
> CLKOUT to clock in the signals in a synchronous manner.  The signal
> transitions are on the rising clock edge +- a few ns.  The clock is
> about 10 ns period.  When it is matched to the FPGA IO timing I don't
> think you can meet the setup and hold times from what I have seen and I
> am told the design double clocks all inputs to remove metastability.
>
> To do the timing analysis, I have asked the FPGA group to provide
> timing data on the FPGA.  I expected them to come back with the data
> they are using for timing constraints.  Instead they basically told me
> "you don't need no stinkin' timing data".  They seem to feel that
> because we are using lots of clock cycles on the bus cycle, the
> detailed timing is not important.  We have gone around a few times and
> I continue to assert that there are a few parameters that I need from
> the FPGA design such as the time from the RD_N signal rising to the
> data out going high-Z.  After half a dozen emails, I finally got an
> answer of 16 ns.  But I realized that I can't believe this since it was
> presented as a measurement from one iteration of the design.  I looked
> at the timing constraints and they don't have any other than the
> clocks!
>
> Today in a meeting the FPGA supervisor told me that this timing
> parameter was from the Spartan data sheet since it is the time from a
> clock input through an IOB FF that controls the tristate buffer.  When
> I checked the data sheet I can't find such a timing parameter and the
> data I do find says the time in the IOB itself is less than 1 ns under
> the given conditions.
>
> "Time from the active transition at the OTCLK input of the Three-state
> Flip-Flop (TFF) to when the Output pin enters the high-impedance state
> (LVCMOS25, 12mA output drive, Fast slew rate) All 0.28 0.74 0.85 ns"
>
> Our interface is 3.3 volts and the worst case adjustment I can find is
> "LVTTL Slow 2 mA 2.76 7.27 8.36 ns".  So we still end up at well less
> than 10 ns without counting the clock delay.  They seem to be using the
> DCMs, but I can't say how they have them set up.  Even so, with the DCM
> the clock input to output pin (through an IOB FF) is under 2 ns and
> even without the DCM it is under 5 ns.  So giving the most leeway I
> possibly can I still come up with less than 15 ns for clock to output
> high-Z compared to 16 ns.
>
> That leaves these possibilities...
> 1) I don't know what I am doing and the above rational is full of
> holes.
> 2) This supervisor is incompetent.
> 3) This supervisor is deliberately misleading us to cover someone
> else's incompetence.
> 4) ???
>
> I am getting so tired of having to sift through the BS that the other
> departments are feeding me that I am close to quitting.  But before I
> do, I want to get to the bottom of this.  Have I completely
> misunderstood how the tristate outputs work somehow?  Is there a number
> in the data sheet that justifies the 16 ns number somewhere?
>
> In reality I expect this signal path is going through logic inside the
> chip and is not being clocked in the IOB.  The 16 ns number most likely
> came from a measurement of one iteration of the chip.  I may take the
> time to dig into the design files at some point.  But first I would
> just like to get a sanity check on the idea that the 16 ns number came
> from the data sheet as a path from the clock input to an output going
> high-Z.
>
> So who is nuts, me or the other guy???  (or is it both?  ;^)
> 



Article: 105561
Subject: Re: Spartan 3 clock to output tristate timing
From: John_H <johnhandwork@mail.com>
Date: Wed, 26 Jul 2006 05:57:45 GMT
Links: << >>  << T >>  << A >>
Rickman - sorry you have to deal with such annoyances.  I'm a stickler 
for well defined I/O constraints so I see shoddy engineering on the part 
of the FPGA group, but that's me.

The "data sheet" is probably not what you think.

The Timing Analyzer within the Xilinx tool suite has a section at the 
end that summarizes data input setup and hold times as well as 
clock-to-out for all the various signals.  I believe the clock and clock 
edge are included as well.  While I specify my PCI numbers with one 
value in my constraints for Tcko and another for the turnaround cycle - 
Toff - it's the longest value that ends up in the "Data Sheet" section 
of the Timing Analyzer report which would be the Ton/Toff.

It's probably the timing for one *iteration* of the FPGA but worst case 
values, not measured.  As long as the design doesn't budge, great. 
Otherwise, the next rev could move the unconstrained I/O around one 
direction or another.


rickman wrote:
> I've got a problem at work where the FPGA group is at war with the
> hardware group and I am sick and tired of ducking the punches.  I
> designed the board although there was not a lot of original design.  I
> was told what main chips to use since they had done a similar design
> before.  So I pretty much copied the design which uses an XC3S400-4 and
> a TMS320VC5510 with a combined SRAM/Flash chip.  I am being asked for a
> proper bus timing analysis and I need the data on the FPGA.  That is
> where the punches start flying!
> 
> The bus is asynchronous, but for whatever reason, the FPGA designers
> originally chose to use the CLKOUT from the DSP as the interface clock
> rather than the other clock being provided to the FPGA.  This may be
> because although the DSP memory interface is designed to work with
> async bus devices like RAMs and Flash, all the timing parameters are
> WRT the DSP CLKOUT.  However, the timings are such that you can't use
> CLKOUT to clock in the signals in a synchronous manner.  The signal
> transitions are on the rising clock edge +- a few ns.  The clock is
> about 10 ns period.  When it is matched to the FPGA IO timing I don't
> think you can meet the setup and hold times from what I have seen and I
> am told the design double clocks all inputs to remove metastability.
> 
> To do the timing analysis, I have asked the FPGA group to provide
> timing data on the FPGA.  I expected them to come back with the data
> they are using for timing constraints.  Instead they basically told me
> "you don't need no stinkin' timing data".  They seem to feel that
> because we are using lots of clock cycles on the bus cycle, the
> detailed timing is not important.  We have gone around a few times and
> I continue to assert that there are a few parameters that I need from
> the FPGA design such as the time from the RD_N signal rising to the
> data out going high-Z.  After half a dozen emails, I finally got an
> answer of 16 ns.  But I realized that I can't believe this since it was
> presented as a measurement from one iteration of the design.  I looked
> at the timing constraints and they don't have any other than the
> clocks!
> 
> Today in a meeting the FPGA supervisor told me that this timing
> parameter was from the Spartan data sheet since it is the time from a
> clock input through an IOB FF that controls the tristate buffer.  When
> I checked the data sheet I can't find such a timing parameter and the
> data I do find says the time in the IOB itself is less than 1 ns under
> the given conditions.
> 
> "Time from the active transition at the OTCLK input of the Three-state
> Flip-Flop (TFF) to when the Output pin enters the high-impedance state
> (LVCMOS25, 12mA output drive, Fast slew rate) All 0.28 0.74 0.85 ns"
> 
> Our interface is 3.3 volts and the worst case adjustment I can find is
> "LVTTL Slow 2 mA 2.76 7.27 8.36 ns".  So we still end up at well less
> than 10 ns without counting the clock delay.  They seem to be using the
> DCMs, but I can't say how they have them set up.  Even so, with the DCM
> the clock input to output pin (through an IOB FF) is under 2 ns and
> even without the DCM it is under 5 ns.  So giving the most leeway I
> possibly can I still come up with less than 15 ns for clock to output
> high-Z compared to 16 ns.
> 
> That leaves these possibilities...
> 1) I don't know what I am doing and the above rational is full of
> holes.
> 2) This supervisor is incompetent.
> 3) This supervisor is deliberately misleading us to cover someone
> else's incompetence.
> 4) ???
> 
> I am getting so tired of having to sift through the BS that the other
> departments are feeding me that I am close to quitting.  But before I
> do, I want to get to the bottom of this.  Have I completely
> misunderstood how the tristate outputs work somehow?  Is there a number
> in the data sheet that justifies the 16 ns number somewhere?
> 
> In reality I expect this signal path is going through logic inside the
> chip and is not being clocked in the IOB.  The 16 ns number most likely
> came from a measurement of one iteration of the chip.  I may take the
> time to dig into the design files at some point.  But first I would
> just like to get a sanity check on the idea that the 16 ns number came
> from the data sheet as a path from the clock input to an output going
> high-Z.  
> 
> So who is nuts, me or the other guy???  (or is it both?  ;^)

Article: 105562
Subject: Re: uClinux on Virtex-4 Mini-Module
From: "Antti" <Antti.Lukats@xilant.com>
Date: 25 Jul 2006 23:39:42 -0700
Links: << >>  << T >>  << A >>
Guru schrieb:

> Hi Folks,
>
> Does anybody has any experience with uClinux running on Virtex4FX12
> (ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to
> the OS if I have a normal Linux version drivers?
> I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module,
> because FLASH for standalone operation is only 4MB deep. This is not
> enough for any other OS with TCP/IP support (or a TCP/IP stack).
>
> Cheers,
>
> Guru

there is no uClinux for the PPC.
If you want to have PPC to be used you have to have Linux on it.

http://www.hydraxc.com

the -50 modules are shipped with PPC-linux reference design, the image
is actually smaller than microblaze-uclinux. And yes it includes
networking support. I think the ppc-linux image is 1.3MB so it would
easily fits into 4MB flash. Too bad that the friend of John Williams
did decide to remove the website with that PPC-linux distribution from
the internet, so that download is no longer
available.

Antti


Article: 105563
Subject: Re: EDK + Assembly Output Files + External Memory Usage
From: "Felix Pang" <xiaofei.pang@gmail.com>
Date: 26 Jul 2006 01:00:36 -0700
Links: << >>  << T >>  << A >>

MKULTRA2@gmail.com wrote:
> Hi Kida,
>
> not sure about the first one. For your second question, you can use XPS
> to customize the linker script: Software -> Generate Linker Script.
> Alternatively you can code it by hand. The linker script contains what
> memories all the software sections sit in. You must include your other
> memories as EDK-compliant peripherals in the system before they will
> appear in the GLS wizard drop-downs. I hope that can at least point you
> in the right direction.
> -scott
>
> vlsi_kida@math.net wrote:
> > Hi Gurus,
> >
> > I am new to EDK and embedded software
> > please help me...
> >
> > I am trying some example and test applications using EDK.
> > I have following Queries...
> >
> > 1. I have my application written in C, I want to view its assembly
> > output instead of .elf
> >     where I can set the option to get assembly output....?
> >
> > 2. presently all the applications are running through internal BRAM.
> >     If I want to map the application or part of application in external
> > sdram
> >      how do I do it...?
> >
> >
> > Thanks and Regards,
> > Kida
For the first one, you can either use mb-objdump/powerpc-eabi-objdump
command in Xilinx shell to dump the ELf to ASM, or use the GDB GUI to
see the ASM code.


Article: 105564
Subject: Re: EDK Using External Ports to toggle FPGA pins
From: "Felix Pang" <xiaofei.pang@gmail.com>
Date: 26 Jul 2006 01:14:56 -0700
Links: << >>  << T >>  << A >>

Kyle H. wrote:
> Hello All,
>
> I am having a hard time understanding EDK  ---> FPGA tool flow (I
> think).  I am using EDK/ISE 8.1, testing the Generic Reference Design
> from Memec/Avnet.  It is for the Xilinx FX12 mini-module.
>
> I have been able to use the drivers supplied to control the LCD screen,
> rs232 uart and the user LEDs as expected.  But when it comes to a
> specific FPGA pin of my choice I'm getting lost.
>
> I first started out with their example, and created my own spin off of
> theirs, trying to learn my way around the IDE of EDK.  All is working
> well except my understanding of the UCF file corresponding to the data
> inside EDK.  Ok, so in my xparameters.h file I see there are
> refferencing the memory locations for each component in the system
> assembly.  So in C I can assign these "registers" via the drivers and
> get expected results.  When it comes down to bit by bit I am lost.
>
> Is the UCF file that I'm using generated by EDK, or did someone from
> memec hand sculpt this?
> Maybe I have to import this into an ISE project to get the big picture?
>
> When I assign a gpio output 0x0550 I can see one 5 on my FPGA pins, but
> not in the order I would expect it.  Really it's not a five at all,
> unless I'm reading all the even pins.  And I thought the gpio output
> was 32 bit, so why in the UCF file is there only 10 pins assigned to
> the gpio output port(s)?
>
Since the PPC is big-endian, the output order of GPIO should be
inversed as you expected.

> I hope I am not being to vague/mis-guided, and even confusing you guys.
> Because I have certianly exhausted my confusion.  I've also read over a
> ton of documentation from XIlinx, about EDK, the drivers, etc...  I was
> searching for that golden document that would tell me exactly what I
> needed to know and I havn't found it yet.  Maybe I am not looking for
> the correct topics in the manuals?  Maybe I need to read over PowerPC
> user guide a bit more?
> Help point me in the wright direction!
> 
> Thanks,
> Kyle


Article: 105565
Subject: Re: <EDK> PORT .... not found in MPD
From: "Felix Pang" <xiaofei.pang@gmail.com>
Date: 26 Jul 2006 01:25:58 -0700
Links: << >>  << T >>  << A >>

Pasacco wrote:
> hi
>
> I have problem when opening "old" project file, system.xmp, using XPS
> 6.3.
>
> It seems that "HW_VER" is not set up for each IP for this particular
> version of EDK.
> How can we know what is correct (or latest) version of each IPs?
>
> thankyou
>

Check the \hw folder in EDK installation directory for all of the IP
released with EDK.
> -------------------------------------------------------------------------------------------------------------------------------
> PM_SPEC -- Xilinx path component is <C:/EDK>
> ERROR:MDT - ppc405 (ppc405_i) - C:\Xilinx\Work_July07\system.mhs:159 -
> PORT TIEC405DISOPERANDFWD not found in mpd.
> ERROR:MDT - ppc405 (ppc405_i) - C:\Xilinx\Work_July07\system.mhs:167 -
> PORT TIEC405MMUEN not found in mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:187 - PORT DBGC405DEBUGHALT not found
> in mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:188 - PORT JTGC405TRSTNEG not found in
> mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:189 - PORT JTGC405TCK not found in
> mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:190 - PORT JTGC405TDI not found in
> mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:191 - PORT JTGC405TMS not found in
> mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:192 - PORT C405JTGTDO not found in
> mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\r\system.mhs:193 - PORT C405JTGTDOEN not found in
> mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:194 - PORT RSTC405RESETSYS not found
> in mpd.
> ERROR:MDT - jtagppc_cntlr (jtag_cntl) -
> C:\Xilinx\Work_July07\system.mhs:196 - PORT HALTNEG not found in mpd.
> ERROR:MDT - ppc405 (ppc405_i2) - C:\Xilinx\Work_July07\system.mhs:306 -
> PORT TIEC405DISOPERANDFWD not found in mpd.
> ERROR:MDT - ppc405 (ppc405_i2) - C:\Xilinx\Work_July07\system.mhs:314 -
> PORT TIEC405MMUEN not found in mpd.


Article: 105566
Subject: Re: uClinux on Virtex-4 Mini-Module
From: "Guru" <ales.gorkic@email.si>
Date: 26 Jul 2006 02:28:39 -0700
Links: << >>  << T >>  << A >>
The only reference design for V4MM (from uCLinux website) uses MB (too
bad).
But the source files for uClinux include also the support for PPC, but
I don't know if it is a working version.

hydraXC-50 probably has the uClinux preloaded (although it is written
that all the designs inluce MB and uClinux), but see the price
(double!!).

I guess I have to contact John Williams on this matter.

Thanks,

Guru

Antti wrote:
> Guru schrieb:
>
> > Hi Folks,
> >
> > Does anybody has any experience with uClinux running on Virtex4FX12
> > (ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to
> > the OS if I have a normal Linux version drivers?
> > I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module,
> > because FLASH for standalone operation is only 4MB deep. This is not
> > enough for any other OS with TCP/IP support (or a TCP/IP stack).
> >
> > Cheers,
> >
> > Guru
>
> there is no uClinux for the PPC.
> If you want to have PPC to be used you have to have Linux on it.
>
> http://www.hydraxc.com
>
> the -50 modules are shipped with PPC-linux reference design, the image
> is actually smaller than microblaze-uclinux. And yes it includes
> networking support. I think the ppc-linux image is 1.3MB so it would
> easily fits into 4MB flash. Too bad that the friend of John Williams
> did decide to remove the website with that PPC-linux distribution from
> the internet, so that download is no longer
> available.
> 
> Antti


Article: 105567
Subject: Re: uClinux on Virtex-4 Mini-Module
From: "Guru" <ales.gorkic@email.si>
Date: 26 Jul 2006 03:11:39 -0700
Links: << >>  << T >>  << A >>
Antti,

I can see you are personally involved in development, that's why you
have good info on this matter.
The modules look VERY good (full of features), only the price bothers
me.
I cannot move to another platform right now, because my hardware is
designed for Mini-Module.
I guess I will have to implement the PPC-uClinux by myself :(

Cheers,

Guru


Antti wrote:
> Guru schrieb:
>
> > Hi Folks,
> >
> > Does anybody has any experience with uClinux running on Virtex4FX12
> > (ML403?) in PPC 405 processor. Can the LL_TEMAC drivers be connected to
> > the OS if I have a normal Linux version drivers?
> > I want to get it running on GSRD2 on Avnet Virtex-4 Mini-Module,
> > because FLASH for standalone operation is only 4MB deep. This is not
> > enough for any other OS with TCP/IP support (or a TCP/IP stack).
> >
> > Cheers,
> >
> > Guru
>
> there is no uClinux for the PPC.
> If you want to have PPC to be used you have to have Linux on it.
>
> http://www.hydraxc.com
>
> the -50 modules are shipped with PPC-linux reference design, the image
> is actually smaller than microblaze-uclinux. And yes it includes
> networking support. I think the ppc-linux image is 1.3MB so it would
> easily fits into 4MB flash. Too bad that the friend of John Williams
> did decide to remove the website with that PPC-linux distribution from
> the internet, so that download is no longer
> available.
> 
> Antti


Article: 105568
Subject: Re: Designing a matrix multpier block using existing xilinx toolbox
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 26 Jul 2006 11:25:18 +0100
Links: << >>  << T >>  << A >>
"sirisha.aluru@gmail.com" <sirisha.aluru@gmail.com> writes:

> hi everyone,
> for my class project i need to build a model in simulink , using xilinx
> system generator blocks..which computes matrix multiplication about
> 512X512 size...can anyone help me how to do it with black box.........i
> tried Mcode but didnt work...........
> thanks in advance
> 

I don't think using a black box will help you (unless you already have
some HDL code that does what you want, but it sounds like you don't).

You need to design the circuit to multiply 2 matrices.

Do you know how to multiply matrices on paper? If not, find that out
first!

If so, write down the steps you do in lots of detail.  This should
give you an idea for some counters and memory accesses. Prototype it
in Excel, or C, or Matlab or something high-leve until you understand
exactly how it's going to work.

Then putting the Sysgen blocks down and wiring them up should be very
straightforward.

HTH!
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   

Article: 105569
Subject: Re: uClinux on Virtex-4 Mini-Module
From: "Antti" <Antti.Lukats@xilant.com>
Date: 26 Jul 2006 03:41:52 -0700
Links: << >>  << T >>  << A >>
Guru schrieb:

> Antti,
>
> I can see you are personally involved in development, that's why you
> have good info on this matter.
> The modules look VERY good (full of features), only the price bothers
> me.
> I cannot move to another platform right now, because my hardware is
> designed for Mini-Module.
> I guess I will have to implement the PPC-uClinux by myself :(
>
> Cheers,
>
> Guru

read what I wrote - PPC-linux (not uClinux) image is 1.3MB only
so it would work on V4MM also.

all hydraXC-xx modules come with support DVD that includes VMWare
preconfigured environments so building a new MB-uclinux or PPC-linux
kernel for the hydraXC modules is only the matter of typing

make

:)

-- there is no PPC-uclinux ASFAIK and I see no reason on even working
on it.

Antti


Article: 105570
Subject: Re: Virtex4 Rocket I/O. Power filtering.
From: "Symon" <symon_brewer@hotmail.com>
Date: 26 Jul 2006 12:48:06 +0200
Links: << >>  << T >>  << A >>
"Mark McDougall" <markm@vl.com.au> wrote in message 
news:44c6b5a3$0$23525$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> Symon wrote:
>
>> From this, and if I don't use any receivers in the column, I deduce that 
>> I
>> can leave AVCCAUXRXA unfiltered. Right?
>
> From the paragraph immediately above the one you quoted, I'm assuming so
> in my design as well...
>
> Regards,
>
> -- 
> Mark McDougall, Engineer

Mark,
Yep, the more I read it, the more I'm convinced that's what they mean. A 
nice little diagram showing what's powered from what would be a nice 
addition to the user guide!
Cheers, Syms.



Article: 105571
Subject: Re: uClinux on Virtex-4 Mini-Module
From: Eli Hughes <emh203@psu.edu>
Date: Wed, 26 Jul 2006 08:43:35 -0400
Links: << >>  << T >>  << A >>
Wasn't the whole Idea of uClinux to have a port to chip without memory 
management?  If this is true, a uClinux would cripple the PowerPC. 
Might as well use the real thing.

-Eli

Antti wrote:
> Guru schrieb:
> 
> 
>>Antti,
>>
>>I can see you are personally involved in development, that's why you
>>have good info on this matter.
>>The modules look VERY good (full of features), only the price bothers
>>me.
>>I cannot move to another platform right now, because my hardware is
>>designed for Mini-Module.
>>I guess I will have to implement the PPC-uClinux by myself :(
>>
>>Cheers,
>>
>>Guru
> 
> 
> read what I wrote - PPC-linux (not uClinux) image is 1.3MB only
> so it would work on V4MM also.
> 
> all hydraXC-xx modules come with support DVD that includes VMWare
> preconfigured environments so building a new MB-uclinux or PPC-linux
> kernel for the hydraXC modules is only the matter of typing
> 
> make
> 
> :)
> 
> -- there is no PPC-uclinux ASFAIK and I see no reason on even working
> on it.
> 
> Antti
> 

Article: 105572
Subject: How to phase align a 10MHz clock using V4LX60 DCM
From: "subint" <subin.82@gmail.com>
Date: 26 Jul 2006 05:48:10 -0700
Links: << >>  << T >>  << A >>
Hello,
    I am now working with new board based on ARM processor which is
pluged on top of V4LX60 based board from avnet. But after the ARM board
is manufactured it is observed that the clock from the ARM is delayed
compared to the other signals. Since redesign of the board is not
possible i thought to advance the clock by 4ns using the DCM on the V4
board.
    But the problem is the clock signal is only 10MHz frequency. Thus
it is outside the  frequency range (input clock) of the DCM if i am
using the CLK0 output. Thus it is possible to use only the CLKFX
output. But the minimum output frequency is 32MHz. Thus i thought to
use two DCMs. One to multiply the input clock with 10 and will do a
phase shift of 4ns. Then this will be divided by another DCM which will
divide by 10 to get a phase advanced 10MHz frequency.
    But the problem observed is that the input 10MHz and the multiplied
100Mhz are phase aligned also the input to second DCM and the output
10MHz are also aligned. The First input and the output of the second
DCM is not showing any relation ship.
     How can i tackle this problem


Article: 105573
Subject: Re: How to phase align a 10MHz clock using V4LX60 DCM
From: "Gabor" <gabor@alacron.com>
Date: 26 Jul 2006 06:04:57 -0700
Links: << >>  << T >>  << A >>
When you multiply a clock and then divide it, there is no common
phase relationship of the output unless you reference the original
signal.  I would suggest sampling the input clock using a flip-flop
clocked by the 10x clock.  The output of this flip-flop should have
a constant (somewhat delayed) phase relationship to the original.
Additional 10x clock delays can then be added to adjust the clock
to the desired phase.

subint wrote:
> Hello,
>     I am now working with new board based on ARM processor which is
> pluged on top of V4LX60 based board from avnet. But after the ARM board
> is manufactured it is observed that the clock from the ARM is delayed
> compared to the other signals. Since redesign of the board is not
> possible i thought to advance the clock by 4ns using the DCM on the V4
> board.
>     But the problem is the clock signal is only 10MHz frequency. Thus
> it is outside the  frequency range (input clock) of the DCM if i am
> using the CLK0 output. Thus it is possible to use only the CLKFX
> output. But the minimum output frequency is 32MHz. Thus i thought to
> use two DCMs. One to multiply the input clock with 10 and will do a
> phase shift of 4ns. Then this will be divided by another DCM which will
> divide by 10 to get a phase advanced 10MHz frequency.
>     But the problem observed is that the input 10MHz and the multiplied
> 100Mhz are phase aligned also the input to second DCM and the output
> 10MHz are also aligned. The First input and the output of the second
> DCM is not showing any relation ship.
>      How can i tackle this problem


Article: 105574
Subject: Re: Which PCI core for Cyclone II board?
From: "Brian McFarland" <brian.mcf1985@gmail.com>
Date: 26 Jul 2006 06:27:04 -0700
Links: << >>  << T >>  << A >>
Well I gave up on trying to find free ( and legal :-/ ) info about PCI
online and ordered the mindshare PCI book.  It hasn't arrived yet, but
I began just writing my own PCI module.  I was kinda hoping to be able
to do this project w/o getting too deep into the specs of PCI, but I
don't think that's going to happen.


Mark McDougall wrote:
> Brian McFarland wrote:
>
> > -- although i'm not sure how much processing it will take because our
> > customers are writing the software that does it and I have no direct
> > way to contanct their developers.
>
> In that case my response would be that I don't have sufficient detail in
> the requirements to propose a solution.
>
> Regards,
>
> --
> Mark McDougall, Engineer
> Virtual Logic Pty Ltd, <http://www.vl.com.au>
> 21-25 King St, Rockdale, 2216
> Ph: +612-9599-3255 Fax: +612-9599-3266




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search