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 147375

Article: 147375
Subject: Re: voltage divider calcs
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 24 Apr 2010 10:35:00 -0700
Links: << >>  << T >>  << A >>
On Sat, 24 Apr 2010 12:12:01 -0500, "krw@att.bizzzzzzzzzzzz"
<krw@att.bizzzzzzzzzzzz> wrote:

>On Sat, 24 Apr 2010 09:43:00 -0700, John Larkin
><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>
>>On Sat, 24 Apr 2010 15:12:19 GMT, Jan Panteltje
>><pNaonStpealmtje@yahoo.com> wrote:
>>
>>>On a sunny day (Sat, 24 Apr 2010 05:23:16 +0200) it happened Sjouke Burry
>>><burrynulnulfour@ppllaanneett.nnll> wrote in
>>><4bd26424$0$14132$703f8584@textnews.kpn.nl>:am still using WIN3.11 for workgroups, have not needed any
>>>>bugs fixed by M$.
>>>>You dont need a new or refurbished OS or computer every 2 years.
>>>
>>>Exactly
>>>Still running a 10 year old Duron 950 Mhz as server, and Linux of course.
>>>All backuped 2 x.
>>>When all applications run, there is no reason in the world to upgrade OS.
>>>
>>>To be honest, nothing really new, a killer application one *must* have,
>>>has happend in the last 10 years....
>>
>>Google Earth.
>
>FPGA tools that actually work.

Xilinx is driving us crazy. Their support guys are under pressure to
close cases, so they do the logical thing, which is close cases.
Fixing things is apparently not a requirement.

The logic is, apparently, if they stall long enough, eventually a new
release will be on the horizon, so they say "install the new release"
and, well, close the case.

Downloading and installing a release, or a service pack, takes days.
Occasionally it fixes things, probably by accident.

We're having some success with the Spartan 6, as long as you use the
tools in make-file mode (the GUI is a mess) and don't do anything too
ambitious, like use the DRAM controller.

My guys are seriously pushing me to go to Lattice or Altera. The
silicon may not be as advanced, but the tools may be better. Dumping
NuHorizons certainly didn't help.

John


Article: 147376
Subject: Re: voltage divider calcs
From: "krw@att.bizzzzzzzzzzzz" <krw@att.bizzzzzzzzzzzz>
Date: Sat, 24 Apr 2010 13:16:44 -0500
Links: << >>  << T >>  << A >>
On Sat, 24 Apr 2010 10:35:00 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

>On Sat, 24 Apr 2010 12:12:01 -0500, "krw@att.bizzzzzzzzzzzz"
><krw@att.bizzzzzzzzzzzz> wrote:
>
>>On Sat, 24 Apr 2010 09:43:00 -0700, John Larkin
>><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>>
>>>On Sat, 24 Apr 2010 15:12:19 GMT, Jan Panteltje
>>><pNaonStpealmtje@yahoo.com> wrote:
>>>
>>>>On a sunny day (Sat, 24 Apr 2010 05:23:16 +0200) it happened Sjouke Burry
>>>><burrynulnulfour@ppllaanneett.nnll> wrote in
>>>><4bd26424$0$14132$703f8584@textnews.kpn.nl>:am still using WIN3.11 for workgroups, have not needed any
>>>>>bugs fixed by M$.
>>>>>You dont need a new or refurbished OS or computer every 2 years.
>>>>
>>>>Exactly
>>>>Still running a 10 year old Duron 950 Mhz as server, and Linux of course.
>>>>All backuped 2 x.
>>>>When all applications run, there is no reason in the world to upgrade OS.
>>>>
>>>>To be honest, nothing really new, a killer application one *must* have,
>>>>has happend in the last 10 years....
>>>
>>>Google Earth.
>>
>>FPGA tools that actually work.
>
>Xilinx is driving us crazy. Their support guys are under pressure to
>close cases, so they do the logical thing, which is close cases.
>Fixing things is apparently not a requirement.
>
>The logic is, apparently, if they stall long enough, eventually a new
>release will be on the horizon, so they say "install the new release"
>and, well, close the case.

Ah, the Microsoft model.

>Downloading and installing a release, or a service pack, takes days.
>Occasionally it fixes things, probably by accident.

Yes, and even if it doesn't fix the problem, a new case is opened.  That does
fix the problem (in their measurements system).

>We're having some success with the Spartan 6, as long as you use the
>tools in make-file mode (the GUI is a mess) and don't do anything too
>ambitious, like use the DRAM controller.

Thanks.  I guess I'll cross Spartan 6 off the list, at least for now. 

>My guys are seriously pushing me to go to Lattice or Altera. The
>silicon may not be as advanced, but the tools may be better. 

I'm having no problems with Altera's software, so far.  I haven't pushed a
design out for real but I have gone through the process.  From my perspective
I don't see much difference between Altera and Xilinx Spartan 4.  I don't need
the speed of either, though.  

I've pushed the design though the Actel tools, too.  No issues with the
software but the hardware only has three-input LUTs which increases the count
by at least 50% which blew out my estimates (and the package).  That was one
of the things that I liked about Spartan 6 - six-input LUTs. 

I haven't seriously (far enough to run a design) looked at Lattice because
their packages aren't good for the application.

>Dumping NuHorizons certainly didn't help.

I've had really good support from Arrow (Altera and Lattice).  The FAE came
and installed the software on my system and gave me a half day tutorial on it.
They're even willing to help with the design.  The sales guy is hungry.  ;-)

Article: 147377
Subject: Re: voltage divider calcs
From: -jg <jim.granville@gmail.com>
Date: Sat, 24 Apr 2010 16:26:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 5:35=A0am, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sat, 24 Apr 2010 12:12:01 -0500,
> My guys are seriously pushing me to go to Lattice or Altera. The
> silicon may not be as advanced, but the tools may be better. Dumping
> NuHorizons certainly didn't help.

So this thread is called "voltage divider calcs" as a cloak then ;)

If you do not NEED the advanced silicon, why choose it ?
It's nicknamed the bleeding edge for a reason..

-jg


Article: 147378
Subject: Re: voltage divider calcs
From: "Joel Koltner" <zapwireDASHgroups@yahoo.com>
Date: Sat, 24 Apr 2010 17:28:51 -0700
Links: << >>  << T >>  << A >>
"-jg" <jim.granville@gmail.com> wrote in message 
news:804078af-510e-4fcb-9cc2-5007cc7c8e70@s15g2000prg.googlegroups.com...
>If you do not NEED the advanced silicon, why choose it ?

Because manufacturers have a tendency to start cranking up the price of the 
older lines within a couple of years of coming out with the new lines?

Some manufacturers are far better than others in this respect, though.

Spartan isn't the bleeding edge line anyway -- Virtex is.

We were buying some old Actel FPGAs for >$50 for awhile since we kept 
thinking -- "oh, it's just one more order so we'll only need 10 more FPGAs, 
$500 wouldn't pay for the engineering time to switch to a newer/different 
park" ...several times over :-(, even though the newer replacement parts would 
have been <$5.


Article: 147379
Subject: Helping tools
From: "truhlik_fredy" <anton.krug@n_o_s_p_a_m.gmail.com>
Date: Sat, 24 Apr 2010 20:46:33 -0500
Links: << >>  << T >>  << A >>
Hi
Perhaps this is just newbie question, but I'm looking for tool helping me
with bits. The point is that I can't find it and I don't know if there is
something out there or the usage is so trivial for everybody used to
hardware design thinking so nobody bothered to create something like that.

If there is nothing then perhaps I will make one because I have sometimes
troubles to imagine it and I cought myself many times just putting
estimated number & synthesizing + praying it was right (time consuming +
very stupid method) or I just write on paper to understand and in no time I
run out of notebooks :)

But I found couple of little tools like DCM calculator to calculate divider
and multiplier factors to get desired frequency. Or Linear feedback shift
register tool etc....

But this one should be to better imagine bits (I don't know how better
describe that). For example I want counter capable counting to 6000dec and
I don't know how big register I should create, OK it's 2 powers 13 so the
register is

reg [12:0]counter;

But later I want to be able to take value of counter, divide it by 4 (so
shift >> 2) and use it somewhere with maximum number of 256. So i will take
the counter from bit 2 and should be 8 bit long, so 2+8=10, but sometimes i
forget that it's counted from zero so I forget to decrement 1 from the 10,
and then the final maximal number is 512, and when the destination is wide
enough it won't overflow and I end up with wrong design instead  of:

wire [16:0] new_counter = counter[9:2];

For example I'm doing PAL signal generator with text mode etc... because I
was experimenting with Color PAL generation I ended up with much higher
x_counter then normally desired. And when calculating the adders for font
8x8 ROM i needed something to generate address. The ROM has 256 characters
with 8x8 bitmap (so 8bits per line = 1 byte per line => 8 bytes of data per
character) so the size is 2048 and it's 11 bits wide; 

wire [10:0] adr;

and I have to take first 3bit of y_counter to change the lines in the font
character, soo...

y_counter[2:0]

The I need something witch will show 32 chars (so 5bit) one by one on X
axis but divided strongly because my X is running to fast

x_count[8:4] adn this should go to rom addres from bit 4 to bit 8 [7:3]

And then after line of text another set of 32 character should by show so
again y_count but divided by 8 because I want to leave enough space to
finish character before (so starting from bit 4 => from zero it's 3) and
should be showing 8 lines so 3bit, 3bit+ starting from 3 =6bit but from
zero it's 5, so i will use

y_counter[5:3]

and put everything together 

adr={y_counter[5:3],x_count[8:4],y_counter[2:0]};

But I hooping to find utility to help me with this simple calculations,
it's just adding, subtracting, decreasing by 1 etc... but it's lot of it
and when I'm in 64bit large number I got easily lost and I would like to
have something to help me visualize that.

If nobody knows any tools like this, then perhaps I will do one, because
without it I'm making lot mistakes and wasting lot of time.

Thanks to everybody who could help me with that.





	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147380
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sat, 24 Apr 2010 21:03:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 23, 7:39=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Apr 22, 3:45=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>
>
>
>
>
> > On Apr 22, 1:55=A0pm, Eric <eric.lafor...@gmail.com> wrote:
>
> > > On Apr 22, 12:36=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > > I guess I don't understand what you are accomplishing with this.
> > > > Block rams in FPGAs are almost always multiported. =A0Maybe not N w=
ay
> > > > ported, but you assume they are single ported when they are dual
> > > > ported.
>
> > > But what if you want more ports, say 2-write/4-read, without wait
> > > states?
> > > I assume them to be "simply dual-ported", which means one write port
> > > and one read port, both operating concurrently. It is also possible t=
o
> > > run them in "true dual port" mode, where each port can either read or
> > > write in a cycle. Some of the designs in the paper do that.
>
> > > > Can you give a general overview of what you are doing without using
> > > > jargon? =A0I took a look and didn't get it at first glance.
>
> > > OK. Let me try:
>
> > > Assume a big, apparently multiported memory of some given capacity an=
d
> > > number of ports. Inside it, I use a small multiported memory
> > > implemented using only the fabric of an FPGA, which stores only the
> > > number of the write port which wrote last to a given address. Thus
> > > this small memory is of the same depth as the whole memory, but much
> > > narrower, hence it scales better.
>
> > > When you read at a given address from the big memory, internally you
> > > use that address to look up which write port wrote there last, and us=
e
> > > that information to steer the read to the correct internal memory ban=
k
> > > which will hold the data you want. These banks are built-up of
> > > multiple Block RAMs so as to have one write port each, and as many
> > > read ports as the big memory appears to have.
>
> > > The net result is a memory which appears to have multiple read and
> > > write ports which can all work simultaneously, but which leaves the
> > > bulk of the storage to Block RAMs instead of the FPGA fabric, which
> > > makes for better speed and smaller area.
>
> > > Does that help?
>
> > > Eric
>
> > I appreciate the elaboration here in the newsgroup.
>
> > The "true dual port" nature of the BlockRAMs allows one independent
> > address on each of the two ports with a separate write enable for each
> > port. =A0The behavior of the BlockRAM can be modified to provide read
> > data based on the new write data, old data, or no change in the read
> > data value from last cycle (particularly helpful for multi-pumping).
>
> > For an M write, N read memory, your approach appears to need M x (N+1)
> > memories since you can have M writes all happening at the same time N
> > accesses are made to the same "most recently written" memory. =A0Please
> > correct me if I'm wrong. =A0This is the same number of memories require=
d
> > with the XOR approach but without the LVT overhead. =A0The time delay i=
n
> > reading the LVT and multiplexing the memories feels like it would be
> > cumbersome. =A0While this might not add "wait states" it appears the
> > system would not be able to run terribly quickly. =A0XORs are pretty
> > quick.
>
> > There are always more ways to approach a problem that any one group
> > can come up with. =A0Kudos on your effort to bring a better approach to
> > a tough system level issue for difficult designs.
>
> John_H,
> What is the XOR method in this regard? Can you give an explanation? or
> give a hint on the source?
>
> Weng

Eric,
Here is my answer to your paper.

1. It is an excellent paper. If let me give a 0-100 mark, I would give
90.

2. It really has inventive idea: it solidly resolves a problem: with a
current FPGA chip available, how to generate
a block RAM with required number of multiple read/write ports using
available block RAM which have limited
and fixed number of write/read ports. In this regard, your method is
the best !!! I will use it if I need to.

3. The references are good, but it lacks the most important things:
patents in this regard filed by Altera and Xilinx.
They must have their technique patented. No matter what, big or small,
both companies would patent everything they think it is important to
them.

4. If you want to expand your inventive idea to new block RAM with
multiple write/read ports made in FPGA, it is not a good idea:
Essentially there is no difficulty to build a block RAM with multiple
write/read ports. If you add 4 sets of read decoder
and 4 sets of write decoder to a current block RAM, the block RAM
immediately would have 4 write/read ports.There is no data racing in
the design at all.
The problem is if there is big need in the market for FPGA
manufactures to do so.

5. Your final conclusion about write-and-read schedule is not right.
When people is using your method, they are still facing write-and-read
scheduling.
For example, there is a wait list pool to receive write and read
requests, and the pool can hold 200 write requests and 200 read
requests.
How to deliver the proper write and read request to your block RAM
ports has the write-and-read scheduling problem.
So your method doesn't eliminate the write-and-read scheduling
problem. And you can only say that your solution
doesn't generate new write-and-read scheduling problem and there is a
new write/read rule: if a write and a read with
same address are issued in the same clock cycle, the read would return
the data which is to be overwritten
by the write request issued in the same clock cycle.


Here is an answer to John_H and Rick:
> > For an M write, N read memory, your approach appears to need M x (N+1)
> > memories since you can have M writes all happening at the same time N
> > accesses are made to the same "most recently written" memory. =A0Please
> > correct me if I'm wrong.

John_H is wrong. It needs M block RAM with another column used by
LVT.
The LVT column needs M write ports and N read ports and its data width
is Upper_bound( log M ).
Each write port writes its data into its block RAM and at the same
time writes its column number to LVT column
so that LVT column stores the latest write column number for the
latest write address.

When being read, read port first reads the LVT column to get the
column number which stores the latest write data with the read
address,
then read the latest write column ( block RAM ) into its read output
register.

It is really a clever idea !!!

Weng




Article: 147381
Subject: Re: Helping tools
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sat, 24 Apr 2010 21:06:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 24, 8:46=A0pm, "truhlik_fredy" <anton.krug@n_o_s_p_a_m.gmail.com>
wrote:

> But I hooping to find utility to help me with this simple calculations,
> it's just adding, subtracting, decreasing by 1 etc... but it's lot of it
> and when I'm in 64bit large number I got easily lost and I would like to
> have something to help me visualize that.
>
> If nobody knows any tools like this, then perhaps I will do one, because
> without it I'm making lot mistakes and wasting lot of time.

Well, with something like Python, you can easily write little scripts
to keep track of this sort of thing.  For example, at the Python
prompt, you can type:

>>> from math import log
>>> def bits_required(maxval, minval=3D0):
...     return int(log(maxval - minval)/log(2)) + 1
...
>>> bits_required(8191)
13
>>> bits_required(8192)
14
>>>

Regards,
Pat

Article: 147382
Subject: Re: Helping tools
From: "truhlik_fredy" <anton.krug@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Sun, 25 Apr 2010 02:33:57 -0500
Links: << >>  << T >>  << A >>
>Well, with something like Python, you can easily write little scripts
>to keep track of this sort of thing.  For example, at the Python
>prompt, you can type:
>
>>>> from math import log
>>>> def bits_required(maxval, minval=3D0):
>...     return int(log(maxval - minval)/log(2)) + 1
>...
>>>> bits_required(8191)
>13
>>>> bits_required(8192)
>14
>>>>
>


That is almost exactly what I'm intending to do, just not in python. I
would like to make it interactive web page in php to make some
visualizations.

Bit required is just 1 thing. For example, do you know how big (I mean in
bits) it's just by looking on this?

{y_counter[5:3],x_count[8:4],y_counter[2:0]}

And when you are merging more signals into 1 bus to see things like, what
value the x_count[8:4] represents 512..32 (and in hex too), how many bits
it is, how many times it's divided what it could represent when inserted
into signal from LSB 0 so

    MSB     LSB
bits 4 3 2 1 0   (if it's writen from 0)
bits 8 7 6 5 4   (original)

so from bit 0 it would represent 32 .. 0 

and what it represents when it's inserted to

{y_counter[5:3],x_count[8:4],y_counter[2:0]}

256..16

What is needed if i want include 300, it's needs to be up to 512, so it's
need to expand from 5bits to 6bits

{y_counter[5:3],x_count[9:4],y_counter[2:0]}

Now but the destination expandet to 11 bits and I want 10bits
so i can change y_counter[5:3] to y_counter[4:3] who is now representing
3..0

So I'm looking for something what has everything together and every change
interacting with rest, because then I will just forget to check something
and designe bigger bus etc....

So anybody any change to find something like this, or I just should start
with mine?	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 147383
Subject: Re: voltage divider calcs
From: luudee <rudolf.usselmann@gmail.com>
Date: Sun, 25 Apr 2010 00:37:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 12:35=A0am, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>
> Xilinx is driving us crazy. Their support guys are under pressure to
> close cases, so they do the logical thing, which is close cases.
> Fixing things is apparently not a requirement.
>
> The logic is, apparently, if they stall long enough, eventually a new
> release will be on the horizon, so they say "install the new release"
> and, well, close the case.
>
> Downloading and installing a release, or a service pack, takes days.
> Occasionally it fixes things, probably by accident.
>
> We're having some success with the Spartan 6, as long as you use the
> tools in make-file mode (the GUI is a mess) and don't do anything too
> ambitious, like use the DRAM controller.
>

John,

perhaps if you would describe the issues you are having you could
get a solution from the group.
We have been using Spartan 6 with DDR without any problems. Try
starting with the code the BSB generates for the SP605. When new
devices are released the initial support is always buggy ....

> My guys are seriously pushing me to go to Lattice or Altera. The
> silicon may not be as advanced, but the tools may be better. Dumping
> NuHorizons certainly didn't help.

Yeah, I agree about NuHorizons.  Now Avnet can abuse the crap out
of us without any consequences. My FMC boards are still on a 8 week
backorder, even though xilinx has them in stock ...

> John

Good Luck,
rudi


Article: 147384
Subject: Craignell2-48 - 48 Pin FPGA DIL Module
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 25 Apr 2010 05:00:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
To complete a busy week of new boards a picture of our new 48 pin FPGA
DIL module - Craignell2-48 is now on http://www.enterpoint.co.uk/component_replacements/craignell2.html.

We have these with us to show at ESC in San Jose this week.for anyone
going to that event and wants to see and hold them.

John Adair
Enterpoint Ltd.

Article: 147385
Subject: Re: Helping tools
From: Patrick Maupin <pmaupin@gmail.com>
Date: Sun, 25 Apr 2010 09:13:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 2:33=A0am, "truhlik_fredy"
<anton.krug@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:

> Bit required is just 1 thing. For example, do you know how big (I mean in
> bits) it's just by looking on this?
>
> {y_counter[5:3],x_count[8:4],y_counter[2:0]}

Yes, 3 + 5 + 3 =3D 11.  But, I will concede that, if the bus size gets
bigger, it could be harder to figure out.

> And when you are merging more signals into 1 bus to see things like, what
> value the x_count[8:4] represents 512..32 (and in hex too), how many bits

>>> [1 << x for x in range(4, 8+1)]
[16, 32, 64, 128, 256]

>>> range(0, 1<<(8+1), 1<<4)
[0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224,
240, 256, 272, 288, 304, 320, 336, 352, 368, 384, 400, 416, 432, 448,
464, 480, 496]

>>> ' '.join(hex(x) for x in range(0, 1<<(8+1), 1<<4))
'0x0 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0
0xe0 0xf0 0x100 0x110 0x120 0x130 0x140 0x150 0x160 0x170 0x180 0x190
0x1a0 0x1b0 0x1c0 0x1d0 0x1e0 0x1f0'

(stuff snipped)

> Now but the destination expandet to 11 bits and I want 10bits
> so i can change y_counter[5:3] to y_counter[4:3] who is now representing
> 3..0
>
> So I'm looking for something what has everything together and every chang=
e
> interacting with rest, because then I will just forget to check something
> and designe bigger bus etc....
>
> So anybody any change to find something like this, or I just should start
> with mine? =A0 =A0 =A0 =A0

I don't personally know of anything that does that, but seriously, I'd
just write a Python script with a few constants.  You can have it do
all sorts of checking, and even write code for you if you want.  (But
I'm not a GUI person.)

Regards,
Pat

Article: 147386
Subject: Re: Craignell2-48 - 48 Pin FPGA DIL Module
From: whygee <yg@yg.yg>
Date: Sun, 25 Apr 2010 20:10:19 +0200
Links: << >>  << T >>  << A >>
John Adair wrote:
> To complete a busy week of new boards a picture of our new 48 pin FPGA
> DIL module - Craignell2-48 is now on http://www.enterpoint.co.uk/component_replacements/craignell2.html.

Congrats, that's a really nice board !

> We have these with us to show at ESC in San Jose this week.for anyone
> going to that event and wants to see and hold them.

Any free samples ?

OK, seriously, I have a real question :
how do you find and choose the names of your products ?
like, you gather your team and take each syllabe from
their names, and see what combination sounds best ?

I'm just curious :-)

> John Adair
> Enterpoint Ltd.
yg

-- 
http://ygdes.com / http://yasep.org

Article: 147387
Subject: Re: Craignell2-48 - 48 Pin FPGA DIL Module
From: Muzaffer Kal <kal@dspia.com>
Date: Sun, 25 Apr 2010 12:43:06 -0700
Links: << >>  << T >>  << A >>
On Sun, 25 Apr 2010 20:10:19 +0200, whygee <yg@yg.yg> wrote:
>OK, seriously, I have a real question :
>how do you find and choose the names of your products ?
>like, you gather your team and take each syllabe from
>their names, and see what combination sounds best ?

It seems that most (all?) Enterpoint products are named after Scotish
landmarks.
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 147388
Subject: Spartan 6 FPGA decoupling cap pattern diagram
From: Aditi <aditi.groups@gmail.com>
Date: Sun, 25 Apr 2010 13:46:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am using SPARTAN 6 LX9 device in my new design and would like to get
decoupling capacitor placement diagram ASAP. I have looked at the User
guide for LX16 development board (from AVNET) to find one. It only has
the top view of the board. If some body could guide/help me in getting
the bottom view of the board, that would be really helpful. I have to
send my design to layout and it is kind of urgent.

Thank you,
Regards,
Aditi.

Article: 147389
Subject: Re: Craignell2-48 - 48 Pin FPGA DIL Module
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Mon, 26 Apr 2010 00:14:44 +0100
Links: << >>  << T >>  << A >>
On Sun, 25 Apr 2010 12:43:06 -0700, Muzaffer Kal <kal@dspia.com> wrote:

>On Sun, 25 Apr 2010 20:10:19 +0200, whygee <yg@yg.yg> wrote:
>>OK, seriously, I have a real question :
>>how do you find and choose the names of your products ?
>>like, you gather your team and take each syllabe from
>>their names, and see what combination sounds best ?
>
>It seems that most (all?) Enterpoint products are named after Scotish
>landmarks.

As a Scot, I can assure you that there are also Welsh and Irish
landmarks in the product range, though I'm not seeing many English
landmarks, say from the Malvern hills or thereabouts. Perhaps we'll see
a Bredon one of these days, or even a Wyre Piddle. Or perhaps not...

- Brian

Article: 147390
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: John_H <newsgroup@johnhandwork.com>
Date: Sun, 25 Apr 2010 19:57:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 12:03=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> Each write port writes its data into its block RAM and at the same
> time writes its column number to LVT column
> so that LVT column stores the latest write column number for the
> latest write address.
>
> When being read, read port first reads the LVT column to get the
> column number which stores the latest write data with the read
> address,
> then read the latest write column ( block RAM ) into its read output
> register.
>

So what happens when the multiple reads all want to read from the same
memory because that happens to be where all the last values were
written for that read?

As to the XOR, I don't have code to share; I developed it a while ago
for some asynchronous stuff and it applies well to multi-port writes.

As I try to put together a clearer explanation, I find I may have been
wrong about the memory count for the XOR approach such that the LVT
would use fewer.  I still believe the LVT approach requires M*N
BlockRAMs for an M-write, N-read multi-port memory plus the LVT; I'm
having trouble remembering why I thought the "+1" was needed.  The XOR
approach appears to need M*(M-1+N) memories.

If you have 3 write ports and 4 read ports, you'll need 3 sets of *6*
memories.  The 6 memories in the "write bank" set all have the same
write address and write data corresponding to that write port.  When a
write occurs, the *read* value for that write address is accessed from
the other two write banks so each set of 6 must provide a read address
for the other two write bank addresses.  The four reads have their own
memories for their own addresses in each of the write banks.

When the write occurs, the read values for that write address are
retrieved from the other write banks and the XOR of those values along
with the new write data are written to all the write ports for its
bank of 6 memories.  When a read is performed, the read value within
each write bank is retrieved and the values (3 in this case) are XORed
to get the original data.

newDataWr0^oldDataWr1^oldDataWr2 overwrites oldDataWr0 for the write.

The later reads retrieve oldDataWr0, oldDataWr1, and oldDataWr2 but
 since oldDataWr0 was updated to newDataWr0^oldDataWr1^oldDataWr2,
 the XOR of the three read values are
oldDataWr0^oldDataWr1^oldDataWr2 =3D=3D
 (newDataWr0^oldDataWr1^oldDataWr2)^oldDataWr1^oldDataWr2 =3D=3D
 newDataWr0^(oldDataWr1^oldDataWr1)^(oldDataWr2^oldDataWr2) =3D=3D
 newDataWr0^(0)^(0) =3D=3D
 newDataWr0

So with a little coordination, the XOR approach requires M*(M-1+N)
BlockRAMs for an M write, N read port memory along with the XORs.

The LVT needs a memory for each write port but requires multiples of
them to accommodate every read port in case the multiple reads for any
one cycle are all from the same write bank for the most recently
updated value.

Depending on the complexity of the LVT, the number of write ports, and
the allowable latencies, the LVT could be a more effective approach.

Article: 147391
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Sun, 25 Apr 2010 21:04:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 25, 7:57=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
> On Apr 25, 12:03=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > Each write port writes its data into its block RAM and at the same
> > time writes its column number to LVT column
> > so that LVT column stores the latest write column number for the
> > latest write address.
>
> > When being read, read port first reads the LVT column to get the
> > column number which stores the latest write data with the read
> > address,
> > then read the latest write column ( block RAM ) into its read output
> > register.
>
> So what happens when the multiple reads all want to read from the same
> memory because that happens to be where all the last values were
> written for that read?
>
> As to the XOR, I don't have code to share; I developed it a while ago
> for some asynchronous stuff and it applies well to multi-port writes.
>
> As I try to put together a clearer explanation, I find I may have been
> wrong about the memory count for the XOR approach such that the LVT
> would use fewer. =A0I still believe the LVT approach requires M*N
> BlockRAMs for an M-write, N-read multi-port memory plus the LVT; I'm
> having trouble remembering why I thought the "+1" was needed. =A0The XOR
> approach appears to need M*(M-1+N) memories.
>
> If you have 3 write ports and 4 read ports, you'll need 3 sets of *6*
> memories. =A0The 6 memories in the "write bank" set all have the same
> write address and write data corresponding to that write port. =A0When a
> write occurs, the *read* value for that write address is accessed from
> the other two write banks so each set of 6 must provide a read address
> for the other two write bank addresses. =A0The four reads have their own
> memories for their own addresses in each of the write banks.
>
> When the write occurs, the read values for that write address are
> retrieved from the other write banks and the XOR of those values along
> with the new write data are written to all the write ports for its
> bank of 6 memories. =A0When a read is performed, the read value within
> each write bank is retrieved and the values (3 in this case) are XORed
> to get the original data.
>
> newDataWr0^oldDataWr1^oldDataWr2 overwrites oldDataWr0 for the write.
>
> The later reads retrieve oldDataWr0, oldDataWr1, and oldDataWr2 but
> =A0since oldDataWr0 was updated to newDataWr0^oldDataWr1^oldDataWr2,
> =A0the XOR of the three read values are
> oldDataWr0^oldDataWr1^oldDataWr2 =3D=3D
> =A0(newDataWr0^oldDataWr1^oldDataWr2)^oldDataWr1^oldDataWr2 =3D=3D
> =A0newDataWr0^(oldDataWr1^oldDataWr1)^(oldDataWr2^oldDataWr2) =3D=3D
> =A0newDataWr0^(0)^(0) =3D=3D
> =A0newDataWr0
>
> So with a little coordination, the XOR approach requires M*(M-1+N)
> BlockRAMs for an M write, N read port memory along with the XORs.
>
> The LVT needs a memory for each write port but requires multiples of
> them to accommodate every read port in case the multiple reads for any
> one cycle are all from the same write bank for the most recently
> updated value.
>
> Depending on the complexity of the LVT, the number of write ports, and
> the allowable latencies, the LVT could be a more effective approach.

"The LVT needs a memory for each write port but requires multiples of
them to accommodate every read port in case the multiple reads for
any
one cycle are all from the same write bank for the most recently
updated value. "

I don't see any problem reading any of 9 block RAM into one read
register by a selection data or to any number of read registers by a
selection data.

Your XOR method is inferior to the LVT method absolutely, even though
I have no full knowledge of your XOR method.

The LVT method is very clean, very fast and easy to implement and so
flexible that
even 2 block RAM with each having independent 2 write ports and 2 read
ports can be easily
expanded into 4 write ports and 4 read ports.

Weng

Article: 147392
Subject: Re: Craignell2-48 - 48 Pin FPGA DIL Module
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 25 Apr 2010 21:36:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
The early board range names are actually our local Malvern Hills -
Broaddown, Raggedstone, Hollybush. We did miss some of these as being
inappropriate, boring, or even indistinct, e.g. Hangmans Hill. The
later product familiy names are from the Galloway Hills in Scotland
where there are more names of distinction. The later names also have a
size link. It's not a totally accurate naming system but we give
brownie points to anyone can pronounce them properly. Maybe I will
keep score this week in San Jose and see what percentage get them
right or nearly so.

John Adair
Enterpoint Ltd.

On 26 Apr, 00:14, Brian Drummond <brian_drumm...@btconnect.com> wrote:
> On Sun, 25 Apr 2010 12:43:06 -0700, Muzaffer Kal <k...@dspia.com> wrote:
> >On Sun, 25 Apr 2010 20:10:19 +0200, whygee <y...@yg.yg> wrote:
> >>OK, seriously, I have a real question :
> >>how do you find and choose the names of your products ?
> >>like, you gather your team and take each syllabe from
> >>their names, and see what combination sounds best ?
>
> >It seems that most (all?) Enterpoint products are named after Scotish
> >landmarks.
>
> As a Scot, I can assure you that there are also Welsh and Irish
> landmarks in the product range, though I'm not seeing many English
> landmarks, say from the Malvern hills or thereabouts. Perhaps we'll see
> a Bredon one of these days, or even a Wyre Piddle. Or perhaps not...
>
> - Brian


Article: 147393
Subject: Re: Craignell2-48 - 48 Pin FPGA DIL Module
From: John Adair <g1@enterpoint.co.uk>
Date: Sun, 25 Apr 2010 21:54:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
No free samples this week but there are discount codes to collect for
anyone that talks to us at the stand this week at ESC. I might even
make a special code award for anyone that spots the unannounced
product on the stand.

The Craignell2 boards themselves are really nice. They are one of my
favorites. We won't spec them to this but I have seen one of these
work from a lot less than 2V all the way up to 5.5V. I have even
programmed them at 2V. The pullup structure with the bus switches
actually allows operation with external logic at these extremes of
voltages provided the external stuff runs at the suitable voltage
levels.

John Adair
Enterpoint Ltd.

On 25 Apr, 19:10, whygee <y...@yg.yg> wrote:
> John Adair wrote:
> > To complete a busy week of new boards a picture of our new 48 pin FPGA
> > DIL module - Craignell2-48 is now onhttp://www.enterpoint.co.uk/component_replacements/craignell2.html.
>
> Congrats, that's a really nice board !
>
> > We have these with us to show at ESC in San Jose this week.for anyone
> > going to that event and wants to see and hold them.
>
> Any free samples ?
>
> OK, seriously, I have a real question :
> how do you find and choose the names of your products ?
> like, you gather your team and take each syllabe from
> their names, and see what combination sounds best ?
>
> I'm just curious :-)
>
> > John Adair
> > Enterpoint Ltd.
>
> yg
>
> --http://ygdes.com/http://yasep.org


Article: 147394
Subject: Re: Quartus II under Windows7?
From: David Brown <david@westcontrol.removethisbit.com>
Date: Mon, 26 Apr 2010 08:54:14 +0200
Links: << >>  << T >>  << A >>
On 23/04/2010 21:39, Rich Webb wrote:
> On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel
> <stephensdigital@gmail.com>  wrote:
>
>> On Apr 21, 1:08 pm, Jon Beniston<j...@beniston.com>  wrote:
>>> It's running ok for me on Windows 7 64-bit.
>>>
>>> What particular part of the software are you having problems with?
>>>
>>> Jon
>>
>> Well it installs alright, but Altium Designer 6 can't find it -
>> whereas it did on my XP box. One problem is that Windows 7 likes to
>> put 32 bit legacy programs under Program FIles(x86), but Quartus won't
>> install there because it can't handle spaces or special characters in
>> it's filenames.
>
> Tell it to use the 8.3 name for the directory (one way of seeing this is
> to do a "dir /X" from a command prompt). For the directory above, the
> name would be "c:\progra~2\".
>

Alternatively, avoid "Program Files" or "Program Files (x86)" like the 
plague - these are seriously stupid path names MS has chosen.

When installing almost any new software, you have a free choice of the 
installation path - if you think you might ever want to refer to the 
program or its files by path name (such as the command line), use 
something like "c:\Progs\" as the base instead of "c:\Program Files".

I have no idea whether this will help you here or not, but it will avoid 
the awkward installation path.


Article: 147395
Subject: Re: I'd rather switch than fight!
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Mon, 26 Apr 2010 00:56:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 24, 3:26=A0am, Patrick Maupin <pmau...@gmail.com> wrote:

> Well, it's hard for me to know what you are looking for in "raising
> the abstraction level" when you showed the code this way. =A0In my
> opinion, coding run/stop and direction separately unnecessarily lowers
> the abstraction level.

'run' and 'dir' come from the original Xilinx examples, and play the
crucial role in the story. In particular, the mismatch between the
Xilinx VHDL and verilog versions is due to different assignment types
to these variables. You will understand that I treat them as a given
in my article that tries to shed a light on the issues.

> Note that this violates my preference not to use 'next_xxx' on the rhs
> in one instance (but doesn't violate any of the underlying rules laid
> out by Cliff Cummings), but given the choice between an extra variable
> and this minor infraction (where it can be easily seen that next_state
> is never used until all potential assignments to it have occurred), I
> would probably code it as I have shown.

Thanks for your coding efforts.

These are the kind of considerations that I'm trying to put on the
agenda, translated to your closer-to-hardware coding style. I note
that you conclude, quite appropriately, that the best option here is
to depart from your preferred style. In effect, what you are doing is
making more effective use of variable semantics as offered by the HDL.

Jan



Article: 147396
Subject: Re: Efficient Multi-Ported Memories for FPGAs
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 26 Apr 2010 04:31:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 26, 12:04=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Apr 25, 7:57=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>
>
>
> > On Apr 25, 12:03=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > Each write port writes its data into its block RAM and at the same
> > > time writes its column number to LVT column
> > > so that LVT column stores the latest write column number for the
> > > latest write address.
>
> > > When being read, read port first reads the LVT column to get the
> > > column number which stores the latest write data with the read
> > > address,
> > > then read the latest write column ( block RAM ) into its read output
> > > register.
>
> > So what happens when the multiple reads all want to read from the same
> > memory because that happens to be where all the last values were
> > written for that read?
>
> > As to the XOR, I don't have code to share; I developed it a while ago
> > for some asynchronous stuff and it applies well to multi-port writes.
>
> > As I try to put together a clearer explanation, I find I may have been
> > wrong about the memory count for the XOR approach such that the LVT
> > would use fewer. =A0I still believe the LVT approach requires M*N
> > BlockRAMs for an M-write, N-read multi-port memory plus the LVT; I'm
> > having trouble remembering why I thought the "+1" was needed. =A0The XO=
R
> > approach appears to need M*(M-1+N) memories.
>
> > If you have 3 write ports and 4 read ports, you'll need 3 sets of *6*
> > memories. =A0The 6 memories in the "write bank" set all have the same
> > write address and write data corresponding to that write port. =A0When =
a
> > write occurs, the *read* value for that write address is accessed from
> > the other two write banks so each set of 6 must provide a read address
> > for the other two write bank addresses. =A0The four reads have their ow=
n
> > memories for their own addresses in each of the write banks.
>
> > When the write occurs, the read values for that write address are
> > retrieved from the other write banks and the XOR of those values along
> > with the new write data are written to all the write ports for its
> > bank of 6 memories. =A0When a read is performed, the read value within
> > each write bank is retrieved and the values (3 in this case) are XORed
> > to get the original data.
>
> > newDataWr0^oldDataWr1^oldDataWr2 overwrites oldDataWr0 for the write.
>
> > The later reads retrieve oldDataWr0, oldDataWr1, and oldDataWr2 but
> > =A0since oldDataWr0 was updated to newDataWr0^oldDataWr1^oldDataWr2,
> > =A0the XOR of the three read values are
> > oldDataWr0^oldDataWr1^oldDataWr2 =3D=3D
> > =A0(newDataWr0^oldDataWr1^oldDataWr2)^oldDataWr1^oldDataWr2 =3D=3D
> > =A0newDataWr0^(oldDataWr1^oldDataWr1)^(oldDataWr2^oldDataWr2) =3D=3D
> > =A0newDataWr0^(0)^(0) =3D=3D
> > =A0newDataWr0
>
> > So with a little coordination, the XOR approach requires M*(M-1+N)
> > BlockRAMs for an M write, N read port memory along with the XORs.
>
> > The LVT needs a memory for each write port but requires multiples of
> > them to accommodate every read port in case the multiple reads for any
> > one cycle are all from the same write bank for the most recently
> > updated value.
>
> > Depending on the complexity of the LVT, the number of write ports, and
> > the allowable latencies, the LVT could be a more effective approach.
>
> "The LVT needs a memory for each write port but requires multiples of
> them to accommodate every read port in case the multiple reads for
> any
> one cycle are all from the same write bank for the most recently
> updated value. "
>
> I don't see any problem reading any of 9 block RAM into one read
> register by a selection data or to any number of read registers by a
> selection data.
>
> Your XOR method is inferior to the LVT method absolutely, even though
> I have no full knowledge of your XOR method.
>
> The LVT method is very clean, very fast and easy to implement and so
> flexible that
> even 2 block RAM with each having independent 2 write ports and 2 read
> ports can be easily
> expanded into 4 write ports and 4 read ports.
>
> Weng

There are engineering tradeoffs in everything.  You surprise me by
saying my approach is inferior "absolutely."  Bad form.

I reread your post after adding mine.  It looks like you believe some
form of scheduling is still needed.  That's what the LVT approach was
trying to overcome!  Or at least I thought it was.

Have you ever tried to implement a 512-entry distributed CLB
SelectRAM?  The latency and resources are pretty extreme.  If one has
a design with no clocking concerns and lots of room for logic in the
FPGA, the LVT approach is stellar.  If the clock rate is a serious
concern and there are plenty of memories left over, the XOR approach
excels.  "Absolutely."

If the LVT approach is not designed to allow next-cycle reads, the
approach has little merit over simpler approaches like "multipumping"
or cache-based write queues.  But the LVT *can* handle multiple reads
by having one memory for each read port associated with each write
memory.

It's all tradeoffs.  There are absolutely no absolutes.

Article: 147397
Subject: Virtex 4 ICAP partial reconfiguration
From: Andrea Miele <andmiele@gmail.com>
Date: Mon, 26 Apr 2010 05:17:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have built a design with PR flow 9.2 using bus macros. The dynamic
reconfiguration works using Impact and downloading the partial
bistreams.
I have connected the  Virtex 4 ICAP port to the LEON3 processor
through the AMBA APB bus.
I would like to perform partial reconfiguration through ICAP.
I have a C software running on LEON 3 wich writes the partial bistream
onto ICAP.
The partial bitstream file has been trimmed in order to start with the
FFFFFFFF dword (the header has been cut off) and
included in the executable as a integer array.
The software write all the dwords of the bitstream on the ICAP, but
the virtex 4 seems to be not reconfigured as it happens
with Impact.
What is wrong?

Andrea

Article: 147398
Subject: Re: I'd rather switch than fight!
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 26 Apr 2010 13:27:51 +0100
Links: << >>  << T >>  << A >>
Chris Higgs <chiggs.99@googlemail.com> writes:

> You can only use sequential processes and make it impossible to infer
> a latch but lose the ability to use a combinatorially derived signal.
> Alternatively you can use a two-process technique which allows
> intermediate/derived signals to be used but accept the risk that bad
> code will introduce latches. 

Or you can use a single sequential process with variables to infer
both combinatorial logic and flip-flops, which both avoids latches and
allows the ability to use a combinatorially derived "signal" (in the
non-VHDL sense of the word).

Cheers,
Martin

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

Article: 147399
Subject: Re: Virtex 4 ICAP partial reconfiguration
From: Sean Durkin <news_MONTH@tuxroot.de>
Date: Mon, 26 Apr 2010 14:33:28 +0200
Links: << >>  << T >>  << A >>
Andrea Miele wrote:

> The software write all the dwords of the bitstream on the ICAP, but
> the virtex 4 seems to be not reconfigured as it happens
> with Impact.
> What is wrong?

Do you send some more empty data words (I think that's 0x20202020 or
something like that, can't remember) after the actual bitstream?

At least when you configure the entire FPGA via SelectMAP or the serial
interface you always have to give the configuration state machine a few
additional clock cycles after clocking in all of the configuration data,
or it won't complete.

HTH,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
and the two-digit code for the current year (simple, eh?).



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