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 134350

Article: 134350
Subject: Re: how to change the system clk in EDK project
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 7 Aug 2008 05:14:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 7, 3:40=A0am, fmostafa <fatma.abouele...@ugent.be> wrote:
> hi all;
>
> I have a question about the system clk in EDK project, my processor
> clk is 100 Mhz and my bus clk is 25Mhz , i tried to increase =A0the bus
> clk to =A050 Mhz , i did this by changing in the DCM , as i changed
> the =A0CLKDV divisor to 2 instead of 4 , which means as i thought
> (100/2) instead of (100/4), and cleaned the hardware and i stared to
> generate the netlist and the bitstream but i don't know the uart is
> not working in a right way , and of course i couldn't examine the rest
> of the system .
> i don't know if what i did is right or there is something missed or
> there is another way to change the frequency.
>
> thanks
> fatma


There are several cores that need to have their parameters updated
when you change the OPB/PLB bus speed.

The UART lite is one of these cores.  It has a parameter C_CLK_FREQ
that needs to be set to the new frequency.  You can change it in the
MHS file, or from the Configure IP GUI window under system/OPB.

There are other cores that need to be updated as well. I don't have a
complete list of the, but serial IO cores, such as the UART and SPI
cores, tend to generate baud rates or external clocks from the bus
clock.

Regards,

John McCaskill
www.FasterTechnology.com

Article: 134351
Subject: Re: RTL Schematic as EDIF
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 07 Aug 2008 13:31:43 +0100
Links: << >>  << T >>  << A >>
On Thu, 07 Aug 2008 11:29:43 +0200, Johann Glaser wrote:

>Hi!
>
>My PhD thesis deals with coarse-grained reconfigurable logic. Therefore
>the RTL schematic synthesis result is one major input for my work.
>
>I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both
>tools provide this RTL netlist (before implementing it to the technology
>netlist), but both in encrypted file formats.

Yes, but every synth tool can write out a post-synthesis netlist
in VHDL or Verilog ready for functional simulation.  Sure you 
don't get a schematic, but I would have thought that a VHDL
or Verilog netlist of primitives would be just as good.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

From glaser@ict.tuwien.ac.at Thu Aug 07 05:59:43 2008
Path: nlpi059.nbdc.sbc.com!nlpi062.nbdc.sbc.com!prodigy.com!nlpi057.nbdc.sbc.com!prodigy.net!feeder.erje.net!news-fra1.dfn.de!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail
Newsgroups: comp.arch.fpga
Subject: Re: RTL Schematic as EDIF
From: Johann Glaser <glaser@ict.tuwien.ac.at>
In-Reply-To: <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com>
References: <1218101383.15335.13.camel@glaser>
	 <kmql9456jj9kt53rm5qo7g371rn65daaqp@4ax.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1218113983.15335.25.camel@glaser>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Date: Thu, 07 Aug 2008 14:59:43 +0200
Lines: 36
NNTP-Posting-Host: pc53.ict.tuwien.ac.at
X-Trace: 1218113849 tunews.univie.ac.at 11868 128.131.80.53
X-Complaints-To: abuse@tuwien.ac.at
Xref: prodigy.net comp.arch.fpga:147118
X-Received-Date: Thu, 07 Aug 2008 08:57:36 EDT (nlpi059.nbdc.sbc.com)

Hi!

Am Donnerstag, den 07.08.2008, 13:31 +0100 schrieb Jonathan Bromley:
> On Thu, 07 Aug 2008 11:29:43 +0200, Johann Glaser wrote:
> 
> >Hi!
> >
> >My PhD thesis deals with coarse-grained reconfigurable logic. Therefore
> >the RTL schematic synthesis result is one major input for my work.
> >
> >I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both
> >tools provide this RTL netlist (before implementing it to the technology
> >netlist), but both in encrypted file formats.
> 
> Yes, but every synth tool can write out a post-synthesis netlist
> in VHDL or Verilog ready for functional simulation.  Sure you 
> don't get a schematic, but I would have thought that a VHDL
> or Verilog netlist of primitives would be just as good.

The schematic itself is not important for me, the netlist is the thing I
want. For my research project I need the RTL netlist because it holds
"higher level" information, like e.g. counters, MUXes, ... A technology
mapped netlist is of no use for me, because the "interesting" things
have already gone there.

The HDL netlist is quite nice for me, but unfortunately a bit hard to
work with. I'd have to implement a complex parser and as well as some
"small synthesis" algorithms.

Do you know if there is a reason, why synthesis tools refuse the user to
get the RTL netlist as EDIF?

Thanks
  Hansi



Article: 134352
Subject: Re: how to change the system clk in EDK project
From: fmostafa <fatma.abouelella@ugent.be>
Date: Thu, 7 Aug 2008 07:23:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 7, 2:14 pm, John McCaskill <jhmccask...@gmail.com> wrote:
> On Aug 7, 3:40 am, fmostafa <fatma.abouele...@ugent.be> wrote:
>
> > hi all;
>
> > I have a question about the system clk in EDK project, my processor
> > clk is 100 Mhz and my bus clk is 25Mhz , i tried to increase  the bus
> > clk to  50 Mhz , i did this by changing in the DCM , as i changed
> > the  CLKDV divisor to 2 instead of 4 , which means as i thought
> > (100/2) instead of (100/4), and cleaned the hardware and i stared to
> > generate the netlist and the bitstream but i don't know the uart is
> > not working in a right way , and of course i couldn't examine the rest
> > of the system .
> > i don't know if what i did is right or there is something missed or
> > there is another way to change the frequency.
>
> > thanks
> > fatma
>
> There are several cores that need to have their parameters updated
> when you change the OPB/PLB bus speed.
>
> The UART lite is one of these cores.  It has a parameter C_CLK_FREQ
> that needs to be set to the new frequency.  You can change it in the
> MHS file, or from the Configure IP GUI window under system/OPB.
>
> There are other cores that need to be updated as well. I don't have a
> complete list of the, but serial IO cores, such as the UART and SPI
> cores, tend to generate baud rates or external clocks from the bus
> clock.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com

hi John;
thanks for your reply , but i have another question in the
plb_bram_if_cntlr i think that i have to change the c_plb_period_ps, i
can't understand how to change this parameter.

BEGIN plb_bram_if_cntlr
 PARAMETER INSTANCE = plb_bram_if_cntlr_1
 PARAMETER HW_VER = 1.00.b
 PARAMETER c_plb_clk_period_ps = 20000
 PARAMETER c_baseaddr = 0xfffe0000
 PARAMETER c_highaddr = 0xffffffff
 BUS_INTERFACE SPLB = plb
 BUS_INTERFACE PORTA = plb_bram_if_cntlr_1_port
END

thanks
fatma

Article: 134353
Subject: Re: Downsizing Verilog synthesization.
From: Gabor <gabor@alacron.com>
Date: Thu, 7 Aug 2008 08:05:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 6, 10:21 am, John McCaskill <jhmccask...@gmail.com> wrote:
[snip]
> > Don
>
> Since you state that you run out of slices, I know that your design is
> larger than the FPGA can hold, but I would still point out that the
> slice utilization is a pessimistic view of how much of the FPGA you
> are using, the mapping stage spreads the logic out by default instead
> of packing it as tightly as possible.  The Register and LUT
> utilization is an optimistic measure of how much of the FPGA you have
> left.  You need to watch all of them to get a good idea of how full
> your design really is.
[snip]
> Regards,
>
> John McCaskillwww.FasterTechnology.com

On a related note, I had a design with about 60% LUT and flip-flop
utilization (Spartan 2) that would not fit until I checked "Disable
Register Ordering" in the mapping options.  If you're not exceeding
the capacity of the device by too much you can look at tuning
the tools a bit to help fit the design.

Regards,
Gabor

Article: 134354
Subject: Re: RTL Schematic as EDIF
From: "Sandeep Dutta" <niktechc@niktech.com>
Date: Thu, 7 Aug 2008 08:16:19 -0700
Links: << >>  << T >>  << A >>
Hi,

You might want to take a look at
http://www.eecs.berkeley.edu/~alanmi/abc/
you can download the source, for research
purposes this might be what you need.

--Sandeep 



Article: 134355
Subject: Re: RTL Schematic as EDIF
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 07 Aug 2008 08:36:39 -0700
Links: << >>  << T >>  << A >>
Johann Glaser wrote:

> The schematic itself is not important for me, the netlist is the thing I
> want. For my research project I need the RTL netlist because it holds
> "higher level" information, like e.g. counters, MUXes, ... 

What's wrong with the source code?
That's the highest level I have,
and the easiest object to simulate.

An RTL schematic shows collections of gates and flops.
Some of the gate collections are drawn as MUXes and
others are drawn as boxes:
http://mysite.verizon.net/miketreseler/uart.pdf

I use these interactively to see what my source
code looks like to synthesis, and for documentation.
However, for simulation or making a synthesis image,
the source is the thing.

> Do you know if there is a reason, why synthesis tools refuse the user to
> get the RTL netlist as EDIF?

Because such a netlist is at a lower level
than the source code that created it, and is
not useful for synthesis.

Back before A+X offered RTL views,
I used to roll my own using Leo to map my design
to a simple FPGA architecture like an Actel 1010.
The resulting technology view looked very much
like today's RTL views.
You could make an edif file of something like that.

     -- Mike Treseler

Article: 134356
Subject: Re: Downsizing Verilog synthesization.
From: eromlignod <eromlignod@aol.com>
Date: Thu, 7 Aug 2008 08:43:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 6, 8:05=A0pm, John McCaskill <jhmccask...@gmail.com> wrote:
> On Aug 6, 12:31=A0pm, eromlignod <eromlig...@aol.com> wrote:
>
>
>
>
>
> > On Aug 6, 11:50=A0am, John McCaskill <jhmccask...@gmail.com> wrote:
>
> > > If you can map this onto a block ram, you will save quite a bit of
> > > registers. Whether or not you can do this depends on if you can write
> > > the vectors in one (or a few) at a time, and process them sequentiall=
y
> > > in the time you have available. =A0How much time do you have to proce=
ss
> > > the vectors? Ns, us, ms ?
>
> > Ah, I think I'm following along now. =A0Are you talking about sending
> > the numbers over a single 8-bit vector wire one-at-a-time? =A0Hmmm.
>
> > The vectors are actually independent from each other and refresh at
> > various random rates, so a few usec here or there shouldn't make a
> > difference. =A0I'll give it a try!
>
> > Don
>
> You are asking good questions, so there are multiple people here that
> will be happy to help you out. However, you are asking for some low
> level suggestions without giving enough high level detail. =A0The best
> optimizations are the ones that you apply at the high level where you
> have the most leverage.
>
> If you can tell us more about what you are trying to do you will get
> better responses. You said that you have almost 100 high speed
> channels.
>
> How many channels are there?
> How fast are the pulses arriving on average?
> Over what time is the average?
> What is the air speed of an unladen swallow?
> What is the minimum spacing between pulses?
> How fast does your central processing module need to compare the
> channels?
>
> As Jim Granville pointed our, the various time bases of your problem
> have a major impact on the potential solutions.
>
> Regards,
>
> John McCaskillwww.FasterTechnology.com- Hide quoted text -
>
> - Show quoted text -


Well, I'm being a little cryptic because there are new patent
applications involved and I don't want to give too much away.  I can
tell you those things that are already covered in the first patent
though.

The device is a self-tuning piano.  You can read/listen about it
here...

New York Times:
http://query.nytimes.com/gst/fullpage.html?res=3D9800E1D8133FF931A35752C0A9=
659C8B63

NPR:
http://www.npr.org/templates/story/story.php?storyId=3D878091

New Scientist Magazine:
http://www.newscientist.com/article/dn3143-hotwired-piano-tunes-itself.html

The incoming signals are square waves at the fundamental frequency of
each of the 219 strings in the piano that are being magnetically
sustained (vibrate forever).  I only read 44 strings at a time, tune
them, then go on to the next 44, etc.  So there are 44 counting
modules and an output address signal to instruct the sustainer
circuits when to vibrate the next string.

I first convert the wave to a "period" wave that has an "on" time
equal to one period of the string's vibration.  I then use this wave
to enable counting of the 50-MHz system clock.  So I get a count of
how many clock ticks of the system clock occur for one period of
string vibration.  This takes up to 21 bits for the low strings.  I
average 32 of these numbers and calculate an error based on a stored
setpoint.  Currently I'm using a theoretical setpoint, but eventually
I will want to add the feature whereby a piano tech can hand-tune the
piano and then "store" his tuning numbers for subsequent use.

The output of each of these modules is a 16-bit, signed "error"
vector.  All 44 errors go to an "evaluation" module where it is
decided how much warmth needs to be applied to each string to tune it,
in the form of 219 PWM duty cycles (0  to 256 each).  These numbers
are sent to another two modules and translated to a synchronous serial
output where a separate power circuit decodes and uses them to produce
the individual PWM control lines.  Once the "in tune" value of PWM is
found for each string, it is simply maintained until the system is
switched off.  Actual adjustments only occur when the system is first
turned on.  Currently I can tune each set of 44 strings in about 20 to
30 seconds.

The whole system does indeed work just fine so far.  I'm just running
out of FPGA space, ostensibly because of my poorly-written code.  I
would like to add code to refine the tuning accuracy and time and
possibly add the "store" option, so I need all the space I can get.

Thanks for all of the excellent help so far!

Don A. Gilmore
Kansas City


Article: 134357
Subject: Re: RTL Schematic as EDIF
From: nico@puntnl.niks (Nico Coesel)
Date: Thu, 07 Aug 2008 16:06:40 GMT
Links: << >>  << T >>  << A >>
Johann Glaser <glaser@ict.tuwien.ac.at> wrote:

>Hi!
>
>My PhD thesis deals with coarse-grained reconfigurable logic. Therefore
>the RTL schematic synthesis result is one major input for my work.
>
>I tried Xilinx ISE 10.1 as well as Synplicity Synplify Pro 9.2. Both
>tools provide this RTL netlist (before implementing it to the technology
>netlist), but both in encrypted file formats.
>
>Xilinx ISE 10.1 saves the file as NGR file. Unfortunately there is no
>ngr2edif tool provided (while an ngc2edif is available). 
>
>Synplicity Synplify Pro 9.2 saves a SRS file and provides an edf2srs
>tool, but no reverse.
>
>Could you please point me to tools which can convert these files formats
>to open formats (especially EDIF) or to synthesis tools (not necessarily
>for FPGA, a tool from an ASIC flow is ok too), which save the RTL
>schematic as open file formats.

Why not export to VHDL? It can be regarded as some sort of netlist and
probably converted to EDIF as well. 

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 134358
Subject: ML403, U-Boot+Linux and Ethernet?
From: Philipp Hachtmann <hachti@hachti.de>
Date: Thu, 07 Aug 2008 19:47:04 +0200
Links: << >>  << T >>  << A >>
Hi folks,

I could need some help with my board's network setup (hardware and Linux 
and U-Boot drivers).


This is my situation:

I currently have a Xilinx ML403 board (With Virtex4 FX12) sitting on my 
desk.
I have an EDK 10.1 system which already worked with simple standalone 
applications.
I managed to use crostool to build a working cross toolchain (with 
gcc-4.2.4 and glibc-2.3.6).
Then I downloaded vanilla Linux 2.6.25.11 from kernel.org. It took me a 
while to get the kernel run on my system. I also had to do some little 
changes to get the whole thing together.

I now have a running Linux 2.6.25.11 kernel in an ace file together with 
the design. I can mount a root filesystem from systemace and play around 
via serial (ns16550) console. That's it.

What I want is a full-featured box with ethernet support in Linux and 
U-boot (which I like and want to use as well).

I found some linux ethernet drivers in the EDK directory:
emac_v1_00_e
emac_v1_00_f
emac_v1_01_a
emac_v1_11_a
gemac_v1_00_f
lltemac_linux_2_6_v1_00_a
temac_linux_2_6_v1_00_a
temac_linux_2_6_v2_00_b
temac_linux_2_6_v2_00_c

EDK offers me the following ethernet related modules:
xps_ll_temac
xps_ethernetlite
hard_temac

U-Boot (latest git snapshot) comes with
xilinx_emac.c
xilinx_emaclite.c

I also remember that I once used an xps_ethernetlite or emaclite (sone 
"light" thing) with µCLinux on microblaze (Petalinux).

Now the questions:

Might there be a software compatibility between different emac and temac 
modules?

What should I use? How do things plug together?

How do I correctly set up the FX12's Tri-mode Emac with Linux and U-Boot?

Are there drivers readily available?

Or do I have to combine something new?


I appreciate every hint, link, information, clarifying question and so on!
Thanks a lot!

Best wishes,

Philipp :-)




-- 
You have to reboot your computer after powerfail? Haha!
http://h316.hachti.de

Article: 134359
Subject: Re: RTL Schematic as EDIF
From: Kevin Neilson <kevin_neilson@removethiscomcast.net>
Date: Thu, 07 Aug 2008 11:54:28 -0600
Links: << >>  << T >>  << A >>
Johann Glaser wrote:

> 
> The schematic itself is not important for me, the netlist is the thing I
> want. For my research project I need the RTL netlist because it holds
> "higher level" information, like e.g. counters, MUXes, ... A technology
> mapped netlist is of no use for me, because the "interesting" things
> have already gone there.
> 
> The HDL netlist is quite nice for me, but unfortunately a bit hard to
> work with. I'd have to implement a complex parser and as well as some
> "small synthesis" algorithms.
> 
> Do you know if there is a reason, why synthesis tools refuse the user to
> get the RTL netlist as EDIF?
> 
> Thanks
>   Hansi

Lieber Hansi,
The intermiate (RTL) netlist is usually proprietary.  I don't think 
companies want to give this away.  It sounds like you would really like 
a tool like Verific, which is an HDL parser that a lot of companies are 
buying as a front end for their own synthesis (and simulation) tools. 
It outputs an RTL-type netlist, with high level primitive blocks.  I 
don't know how expensive this would be for an individual user to buy, 
though.

I can think of good reasons why the RTL netlist isn't in a standard 
format.  Assume that you really liked the Xilinx synthesizer, because it 
was so great at inferring structures from behavioral code.  You could 
then get that tool (cheap, since it is subsidized), and then take the 
RTL netlist and synthesize it with a poorer synthesizer using another 
part as a target.
-Kevin


Article: 134360
Subject: Re: Downsizing Verilog synthesization.
From: David Tweed <dtweed@acm.org>
Date: Thu, 07 Aug 2008 14:01:08 -0400
Links: << >>  << T >>  << A >>
John_H wrote:
> If you can't increase the processing frequency, you could still count 
> the LSbits and cycle through the counters, adding and clearing the 
> LSbits to a BlockRAM worth of counter values.  To cycle through 255 
> 32-bit counters, you'd need 8-bit counters for each signal and a 
> read-add-write cycle (using the dual-port mode) for each entry in your 
> list.  You end up only using half the BlockRAM for this extreme number 
> of counters.
> 
> It's more housekeeping but you use a fraction of the count resources.

I once did something very much like this, but in reverse.

I needed to generate 63 PWM outputs with a repetition rate of 1 kHz
and 16-bit resolution (which implies a master clock frequency of
65.536 MHz) on a fairly modest FPGA.

Obviously, the brute-force way to do this is to have a 16-bit master
counter, 63 16-bit registers to hold the duty cycle values, and 63
16-bit comparators to drive the outputs. This would not have fit into
the chip.

So, rather than having 63 16-bit comparators, I used 6-bit comparators.
The duty-cycle values were stored in a 64x16 block RAM (actually 128x16
so that updates to the values could be double-buffered), and I scanned
through that RAM at the master clock rate (1024000 scans/second) and
did the MSB comparison with one common 10-bit comparator. Each of the
6-bit comparators was "enabled" for fine timing when the MSBs matched
for that channel. IIRC, used about 40% of the chip.

-- Dave Tweed

Article: 134361
Subject: Nibz processor @ 472 LEs (16 bit generic specified)
From: jacko <jackokring@gmail.com>
Date: Thu, 7 Aug 2008 11:22:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi

http://nibz.googlecode.com processor ith VHDL just put up. Fully
generic design. 16 bit version is 472 ltera LEs MAX II. There is still
some optimization to be done. Wishbone master interface is primary
interface. SEL_O all set to ones no matter what generic word size is
used.

cheers
jacko

Article: 134362
Subject: Re: Downsizing Verilog synthesization.
From: David Tweed <dtweed@acm.org>
Date: Thu, 07 Aug 2008 14:44:02 -0400
Links: << >>  << T >>  << A >>
eromlignod wrote:
> The incoming signals are square waves at the fundamental frequency of
> each of the 219 strings in the piano that are being magnetically
> sustained (vibrate forever).  I only read 44 strings at a time, tune
> them, then go on to the next 44, etc.  So there are 44 counting
> modules and an output address signal to instruct the sustainer
> circuits when to vibrate the next string.
> 
> I first convert the wave to a "period" wave that has an "on" time
> equal to one period of the string's vibration.  I then use this wave
> to enable counting of the 50-MHz system clock.  So I get a count of
> how many clock ticks of the system clock occur for one period of
> string vibration.  This takes up to 21 bits for the low strings.  I
> average 32 of these numbers and calculate an error based on a stored
> setpoint.  Currently I'm using a theoretical setpoint, but eventually
> I will want to add the feature whereby a piano tech can hand-tune the
> piano and then "store" his tuning numbers for subsequent use.

Ah, this makes what you are doing much clearer.

One immediate suggestion would be this: Rather than using 44 separate
50-MHz counters, use just one counter and 44 registers that capture
the value of that counter when the rising edge of the input occurs.

Then, you have a module that scans those 44 latches, and each time
one is updated, you subtract the previous value from the current value
(mod 2**21) to get the period for that string. This should save a lot
of chip resources, converting lots of slice flip-flops into block RAM.

The "previous values" can be stored in block RAM, the calibration
periods can be stored in block RAM, the PWM values can be stored in
block RAM, etc. Everything except for the 44 latches can be processed
sequentially rather than in parallel.

-- Dave Tweed

Article: 134363
Subject: Re: Downsizing Verilog synthesization.
From: eromlignod <eromlignod@aol.com>
Date: Thu, 7 Aug 2008 12:33:13 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 7, 1:44=A0pm, David Tweed <dtw...@acm.org> wrote:
> eromlignod wrote:
> > The incoming signals are square waves at the fundamental frequency of
> > each of the 219 strings in the piano that are being magnetically
> > sustained (vibrate forever). =A0I only read 44 strings at a time, tune
> > them, then go on to the next 44, etc. =A0So there are 44 counting
> > modules and an output address signal to instruct the sustainer
> > circuits when to vibrate the next string.
>
> > I first convert the wave to a "period" wave that has an "on" time
> > equal to one period of the string's vibration. =A0I then use this wave
> > to enable counting of the 50-MHz system clock. =A0So I get a count of
> > how many clock ticks of the system clock occur for one period of
> > string vibration. =A0This takes up to 21 bits for the low strings. =A0I
> > average 32 of these numbers and calculate an error based on a stored
> > setpoint. =A0Currently I'm using a theoretical setpoint, but eventually
> > I will want to add the feature whereby a piano tech can hand-tune the
> > piano and then "store" his tuning numbers for subsequent use.
>
> Ah, this makes what you are doing much clearer.
>
> One immediate suggestion would be this: Rather than using 44 separate
> 50-MHz counters, use just one counter and 44 registers that capture
> the value of that counter when the rising edge of the input occurs.
>
> Then, you have a module that scans those 44 latches, and each time
> one is updated, you subtract the previous value from the current value
> (mod 2**21) to get the period for that string. This should save a lot
> of chip resources, converting lots of slice flip-flops into block RAM.
>
> The "previous values" can be stored in block RAM, the calibration
> periods can be stored in block RAM, the PWM values can be stored in
> block RAM, etc. Everything except for the 44 latches can be processed
> sequentially rather than in parallel.
>
> -- Dave Tweed
>
> - Show quoted text -


I like this idea.  But how do I handle the case when the counter rolls
back to zero inside a period measurement?  Excuse my thickheadedness,
but I'm actually an ME by trade and just taught myself HDL a few
months ago.

Don

Article: 134364
Subject: Re: Downsizing Verilog synthesization.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 08 Aug 2008 07:57:59 +1200
Links: << >>  << T >>  << A >>
David Tweed wrote:

> eromlignod wrote:
> 
>> The incoming signals are square waves at the fundamental frequency of
>> each of the 219 strings in the piano that are being magnetically
>> sustained (vibrate forever).  I only read 44 strings at a time, tune
>> them, then go on to the next 44, etc.  So there are 44 counting
>> modules and an output address signal to instruct the sustainer
>> circuits when to vibrate the next string.
>>
>> I first convert the wave to a "period" wave that has an "on" time
>> equal to one period of the string's vibration.  I then use this wave
>> to enable counting of the 50-MHz system clock.  So I get a count of
>> how many clock ticks of the system clock occur for one period of
>> string vibration.  This takes up to 21 bits for the low strings.  I
>> average 32 of these numbers and calculate an error based on a stored
>> setpoint.  Currently I'm using a theoretical setpoint, but eventually
>> I will want to add the feature whereby a piano tech can hand-tune the
>> piano and then "store" his tuning numbers for subsequent use.
> 

There is flaw in this approach, which is the Signal to Noise
of a SINGLE cycle. With 44 going off at once, you will have crosstalk.
That 21 bits will be mostly an illusion.


> Ah, this makes what you are doing much clearer.
> 
> One immediate suggestion would be this: Rather than using 44 separate
> 50-MHz counters, use just one counter and 44 registers that capture
> the value of that counter when the rising edge of the input occurs.
> 
> Then, you have a module that scans those 44 latches, and each time
> one is updated, you subtract the previous value from the current value
> (mod 2**21) to get the period for that string. This should save a lot
> of chip resources, converting lots of slice flip-flops into block RAM.
> 
> The "previous values" can be stored in block RAM, the calibration
> periods can be stored in block RAM, the PWM values can be stored in
> block RAM, etc. Everything except for the 44 latches can be processed
> sequentially rather than in parallel.

Even simpler, since you KNOW what frequency you want, set up
a pair of Loadable counter, close together as MIN as MIX and generate a 
TuneUP and TuneDOWN signal from when outside this error band.

- drive those into LEDS and your Tune motors.

Then your datapaths are just the error signals.

Read up on reciprocal Frequecy counters, these give higher
precisions by counting a time for a certain WHOLE number
of cycles.
To do that, you would preload 3 numbers, the Min/Max counts, and
the cycles to total over. Much better signal to noise.
You might even get the whole thing working in a Block Ram,
as you can lower the 50MHz...


You don't want the pianist saying your system is crap do you ;)

-jg





Article: 134365
Subject: Altera Cyclone and Stratix II
From: jon <jon@pyramidemail.com>
Date: Thu, 7 Aug 2008 13:12:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Below you will find a list of Altera product that is left over from
builds. I need to move this product ASAP and should be able to be able
to supply far below factory direct.  All product is new in original
factory packaging. I have supported several members of this users
group and they have all be very happy with  product and level of
service. I thank you all for your support. If interested I also have
plenty of LCD's,SRAM and DDR memory.

Regards,
Jon E. Hansen
(949)864-7745 direct
jon@pyramidemail.com
www.pyramidtechnologiesinc.com

EP2C35F672C6N                       EP1S80F1020C5
EP20K600EFC672-3                   EP1S80F1020C5N
EP20K400EFC672-2X                 EP20K100FC324-2
EP2S60F1020C5N                      EP1S60F1020C5N
EP2S60F672C5N                        EP1S60F1020C5

EP1S40F780C6
EPF10K100ARC240-3                 EP1S40F780C5N
EPF10K100EQC240-1                 EP2SGX90FF1508C3N
EPF10K10QC208-3                     EP1K50QI208-2
EPM9400RC208-15                     EP1C20F400C6
EP2S180F1020C3N
EP2C20F484C8N
EP2A40B724C8
EP20K400EBC652-1
EP20K400BC652-1V
EP20K300EFC672-1
EP20K200EQC240-1N
EP20K200EFC672-3
EP20K200CF484C9

Article: 134366
Subject: Re: Downsizing Verilog synthesization.
From: David Tweed <dtweed@acm.org>
Date: Thu, 07 Aug 2008 16:38:06 -0400
Links: << >>  << T >>  << A >>
eromlignod wrote:
> I like this idea. But how do I handle the case when the counter
> rolls back to zero inside a period measurement?

Modular arithmetic -- what I was alluding to with the "mod 2**21"
comment -- takes care of that automatically. As long as you treat
the difference as a positive number, it will always be correct,
even if the counter rolls over.

Actually, I can think of many refinements to this basic idea.
Since you have a system clock of 50 MHz, you can easily scan your
44 input channels in well under 1 us, which means you really only
need a 6-bit latch for each channel, along with an "edge happened"
flag. Everything else can be handled with resources that are
shared among all of the channels.

To be honest, this is a system that really begs for a microcontroller.
The only hardware that should be in the FPGA are the latches for your
44 period measurement channels and your 219 PWM output channels.
Everything else -- the difference logic for the period calculation,
the calibration algorithm, the preset tuning numbers, user interface
features -- should be microcontroller firmware.

 > Excuse my thickheadedness, but I'm actually an ME by trade and just
 > taught myself HDL a few months ago.

Really? The press announcments about this system that you linked to
date from 2002-03 or so. Has it really taken that long to begin an
implementation?

-- Dave Tweed

Article: 134367
Subject: Re: Downsizing Verilog synthesization.
From: eromlignod <eromlignod@aol.com>
Date: Thu, 7 Aug 2008 13:51:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 7, 2:57=A0pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> David Tweed wrote:
> > eromlignod wrote:
>
> >> The incoming signals are square waves at the fundamental frequency of
> >> each of the 219 strings in the piano that are being magnetically
> >> sustained (vibrate forever). =A0I only read 44 strings at a time, tune
> >> them, then go on to the next 44, etc. =A0So there are 44 counting
> >> modules and an output address signal to instruct the sustainer
> >> circuits when to vibrate the next string.
>
> >> I first convert the wave to a "period" wave that has an "on" time
> >> equal to one period of the string's vibration. =A0I then use this wave
> >> to enable counting of the 50-MHz system clock. =A0So I get a count of
> >> how many clock ticks of the system clock occur for one period of
> >> string vibration. =A0This takes up to 21 bits for the low strings. =A0=
I
> >> average 32 of these numbers and calculate an error based on a stored
> >> setpoint. =A0Currently I'm using a theoretical setpoint, but eventuall=
y
> >> I will want to add the feature whereby a piano tech can hand-tune the
> >> piano and then "store" his tuning numbers for subsequent use.
>
> There is flaw in this approach, which is the Signal to Noise
> of a SINGLE cycle. With 44 going off at once, you will have crosstalk.
> That 21 bits will be mostly an illusion.
>
> > Ah, this makes what you are doing much clearer.
>
> > One immediate suggestion would be this: Rather than using 44 separate
> > 50-MHz counters, use just one counter and 44 registers that capture
> > the value of that counter when the rising edge of the input occurs.
>
> > Then, you have a module that scans those 44 latches, and each time
> > one is updated, you subtract the previous value from the current value
> > (mod 2**21) to get the period for that string. This should save a lot
> > of chip resources, converting lots of slice flip-flops into block RAM.
>
> > The "previous values" can be stored in block RAM, the calibration
> > periods can be stored in block RAM, the PWM values can be stored in
> > block RAM, etc. Everything except for the 44 latches can be processed
> > sequentially rather than in parallel.
>
> Even simpler, since you KNOW what frequency you want, set up
> a pair of Loadable counter, close together as MIN as MIX and generate a
> TuneUP and TuneDOWN signal from when outside this error band.
>
> - drive those into LEDS and your Tune motors.
>
> Then your datapaths are just the error signals.
>
> Read up on reciprocal Frequecy counters, these give higher
> precisions by counting a time for a certain WHOLE number
> of cycles.
> To do that, you would preload 3 numbers, the Min/Max counts, and
> the cycles to total over. Much better signal to noise.
> You might even get the whole thing working in a Block Ram,
> as you can lower the 50MHz...
>
> You don't want the pianist saying your system is crap do you ;)
>
> -jg- Hide quoted text -
>
> - Show quoted text -


An ordinary frequency counter is not an option in this application.
The lowest note A0 in a piano is 27.5 Hz and I need an accuracy of
less than one "cent" (1/100th of a musical semitone).  One cent sharp
at 27.5 Hz is

27.5 * (2**(1/1200)) =3D 27.5159 Hz

That's a difference in frequency of .0159 Hz.  To be able to count
with this accuracy would require that I count for at least a minute to
get each reading.  This is unacceptable.

Also, please read the publicity I posted the links to, or the patent
(6,559,369).  I do not use any moving parts to control the string's
pitch.

Don
Kansas City

Article: 134368
Subject: Re: Downsizing Verilog synthesization.
From: eromlignod <eromlignod@aol.com>
Date: Thu, 7 Aug 2008 14:07:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 7, 3:38=A0pm, David Tweed <dtw...@acm.org> wrote:
> eromlignod wrote:
> =A0> Excuse my thickheadedness, but I'm actually an ME by trade and just
> =A0> taught myself HDL a few months ago.
>
> Really? The press announcments about this system that you linked to
> date from 2002-03 or so. Has it really taken that long to begin an
> implementation?
>
> -- Dave Tweed


All of this was originally supposed to be prototyped by an electronics
firm in Florida, starting in the summer of 2002.  I had a five-year
royalty contract with Story & Clark Pianos (QRS) to build it.  After
the five years was up, they still hadn't got around to starting the
project.  They kept putting it on the back burner as other projects
and financial concerns took priority.  I refused to renew their
contract in 2007 and am using the minimum royalty money that they had
paid me, to build the prototype myself.

I thought about a microcontroller for the main processing, but decided
that I could probably do it all with the FPGA...and did so, except for
this size problem.  But I think by implementing some of your ideas, I
can considerably reduce the number of slices.  Thanks.

Don
Kansas City

Article: 134369
Subject: Re: Downsizing Verilog synthesization.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 08 Aug 2008 09:13:08 +1200
Links: << >>  << T >>  << A >>
eromlignod wrote:
> I like this idea.  But how do I handle the case when the counter rolls
> back to zero inside a period measurement?  Excuse my thickheadedness,
> but I'm actually an ME by trade and just taught myself HDL a few
> months ago.

Normally you capture the value, and simply subtract Newest-Previous.
IF newest < previous then overflow occured, and you replace as
Newest+(MAX-Previous).
-jg


Article: 134370
Subject: Re: Microblaze to LCD module via FSL bus
From: Eric Smith <eric@brouhaha.com>
Date: Thu, 07 Aug 2008 15:16:27 -0700
Links: << >>  << T >>  << A >>
Ray D. wrote:
> but I want to add a MicroBlaze core and connect my
> hardware LCD module to the FSL bus instead of implementing software
> drivers.

That seems like a non sequitur to me.  Surely you need some kind of
"software drivers" for the LCD regardless of whether the LCD is conencted
to FSL or to a GPIO peripheral on an OPB or PLB bus?  The use of FSL
vs. another bus only changes the method the driver would use to write
to the LCD module.


Article: 134371
Subject: Re: ISE 8.1i sp3: map is not recognized as an internal or external
From: andersod2 <thechrisanderson@gmail.com>
Date: Thu, 7 Aug 2008 15:16:40 -0700 (PDT)
Links: << >>  << T >>  << A >>

That error is given by the DOS shell when it can't find the command
you've typed.....are you using the default options for ISE (i.e. not
using a batch script)?  I know the commands they use aren't prefixed
with the xilinx directory which could create issues with the
path...but that seems screwy that it would hard code the map command
to a seperate directory like that...that's why I ask if you're using a
batch script...check your projects .cmd_log file, and your
paths...sorry if that doesn't help, as I'm a beginner as well to ISE.

Article: 134372
Subject: Re: What's the deal with PSoC programmers?
From: andersod2 <thechrisanderson@gmail.com>
Date: Thu, 7 Aug 2008 15:18:40 -0700 (PDT)
Links: << >>  << T >>  << A >>

> If you want a low-cost board to experiment with both a Xilinx FPGA and
> a Cypress PSoC, try this $39 kit:
>
> www.em.avnet.com/spartan3a-evl
>


Yeah, I just ordered it...but 10-12 week backlog though :(  Must be
popular....

Article: 134373
Subject: Re: Downsizing Verilog synthesization.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 08 Aug 2008 10:36:08 +1200
Links: << >>  << T >>  << A >>


eromlignod wrote:

> On Aug 7, 2:57 pm, Jim Granville <no.s...@designtools.maps.co.nz>
>>
>>Even simpler, since you KNOW what frequency you want, set up
>>a pair of Loadable counter, close together as MIN as MIX and generate a
>>TuneUP and TuneDOWN signal from when outside this error band.
>>
>>- drive those into LEDS and your Tune motors.
>>
>>Then your datapaths are just the error signals.
>>
>>Read up on reciprocal Frequecy counters, these give higher
>>precisions by counting a time for a certain WHOLE number
>>of cycles.
>>To do that, you would preload 3 numbers, the Min/Max counts, and
>>the cycles to total over. Much better signal to noise.
>>You might even get the whole thing working in a Block Ram,
>>as you can lower the 50MHz...
>>
>>You don't want the pianist saying your system is crap do you ;)
>>
>>-jg- Hide quoted text -
>>
>>- Show quoted text -
> 
> 
> 
> An ordinary frequency counter is not an option in this application.
> The lowest note A0 in a piano is 27.5 Hz and I need an accuracy of
> less than one "cent" (1/100th of a musical semitone).  One cent sharp
> at 27.5 Hz is
> 
> 27.5 * (2**(1/1200)) = 27.5159 Hz

Read what I wrote carefully. "Read up on reciprocal Frequecy counters"
A Reciprocal Frequecy counter is not an ordinary frequency counter :)
It counts in two domains: Whole cycles and time.

Your values above are a dT of 17.05us.
Suppose you measure 3 whole cycles, giving ~9 readings a second
then a (relatively low) 1MHz reciprocal Counter will give a 63 count
difference on your 15.9mHz dF example. - so is about 6 bits more
precise than you need.

You can change the sample time, to improve noise filtering, or
the Mhz to give you more FPGA time.
500KHz is 100 cycles at 50MHz, (which sounds useful) and
still gives 5 bits precision headroom at 9 samples/second.
(more at lower samples/sec)

eg at a 1-2us timebase, you can edge count 25-50 channels in
block ram, with a simple state engine. Interleave the
INC and Decision cycles for simplicity.

> 
> That's a difference in frequency of .0159 Hz.  To be able to count
> with this accuracy would require that I count for at least a minute to
> get each reading.  This is unacceptable.
> 
> Also, please read the publicity I posted the links to, or the patent
> (6,559,369).  I do not use any moving parts to control the string's
> pitch.

Wow - what is your power budget ?

<paste>
> I thought about a microcontroller for the main processing, but decided
> that I could probably do it all with the FPGA...and did so, except for
> this size problem.  But I think by implementing some of your ideas, I
> can considerably reduce the number of slices.  Thanks.

A fpga is a good development vehicle.
Good luck.

-jg




Article: 134374
Subject: Re: Downsizing Verilog synthesization.
From: Jeff Cunningham <jcc@sover.net>
Date: Thu, 07 Aug 2008 23:07:04 -0400
Links: << >>  << T >>  << A >>
eromlignod wrote:
> On Aug 6, 8:05 pm, John McCaskill <jhmccask...@gmail.com> wrote:
>> On Aug 6, 12:31 pm, eromlignod <eromlig...@aol.com> wrote:
>>
>>
>>
>>
>>
>>> On Aug 6, 11:50 am, John McCaskill <jhmccask...@gmail.com> wrote:
>>>> If you can map this onto a block ram, you will save quite a bit of
>>>> registers. Whether or not you can do this depends on if you can write
>>>> the vectors in one (or a few) at a time, and process them sequentially
>>>> in the time you have available.  How much time do you have to process
>>>> the vectors? Ns, us, ms ?
>>> Ah, I think I'm following along now.  Are you talking about sending
>>> the numbers over a single 8-bit vector wire one-at-a-time?  Hmmm.
>>> The vectors are actually independent from each other and refresh at
>>> various random rates, so a few usec here or there shouldn't make a
>>> difference.  I'll give it a try!
>>> Don
>> You are asking good questions, so there are multiple people here that
>> will be happy to help you out. However, you are asking for some low
>> level suggestions without giving enough high level detail.  The best
>> optimizations are the ones that you apply at the high level where you
>> have the most leverage.
>>
>> If you can tell us more about what you are trying to do you will get
>> better responses. You said that you have almost 100 high speed
>> channels.
>>
>> How many channels are there?
>> How fast are the pulses arriving on average?
>> Over what time is the average?
>> What is the air speed of an unladen swallow?
>> What is the minimum spacing between pulses?
>> How fast does your central processing module need to compare the
>> channels?
>>
>> As Jim Granville pointed our, the various time bases of your problem
>> have a major impact on the potential solutions.
>>
>> Regards,
>>
>> John McCaskillwww.FasterTechnology.com- Hide quoted text -
>>
>> - Show quoted text -
> 
> 
> Well, I'm being a little cryptic because there are new patent
> applications involved and I don't want to give too much away.  I can
> tell you those things that are already covered in the first patent
> though.
> 
> The device is a self-tuning piano.  You can read/listen about it
> here...
> 
> New York Times:
> http://query.nytimes.com/gst/fullpage.html?res=9800E1D8133FF931A35752C0A9659C8B63
> 
> NPR:
> http://www.npr.org/templates/story/story.php?storyId=878091
> 
> New Scientist Magazine:
> http://www.newscientist.com/article/dn3143-hotwired-piano-tunes-itself.html
> 
> The incoming signals are square waves at the fundamental frequency of
> each of the 219 strings in the piano that are being magnetically
> sustained (vibrate forever).  I only read 44 strings at a time, tune
> them, then go on to the next 44, etc.  So there are 44 counting
> modules and an output address signal to instruct the sustainer
> circuits when to vibrate the next string.
> 
> I first convert the wave to a "period" wave that has an "on" time
> equal to one period of the string's vibration.  I then use this wave
> to enable counting of the 50-MHz system clock.  So I get a count of
> how many clock ticks of the system clock occur for one period of
> string vibration.  This takes up to 21 bits for the low strings.  I
> average 32 of these numbers and calculate an error based on a stored
> setpoint.  Currently I'm using a theoretical setpoint, but eventually
> I will want to add the feature whereby a piano tech can hand-tune the
> piano and then "store" his tuning numbers for subsequent use.
> 
> The output of each of these modules is a 16-bit, signed "error"
> vector.  All 44 errors go to an "evaluation" module where it is
> decided how much warmth needs to be applied to each string to tune it,
> in the form of 219 PWM duty cycles (0  to 256 each).  These numbers
> are sent to another two modules and translated to a synchronous serial
> output where a separate power circuit decodes and uses them to produce
> the individual PWM control lines.  Once the "in tune" value of PWM is
> found for each string, it is simply maintained until the system is
> switched off.  Actual adjustments only occur when the system is first
> turned on.  Currently I can tune each set of 44 strings in about 20 to
> 30 seconds.
> 
> The whole system does indeed work just fine so far.  I'm just running
> out of FPGA space, ostensibly because of my poorly-written code.  I
> would like to add code to refine the tuning accuracy and time and
> possibly add the "store" option, so I need all the space I can get.
> 
> Thanks for all of the excellent help so far!
> 
> Don A. Gilmore
> Kansas City
> 

Don,

That's quite fascinating.

Are you concerned about the 600W of heat drying out the piano wood? I 
know some pianos have humidifiers inside them so it seems like a 
potential issue.

-Jeff



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