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

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 159000

Article: 159000
Subject: Re: Advice to a newbie
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 3 Jun 2016 14:42:47 -0500
Links: << >>  << T >>  << A >>
On 6/3/2016 2:29 PM, Rick C. Hodgin wrote:
> On Friday, June 3, 2016 at 3:02:24 PM UTC-4, Cecil Bayona wrote:
>> On 6/3/2016 1:09 PM, Rick C. Hodgin wrote:
>>> On Friday, June 3, 2016 at 12:00:52 PM UTC-4, Rick C. Hodgin wrote:
>>> Received:
>>>     http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/LatticeXP2Brevia2DevelopmentKit.aspx
>>>
>>> I am wanting to apply logic to this LED process, but I'm thinking there may
>>> be some analog issues that I need to consider.  For example, when a button
>>> on the board is clicked, I assume there is some jitter time, such that if it
>>> were sampled at a MHz frequency it would record jittery on/off signals for
>>> a ms or two until the contact was made solid, and the same for releasing.
>>>
>>> As such, any logic which samples the buttons, for example, must include
>>> things like identifying the first high signal, and then either sampling
>>> the high/low ratio over periods of time to determine if it's still high
>>> or low, and then using that value after the sampling period has expired,
>>> or wait until the high signal persists solidly for something like 10ms,
>>> and then consider that to be a single press event, and then wait for it
>>> to go low again for something like 10ms before concluding it is actually
>>> a release event.
>>
>> I like that board, you can implement simple CPUs in it for a low cost.
>>
>> This is a link to a video of FPGAs, this one is lesson 1, on lesson 2
>> they take a button and debounce it, the purpose of the project is to
>> count a series of pulses on the LED based on pushing a button.
>>
>> --
>> Cecil - k5nwa
>
> Specs:
>
>     http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735
>
> In looking at the specs, it shows that all five momentary push buttons
> are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not,
> pin 55).
>
> Awesome.  Should make it easier.
>
> What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb).  I assume
> output enable and write enable?  But what is CS?  Some kind of strobe?
> Do the address and data pins go high, and write goes high, and then
> it's strobed before it actually writes?  Or address pins go high, and
> then output goes high, and then it's strobed before data pins are
> ready?  Or does CS signal when the operation is complete after OE or
> WE go high?
>
> Or are they something else entirely? :-)
>
> Best regards,
> Rick C. Hodgin
>
I would not be sure that applies to any application but is what the demo 
does, as they do not know what you will end up doing with the I/O pins.

-- 
Cecil - k5nwa

Article: 159001
Subject: Re: Advice to a newbie
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 3 Jun 2016 12:46:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote:
> On 6/3/2016 2:29 PM, Rick C. Hodgin wrote:
> > Specs:
> >
> >     http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735
> >
> > In looking at the specs, it shows that all five momentary push buttons
> > are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not,
> > pin 55).
> >
> > Awesome.  Should make it easier.
> >
> > What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb).  I assume
> > output enable and write enable?  But what is CS?  Some kind of strobe?
> > Do the address and data pins go high, and write goes high, and then
> > it's strobed before it actually writes?  Or address pins go high, and
> > then output goes high, and then it's strobed before data pins are
> > ready?  Or does CS signal when the operation is complete after OE or
> > WE go high?
> >
> > Or are they something else entirely? :-)
>
> I would not be sure that applies to any application but is what the demo 
> does, as they do not know what you will end up doing with the I/O pins.

I think it's chip select.  It looks like there are 17 address pins.  2^17
yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
could be thought of essentially as the 18th address pin?

I couldn't find the video with the lessons.  Do you have a link, Cecil?

Best regards,
Rick C. Hodgin

Article: 159002
Subject: Re: Advice to a newbie
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 3 Jun 2016 17:01:37 -0500
Links: << >>  << T >>  << A >>
On 6/3/2016 2:46 PM, Rick C. Hodgin wrote:
> On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote:
>> On 6/3/2016 2:29 PM, Rick C. Hodgin wrote:
>>> Specs:
>>>
>>>     http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735
>>>
>>> In looking at the specs, it shows that all five momentary push buttons
>>> are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not,
>>> pin 55).
>>>
>>> Awesome.  Should make it easier.
>>>
>>> What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb).  I assume
>>> output enable and write enable?  But what is CS?  Some kind of strobe?
>>> Do the address and data pins go high, and write goes high, and then
>>> it's strobed before it actually writes?  Or address pins go high, and
>>> then output goes high, and then it's strobed before data pins are
>>> ready?  Or does CS signal when the operation is complete after OE or
>>> WE go high?
>>>
>>> Or are they something else entirely? :-)
>>
>> I would not be sure that applies to any application but is what the demo
>> does, as they do not know what you will end up doing with the I/O pins.
>
> I think it's chip select.  It looks like there are 17 address pins.  2^17
> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
> could be thought of essentially as the 18th address pin?
>
> I couldn't find the video with the lessons.  Do you have a link, Cecil?
>
> Best regards,
> Rick C. Hodgin
>

Sorry, I forgot to add the link, but mind you the lesson is not for the 
Lattice board, but it's in VHDL which can be used with any board.

Lesson 2 has the implementation including debouncing of buttons, and a 
state machine.

<  https://www.youtube.com/watch?v=pDE2qenDXKQ  > Lesson 1	Basics
<  https://www.youtube.com/watch?v=uhxTgUSZvYE  > Lesson 2	Button 
Debouncer, State Machine
<  https://www.youtube.com/watch?v=yoytRxOjA-A  > Lesson 3	Oscilloscope, 
VGA output

-- 
Cecil - k5nwa

Article: 159003
Subject: Re: Advice to a newbie
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Fri, 3 Jun 2016 19:27:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 3, 2016 at 6:01:44 PM UTC-4, Cecil Bayona wrote:
> On 6/3/2016 2:46 PM, Rick C. Hodgin wrote:
> > On Friday, June 3, 2016 at 3:42:54 PM UTC-4, Cecil Bayona wrote:
> >> On 6/3/2016 2:29 PM, Rick C. Hodgin wrote:
> >>> Specs:
> >>>
> >>>     http://www.latticesemi.com/~/media/LatticeSemi/Documents/UserManuals/JL/LatticeXP2Brevia2DevelopmentKitUsersGuide.PDF?document_id=43735
> >>>
> >>> In looking at the specs, it shows that all five momentary push buttons
> >>> are already debounced, and 3 of the 4 DIP switches are (4 to 5 is not,
> >>> pin 55).
> >>>
> >>> Awesome.  Should make it easier.
> >>>
> >>> What are pins 142, 143, 144 (SRAM_CSb, SRAM_OEb, SRAM_WEb).  I assume
> >>> output enable and write enable?  But what is CS?  Some kind of strobe?
> >>> Do the address and data pins go high, and write goes high, and then
> >>> it's strobed before it actually writes?  Or address pins go high, and
> >>> then output goes high, and then it's strobed before data pins are
> >>> ready?  Or does CS signal when the operation is complete after OE or
> >>> WE go high?
> >>>
> >>> Or are they something else entirely? :-)
> >>
> >> I would not be sure that applies to any application but is what the demo
> >> does, as they do not know what you will end up doing with the I/O pins.
> >
> > I think it's chip select.  It looks like there are 17 address pins.  2^17
> > yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
> > be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
> > specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
> > could be thought of essentially as the 18th address pin?
> >
> > I couldn't find the video with the lessons.  Do you have a link, Cecil?
> >
> > Best regards,
> > Rick C. Hodgin
> >
> 
> Sorry, I forgot to add the link, but mind you the lesson is not for the 
> Lattice board, but it's in VHDL which can be used with any board.
> 
> Lesson 2 has the implementation including debouncing of buttons, and a 
> state machine.
> 
> <  https://www.youtube.com/watch?v=pDE2qenDXKQ  > Lesson 1	Basics
> <  https://www.youtube.com/watch?v=uhxTgUSZvYE  > Lesson 2	Button 
> Debouncer, State Machine
> <  https://www.youtube.com/watch?v=yoytRxOjA-A  > Lesson 3	Oscilloscope, 
> VGA output

I was able to go through this tonight.  This type of design is very
similar to what I plan for my Logician software:

    http://blog.bastelhalde.de/?p=678

I modified it so that the input buttons also map to additional LEDs,
one each for the four inputs, to signal when they are pressed.  But,
I could not figure out how to do it without going through a dual
inverter sequence.  When I pulled the signal directly from the input
pin, it would synthesize without error, but it would not illuminate
the LED.  I had to route it through the first inverter, then the second,
and I'm sure about why that is.

I'd like to begin working with timing and go through the stages to
get a 640x480 VGA output working with an 8x6 font.  Then, get a second
Brevia2 to drive the VGA as a stand-alone hardware device communicating
graphics updates over a simple protocol, allowing for dual-ported memory
writes (one to SRAM, one to Video-RAM).

Best regards,
Rick C. Hodgin

Article: 159004
Subject: Re: Advice to a newbie
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 04 Jun 2016 12:41:31 +0100 (BST)
Links: << >>  << T >>  << A >>
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> I think it's chip select.  It looks like there are 17 address pins.  2^17
> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
> could be thought of essentially as the 18th address pin?

CS is chip select.  It's typically connected to the rest of your address
decode logic: when you know you're talking to this chip and not something
else, assert CS.

However this is likely to be asynchronous SRAM, so the timing of CS and OE or
WE set up the read or write cycle.  I don't know the chip they use, but this
is the datasheet for a traditional 'old fashioned' SRAM:
http://6502.org/users/alexis/62256.pdf
- see page 8.

Since there isn't a clock going to the SRAM, you need to generate a cycle
that meets the timing diagram from the chip you have.  That means asserting
signals in the right order and waiting the right length of time before you
latch in any read data.  Since the SRAM has no maximum time for an access
cycle, you can just take it nice and slow by padding extra cycles in
whatever clock you happen to use, and it should be fine, but you do still
need to obey the right sequence.

Theo

Article: 159005
Subject: Re: Advice to a newbie
From: Marko Zec <zec@fer.hr>
Date: Sat, 4 Jun 2016 13:17:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>> I think it's chip select.  It looks like there are 17 address pins.  2^17
>> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
>> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
>> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
>> could be thought of essentially as the 18th address pin?
> 
> CS is chip select.  It's typically connected to the rest of your address
> decode logic: when you know you're talking to this chip and not something
> else, assert CS.
> 
> However this is likely to be asynchronous SRAM, so the timing of CS and OE or
> WE set up the read or write cycle.  I don't know the chip they use, but this
> is the datasheet for a traditional 'old fashioned' SRAM:
> http://6502.org/users/alexis/62256.pdf
> - see page 8.
> 
> Since there isn't a clock going to the SRAM, you need to generate a cycle
> that meets the timing diagram from the chip you have.  That means asserting
> signals in the right order and waiting the right length of time before you
> latch in any read data.  Since the SRAM has no maximum time for an access
> cycle, you can just take it nice and slow by padding extra cycles in
> whatever clock you happen to use, and it should be fine, but you do still
> need to obey the right sequence.

I think the particular SRAM chip on the Lattice Brevia 2 board is of the
true static kind.  However, there are also certain pseudo-SRAM chips
out there, i.e. DRAMs disguised behind an asynchronous, supposedly
SRAM-compatible interface, which require CS to be deasserted every
15 us or so, in order to trigger DRAM's internal auto-refresh cycles.
So don't take it for granted that CS is just an old-school chip select
signal - it may be much more than that, and only digging into the
datasheet of the particular chip can reveal its CS signal's true nature.

Marko


Article: 159006
Subject: Re: Advice to a newbie
From: Cecil Bayona <cbayona@cbayona.com>
Date: Sat, 4 Jun 2016 10:45:08 -0500
Links: << >>  << T >>  << A >>
On 6/4/2016 8:17 AM, Marko Zec wrote:
> Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
>> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>>> I think it's chip select.  It looks like there are 17 address pins.  2^17
>>> yields 128 KB.  The data reads/writes are 8-bits each, so I presume I will
>>> be reading/writing 8 bits at that byte-address.  2^17 * 8 = 1 MBit.  The
>>> specs say it has 2 MBit of SRAM, so I assume CS means chip select, and
>>> could be thought of essentially as the 18th address pin?
>>
>> CS is chip select.  It's typically connected to the rest of your address
>> decode logic: when you know you're talking to this chip and not something
>> else, assert CS.
>>
>> However this is likely to be asynchronous SRAM, so the timing of CS and OE or
>> WE set up the read or write cycle.  I don't know the chip they use, but this
>> is the datasheet for a traditional 'old fashioned' SRAM:
>> http://6502.org/users/alexis/62256.pdf
>> - see page 8.
>>
>> Since there isn't a clock going to the SRAM, you need to generate a cycle
>> that meets the timing diagram from the chip you have.  That means asserting
>> signals in the right order and waiting the right length of time before you
>> latch in any read data.  Since the SRAM has no maximum time for an access
>> cycle, you can just take it nice and slow by padding extra cycles in
>> whatever clock you happen to use, and it should be fine, but you do still
>> need to obey the right sequence.
>
> I think the particular SRAM chip on the Lattice Brevia 2 board is of the
> true static kind.  However, there are also certain pseudo-SRAM chips
> out there, i.e. DRAMs disguised behind an asynchronous, supposedly
> SRAM-compatible interface, which require CS to be deasserted every
> 15 us or so, in order to trigger DRAM's internal auto-refresh cycles.
> So don't take it for granted that CS is just an old-school chip select
> signal - it may be much more than that, and only digging into the
> datasheet of the particular chip can reveal its CS signal's true nature.
>
> Marko
>
15 ns access time true static RAM chip.
< 
http://www.idt.com/products/memory-logic/srams/asynchronous-srams/71v124-33v-128k-x-8-asynchronous-static-ram-center-power-ground-pinout 
  >

The board is not bad in terms of price ($43 at Mouser) for what you get, 
instant on, 128KB external RAM, 12 18x18 multipliers, 3 DSP Blocks, 
400MHz FPGA core.

Another slightly more expensive but with some extra features is the 
Papilio Duo for about $88 with Spartan 6 FPGA, 512 KB RAM (Optionally 
2MB RAM), 8MB FLASH, that is bytes not bits, Arduino UNO with interface 
connectors, and a FPGA chip with 18 DSPslices.

Too many toys, but not enough time.
-- 
Cecil - k5nwa

Article: 159007
Subject: Re: Advice to a newbie
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 4 Jun 2016 17:04:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, June 3, 2016 at 10:27:07 PM UTC-4, Rick C. Hodgin wrote:
> I was able to go through this tonight.  This type of design is very
> similar to what I plan for my Logician software:
> 
>     http://blog.bastelhalde.de/?p=678
> 
> I modified it so that the input buttons also map to additional LEDs,
> one each for the four inputs, to signal when they are pressed.  But,
> I could not figure out how to do it without going through a dual
> inverter sequence.  When I pulled the signal directly from the input
> pin, it would synthesize without error, but it would not illuminate
> the LED.  I had to route it through the first inverter, then the second,
> and I'm sure about why that is.
> 
> I'd like to begin working with timing and go through the stages to
> get a 640x480 VGA output working with an 8x6 font.  Then, get a second
> Brevia2 to drive the VGA as a stand-alone hardware device communicating
> graphics updates over a simple protocol, allowing for dual-ported memory
> writes (one to SRAM, one to Video-RAM).

I am presently hampered (to the point of significant failure) by knowing
what I want to do, but not knowing the syntax to do it in Verilog (or VHDL).
I'm tempted to begin working on my Logician tool so I can create its UI to
operate the way I think. :-)

Best regards,
Rick C. Hodgin

Article: 159008
Subject: comparing hardware architecture
From: Marvin L <user123random@gmail.com>
Date: Sun, 5 Jun 2016 06:34:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
Currently, I have two algorithm to consider.

one using FFT, one using DCT
the DCT is using NEDA
for FFT, I am not quite sure which one to use

Do you guys have any suggestions for FFT and DCT regarding implementation ?
I am now reading on NEDA and Radix.

Besides, how would you guys implement DoG (Difference of Gaussian) in hardware ?

Thanks !

Article: 159009
Subject: comparing hardware architecture
From: Marvin L <user123random@gmail.com>
Date: Sun, 5 Jun 2016 06:34:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
Currently, I have two algorithm to consider.

one using FFT, one using DCT
the DCT is using NEDA
for FFT, I am not quite sure which one to use

Do you guys have any suggestions for FFT and DCT regarding implementation ?
I am now reading on NEDA and Radix.

Besides, how would you guys implement DoG (Difference of Gaussian) in hardware ?

Thanks !

Article: 159010
Subject: Re: comparing hardware architecture
From: rickman <gnuarm@gmail.com>
Date: Thu, 9 Jun 2016 23:39:22 -0400
Links: << >>  << T >>  << A >>
On 6/5/2016 9:34 AM, Marvin L wrote:
> Currently, I have two algorithm to consider.
>
> one using FFT, one using DCT
> the DCT is using NEDA
> for FFT, I am not quite sure which one to use
>
> Do you guys have any suggestions for FFT and DCT regarding implementation ?
> I am now reading on NEDA and Radix.
>
> Besides, how would you guys implement DoG (Difference of Gaussian) in hardware ?

Do you have any requirements for these functions other than "they need 
to be implemented"?  What data throughput do you require?  What data 
representation do you need use?  What type of device will it be 
implemented on?

You are considering algorithms which is fine, but the choice of 
algorithm is often impacted by the requirements.

-- 

Rick C

Article: 159011
Subject: Re: Advice to a newbie
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 10 Jun 2016 13:05:24 -0500
Links: << >>  << T >>  << A >>
On 5/27/2016 1:00 PM, Cecil Bayona wrote:
> I a retired person with limited resources and I've always been
> interested in CPU design, so now that I have time I wanted to give it a
> go using FPGAs to design simple CPUs.
>
> I would like some advice on several topics, one being which HDL language
> to learn first, although Verilog seems simpler I've read articles that
> encourages beginners to start with VHDL, although it seems more wordy, I
> believe it will help eliminate more dumb mistakes so I'm leaning that
> way. What is your advice?
>
> Another is which logic families/companies make products that are
> inexpensive and have good features useful in creating CPUs and DSP type
> products as I also am interested in Software Defined Radios.
>
> I have purchase for a starter kit a Lattice Brevia2 kit as it was
> inexpensive and has low power consumption, so I assume will be easier to
> use in the beginning. It's a simple device with 5K LUTs which seems to
> be enough for some of the simple processors that I'm interested in to
> start with, CPUs such as the J1 for starters. From some time back I've
> have a Xilinx Spartan 3 Started kit that I have not used, I plan to use
> it later for more complex designs.
>
> Your opinions and advice is welcomed.

I have been doing a lot of research and have come up with a plan.

I have already implemented the ep8080, a high efficiency I8080 CPU a 
processor that I worked with for many years in my line of work, we 
quickly converted to the I8085 since it's hardware was more efficient, 
and could run at a much higher clock rate. In any case I'm ready to move on.

After some deliberation and tool searching, I have decided to implement 
C H Tings ep32 processor as the next CPU, there are several reasons why, 
some are below;

1. It's a simple tested 32 bit Forth CPU, something I desire, not a work 
in progress.
2. It's implemented on a Brevia2 board, which I already own.
3. I have quite a bit of documentation on it, supplied by C H Ting, and 
it's quite good.
4. I have a Forth assembler, and compiler that generates machine code, 
with documentation.
5. I have the source to a resident eForth compiler for the CPU, with 
documentation.
6. It is written in VHDL which is the first language I want to learn.
7. I has room in the opcodes to add many new instructions.
8. It can pack multiple instructions in an instruction word to make it 
more efficient.
9. Large address space so I could use the external RAM to add program space.

So there are a lot of advantages in the design with room for me to add 
instructions, and make architectural changes. I will start trying to get 
it working this evening after I get all my day activities all done. I've 
setup a virtual W7 partition with VMware Player 12, with all the 
development software and it all seems to work just fine, including the 
serial port working fine at 115K baud rate.

The ep16 is next in the short future after that then the J1, and maybe 
the PDP11, and who knows what else. Before I move to some of these 
processors I need to become more familiar with VHDL as some of these 
CPUs such as the PDP11 with be implemented from scratch.

Let the fun begin.

-- 
Cecil - k5nwa

Article: 159012
Subject: Re: Advice to a newbie
From: rickman <gnuarm@gmail.com>
Date: Fri, 10 Jun 2016 16:54:48 -0400
Links: << >>  << T >>  << A >>
On 6/10/2016 2:05 PM, Cecil Bayona wrote:
>
> The ep16 is next in the short future after that then the J1, and maybe
> the PDP11, and who knows what else. Before I move to some of these
> processors I need to become more familiar with VHDL as some of these
> CPUs such as the PDP11 with be implemented from scratch.
>
> Let the fun begin.

VHDL is not so hard.  Just learn how to infer a register and instantiate 
a module and you are practically done.  The rest is just logic which can 
be added to the register code or inferred separately.  Life will be 
easier if you enable VHDL-2008 in your tools and use those features.

If you have any questions you can ask here or maybe comp.lang.vhdl would 
be good too.

-- 

Rick C

Article: 159013
Subject: Re: Advice to a newbie
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 10 Jun 2016 16:11:09 -0500
Links: << >>  << T >>  << A >>
On 6/10/2016 3:54 PM, rickman wrote:
> On 6/10/2016 2:05 PM, Cecil Bayona wrote:
>>
>> The ep16 is next in the short future after that then the J1, and maybe
>> the PDP11, and who knows what else. Before I move to some of these
>> processors I need to become more familiar with VHDL as some of these
>> CPUs such as the PDP11 with be implemented from scratch.
>>
>> Let the fun begin.
>
> VHDL is not so hard.  Just learn how to infer a register and instantiate
> a module and you are practically done.  The rest is just logic which can
> be added to the register code or inferred separately.  Life will be
> easier if you enable VHDL-2008 in your tools and use those features.
>
> If you have any questions you can ask here or maybe comp.lang.vhdl would
> be good too.
>
I will today be starting on the ep32 CPU, later when I get back from 
running errands.

I setup a virtual Windows 7 PC and have Lattice Diamond and other tools 
loaded and working. I even have the serial port on the Brevia2 board 
running at 115K baud rate so all is ready. I posted about it on this 
topic earlier today.

Thanks for all the advice, and I will post in the c.l.vhdl when I have 
an issue with not understanding a feature of VHDL. So far looking at 
some books it all seems OK but a lot of details to remember.

-- 
Cecil - k5nwa

Article: 159014
Subject: Re: Advice to a newbie
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Fri, 10 Jun 2016 17:54:17 -0500
Links: << >>  << T >>  << A >>
On Fri, 10 Jun 2016 16:11:09 -0500, Cecil Bayona wrote:

> On 6/10/2016 3:54 PM, rickman wrote:
>> On 6/10/2016 2:05 PM, Cecil Bayona wrote:
>>>
>>> The ep16 is next in the short future after that then the J1, and maybe
>>> the PDP11, and who knows what else. Before I move to some of these
>>> processors I need to become more familiar with VHDL as some of these
>>> CPUs such as the PDP11 with be implemented from scratch.
>>>
>>> Let the fun begin.
>>
>> VHDL is not so hard.  Just learn how to infer a register and
>> instantiate a module and you are practically done.  The rest is just
>> logic which can be added to the register code or inferred separately. 
>> Life will be easier if you enable VHDL-2008 in your tools and use those
>> features.
>>
>> If you have any questions you can ask here or maybe comp.lang.vhdl
>> would be good too.
>>
> I will today be starting on the ep32 CPU, later when I get back from
> running errands.
> 
> I setup a virtual Windows 7 PC and have Lattice Diamond and other tools
> loaded and working. I even have the serial port on the Brevia2 board
> running at 115K baud rate so all is ready. I posted about it on this
> topic earlier today.
> 
> Thanks for all the advice, and I will post in the c.l.vhdl when I have
> an issue with not understanding a feature of VHDL. So far looking at
> some books it all seems OK but a lot of details to remember.

I don't even try to remember all the details of C++ (which is my main 
computer language).  I just remember what's possible, and enough terms 
that I can use a book with a good index, or a site with a good search 
engine, and look up what I need to know.

Then I use it, then I forget it again.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Article: 159015
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Cecil Bayona <cbayona@cbayona.com>
Date: Fri, 10 Jun 2016 20:36:08 -0500
Links: << >>  << T >>  << A >>
On 5/13/2011 7:34 AM, wzab wrote:
> Hi,
>
> I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html
> I'd like to use it to implement simple non-time critical control and
> debugging layer
> in my FPGA based DSP system.
> However to accomplish it I need to add possibility of interactive work
> via console
> connected either by UART or by JTAG.
> Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz
> with possibility to interactively define new words and execute them?
> --
> TIA & Regards,
> WZab
>
I have not done it, I'm just starting using FPGA, however the J1 is on 
my short list of processors to implement. I'm in the process of learning 
VHDL so I will be doing my own take using VHDL instead of Verilog. Once 
up and running then my plans is to do upgrades to it.

Sorry if this doesn't help you, but I'm heading in that general 
direction. Currently my plans are to implement the ep32 and the ep16 
first since I have decent documentation and development software for 
those two CPUs.

-- 
Cecil - k5nwa

Article: 159016
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Fri, 10 Jun 2016 22:06:36 -0400
Links: << >>  << T >>  << A >>
On 6/10/2016 9:36 PM, Cecil Bayona wrote:
> On 5/13/2011 7:34 AM, wzab wrote:
>> Hi,
>>
>> I'm very impressed with a J1 forth processor:
>> http://excamera.com/sphinx/fpga-j1.html
>> I'd like to use it to implement simple non-time critical control and
>> debugging layer
>> in my FPGA based DSP system.
>> However to accomplish it I need to add possibility of interactive work
>> via console
>> connected either by UART or by JTAG.
>> Has anybody tried to extend the J1 published in
>> http://excamera.com/files/j1demo.tar.gz
>> with possibility to interactively define new words and execute them?
>> --
>> TIA & Regards,
>> WZab
>>
> I have not done it, I'm just starting using FPGA, however the J1 is on
> my short list of processors to implement. I'm in the process of learning
> VHDL so I will be doing my own take using VHDL instead of Verilog. Once
> up and running then my plans is to do upgrades to it.
>
> Sorry if this doesn't help you, but I'm heading in that general
> direction. Currently my plans are to implement the ep32 and the ep16
> first since I have decent documentation and development software for
> those two CPUs.

Seems you replied to a rather old post.  I expect wzab's project is 
quite done at this point.

I'm not sure what he meant by "interactively define new words and 
execute them".  Someone else, maybe in the Forth group, wanted to do 
something like that where the basic instruction set could be extended by 
compiling Forth.

I have worked with microcoded machines and the only way I can think that 
would be done would be through a special set of primitives that were 
specific to the CPU rather than typical Forth primitives.  You can think 
of Forth as the instruction set for a stack machine.  Inventing new 
primitives would essentially mean writing new microcode rather than 
using the existing primitives.  I think that would be rather a lot of 
Forth to generate that new microcode from Forth primitives.  I suppose 
it is doable though.  Maybe I just haven't been able to simplify the 
problem enough to see the solution.

-- 

Rick C

Article: 159017
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Fri, 10 Jun 2016 22:31:40 -0400
Links: << >>  << T >>  << A >>
On 6/10/2016 10:06 PM, rickman wrote:
> On 6/10/2016 9:36 PM, Cecil Bayona wrote:
>> On 5/13/2011 7:34 AM, wzab wrote:
>>> Hi,
>>>
>>> I'm very impressed with a J1 forth processor:
>>> http://excamera.com/sphinx/fpga-j1.html
>>> I'd like to use it to implement simple non-time critical control and
>>> debugging layer
>>> in my FPGA based DSP system.
>>> However to accomplish it I need to add possibility of interactive work
>>> via console
>>> connected either by UART or by JTAG.
>>> Has anybody tried to extend the J1 published in
>>> http://excamera.com/files/j1demo.tar.gz
>>> with possibility to interactively define new words and execute them?
>>> --
>>> TIA & Regards,
>>> WZab
>>>
>> I have not done it, I'm just starting using FPGA, however the J1 is on
>> my short list of processors to implement. I'm in the process of learning
>> VHDL so I will be doing my own take using VHDL instead of Verilog. Once
>> up and running then my plans is to do upgrades to it.
>>
>> Sorry if this doesn't help you, but I'm heading in that general
>> direction. Currently my plans are to implement the ep32 and the ep16
>> first since I have decent documentation and development software for
>> those two CPUs.
>
> Seems you replied to a rather old post.  I expect wzab's project is
> quite done at this point.
>
> I'm not sure what he meant by "interactively define new words and
> execute them".  Someone else, maybe in the Forth group, wanted to do
> something like that where the basic instruction set could be extended by
> compiling Forth.
>
> I have worked with microcoded machines and the only way I can think that
> would be done would be through a special set of primitives that were
> specific to the CPU rather than typical Forth primitives.  You can think
> of Forth as the instruction set for a stack machine.  Inventing new
> primitives would essentially mean writing new microcode rather than
> using the existing primitives.  I think that would be rather a lot of
> Forth to generate that new microcode from Forth primitives.  I suppose
> it is doable though.  Maybe I just haven't been able to simplify the
> problem enough to see the solution.

Just to clarify, a microcoded machine has fields or individual bits 
which control... well, control points.  The CPU has many register 
enables, multiplexers and other functions that need to controlled.  The 
signals that do all this are "control points".  A microcoded machine 
generates those control points either through a 1 to 1 mapping of 
microcode bits to control bits (a very wide instruction word) or control 
points that are mutually exclusive can be encoded into a field which is 
decoded by logic to generate the control points saving microcode memory. 
  Even if the encoded control points aren't mutually exclusive by the 
hardware design, they will be if encoded.

The primitives for such a microcoded machine would be the control 
points.  In Forth a word could be defined for each one and one for each 
of the possible selections in an encoded field (hopefully checking if 
any of the other mutually exclusive words had been used already in this 
instruction).  Not entirely unlike assembly language done in Forth each 
field could be entered building up the instruction until a finishing 
word uses that instruction and inserts it into the microcode memory.

Maybe this is not so much more complex than standard assembly language, 
certainly there aren't all the addressing modes, etc.  But I would have 
a hard time figuring out how to map existing Forth primitives to 
microcode to define new instructions/new Forth primitives.  Simply 
inserting the same sequence of microcode words as exist in the 
definitions for the Forth primitives would not be terribly useful since 
there likely would be very little or even no overhead in using Forth 
primitives.

Being able to define new instructions that do new or different things 
would not be easy to specify in standard Forth primitives.  This would 
need to be done using microcode primitives.

-- 

Rick C

Article: 159018
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Jecel <jecel@merlintec.com>
Date: Mon, 13 Jun 2016 09:52:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
Rickman,

> I'm not sure what he meant by "interactively define new words and 
> execute them".  Someone else, maybe in the Forth group, wanted to do 
> something like that where the basic instruction set could be extended by 
> compiling Forth.

You are overthinking things. What he meant was that he wanted a native J1
Forth system instead of the cross Forth system most projects were using.
So you would connect a terminal to the FPGA board and would see an "Ok"
prompt and then you could define new words by typing ": name ...." on
the terminal. You would also be able to try simple expressions like
"3 4 + ." and see immediately what they do.

With cross development you type in your program in some editor on your
PC, run the compiler and get a bunch of bits to be loaded into the FPGA
board. You turn on the FPGA board and see if it worked or not. If not,
you got back to the editor on your PC and start the whole cycle again.
This works, but it is not how Forth was meant to be used.

-- Jecel

Article: 159019
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Mon, 13 Jun 2016 15:21:19 -0400
Links: << >>  << T >>  << A >>
On 6/13/2016 12:52 PM, Jecel wrote:
> Rickman,
>
>> I'm not sure what he meant by "interactively define new words and
>> execute them".  Someone else, maybe in the Forth group, wanted to do
>> something like that where the basic instruction set could be extended by
>> compiling Forth.
>
> You are overthinking things. What he meant was that he wanted a native J1
> Forth system instead of the cross Forth system most projects were using.
> So you would connect a terminal to the FPGA board and would see an "Ok"
> prompt and then you could define new words by typing ": name ...." on
> the terminal. You would also be able to try simple expressions like
> "3 4 + ." and see immediately what they do.
>
> With cross development you type in your program in some editor on your
> PC, run the compiler and get a bunch of bits to be loaded into the FPGA
> board. You turn on the FPGA board and see if it worked or not. If not,
> you got back to the editor on your PC and start the whole cycle again.
> This works, but it is not how Forth was meant to be used.

A target hosted Forth has it's advantages, but I still type my source 
into an editor on the PC and compile by downloading to the target rather 
than loading into a Forth crosscompiler which downloads it for me.  Not 
sure there is a huge advantage either way.  They seem pretty similar to 
me including the need to hit the reset button when I screw up bad enough.

You make it sound like the edit, compile, test loop is somehow much less 
useful when using a PC.  I got rid of my ADM-3A a long time ago.

-- 

Rick C

Article: 159020
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Jecel <jecel@merlintec.com>
Date: Tue, 14 Jun 2016 12:52:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote:
> You make it sound like the edit, compile, test loop is somehow much less 
> useful when using a PC.  I got rid of my ADM-3A a long time ago.

Compare developing a game in Basic on a Commodore 64 with creating the
same game on a PC, using a Basic-to-6502 compiler and downloading it to
the C64 to see if it works. Development is faster in the first option
while the resulting game will be faster in the second option.

What I am saying is that I don't like edit/compile/test loops but
prefer interpreted systems (or those that do a good job of pretending
to be interpreted - see Smalltalks with JIT compilation).

You are free to prefer compiled systems (most people do) but wzab seems
to have the same taste as me and was asking for an option to develop
interactively on the J1 processor itself.

-- Jecel

Article: 159021
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Tue, 14 Jun 2016 16:16:04 -0400
Links: << >>  << T >>  << A >>
On 6/14/2016 3:52 PM, Jecel wrote:
> On Monday, June 13, 2016 at 4:21:21 PM UTC-3, Rickman wrote:
>> You make it sound like the edit, compile, test loop is somehow much less
>> useful when using a PC.  I got rid of my ADM-3A a long time ago.
>
> Compare developing a game in Basic on a Commodore 64 with creating the
> same game on a PC, using a Basic-to-6502 compiler and downloading it to
> the C64 to see if it works. Development is faster in the first option
> while the resulting game will be faster in the second option.

That is not at all clear to me.  Your example seems to be compiling 
native on one type of PC vs. cross compiling on another and transferring 
the executable.  I don't expect to have anything like mass storage on 
the target system, so the two options I have are using the PC for 
program storage or using the PC to cross compile.  I can download at 
nearly 1 Mbps today using the ubiquitous USB serial ports.  I don't 
perceive any difference in time of loading an executable vs. loading the 
program source.  Compile times are very fast as well.


> What I am saying is that I don't like edit/compile/test loops but
> prefer interpreted systems (or those that do a good job of pretending
> to be interpreted - see Smalltalks with JIT compilation).

You still have the loop, you think it is faster the way you are 
describing, but I use the same command line for testing.  I just use the 
PC as an editor.


> You are free to prefer compiled systems (most people do) but wzab seems
> to have the same taste as me and was asking for an option to develop
> interactively on the J1 processor itself.

That's fine if the J1 has facilities for the full development process. 
I can't remember the last time I used a target that was even close to 
being able to support a full development system other than the Raspberry 
Pi.  What sort of J1 hardware are you looking at?

-- 

Rick C

Article: 159022
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Jecel <jecel@merlintec.com>
Date: Wed, 15 Jun 2016 14:43:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote:
> > What I am saying is that I don't like edit/compile/test loops but
> > prefer interpreted systems (or those that do a good job of pretending
> > to be interpreted - see Smalltalks with JIT compilation).
> 
> You still have the loop, you think it is faster the way you are 
> describing, but I use the same command line for testing.  I just use the 
> PC as an editor.

"the same command line" might be the key to our differences. In the
native C64 Basic command line I can type something like

PRINT (MADD/4)+1

and see the result. In a cross compiling Basic I can't do that.

> > You are free to prefer compiled systems (most people do) but wzab seems
> > to have the same taste as me and was asking for an option to develop
> > interactively on the J1 processor itself.
> 
> That's fine if the J1 has facilities for the full development process. 
> I can't remember the last time I used a target that was even close to 
> being able to support a full development system other than the Raspberry 
> Pi.  What sort of J1 hardware are you looking at?

The J1 can't address much memory, so a native Forth is possible but would
be a tight fit.

You mentioned a lack of mass storage on the target device, but these days
you can easily have 64Kb of Flash or more.

In any case, my own SiliconSqueak is way larger than the J1 and is meant
for boards with more resources, though not necessarily as large as a
Raspberry Pi.

-- Jecel

Article: 159023
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: rickman <gnuarm@gmail.com>
Date: Wed, 15 Jun 2016 18:13:59 -0400
Links: << >>  << T >>  << A >>
On 6/15/2016 5:43 PM, Jecel wrote:
> On Tuesday, June 14, 2016 at 5:16:08 PM UTC-3, Rickman wrote:
>>> What I am saying is that I don't like edit/compile/test loops but
>>> prefer interpreted systems (or those that do a good job of pretending
>>> to be interpreted - see Smalltalks with JIT compilation).
>>
>> You still have the loop, you think it is faster the way you are
>> describing, but I use the same command line for testing.  I just use the
>> PC as an editor.
>
> "the same command line" might be the key to our differences. In the
> native C64 Basic command line I can type something like
>
> PRINT (MADD/4)+1
>
> and see the result. In a cross compiling Basic I can't do that.

There's the problem.  I'm using Forth.  I didn't know we were talking 
about BASIC.


>>> You are free to prefer compiled systems (most people do) but wzab seems
>>> to have the same taste as me and was asking for an option to develop
>>> interactively on the J1 processor itself.
>>
>> That's fine if the J1 has facilities for the full development process.
>> I can't remember the last time I used a target that was even close to
>> being able to support a full development system other than the Raspberry
>> Pi.  What sort of J1 hardware are you looking at?
>
> The J1 can't address much memory, so a native Forth is possible but would
> be a tight fit.

I don't recall the limitation, but I would expect it to be on the order 
of many KB.  Mecrisp is not so large and in fact, I'm pretty sure it has 
been ported to the J1.  I seem to recall this was done using an open 
source package (the only one I've ever heard of) that compiles to a bit 
stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth 
to this target making the entire effort open source.  I can't recall for 
sure, but I'm pretty sure the hardware is also open source.


> You mentioned a lack of mass storage on the target device, but these days
> you can easily have 64Kb of Flash or more.

64 kB of on target flash is not of much value for storing source.  You 
have virtually no tools for printing, copying, backup, etc.  I use a PC 
for all that.


> In any case, my own SiliconSqueak is way larger than the J1 and is meant
> for boards with more resources, though not necessarily as large as a
> Raspberry Pi.

You mean an FPGA board?  The rPi has a higher end ARM processor.

-- 

Rick C

Article: 159024
Subject: Re: J1 forth processor in FPGA - possibility of interactive work?
From: Jecel <jecel@merlintec.com>
Date: Thu, 16 Jun 2016 10:57:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote:
> On 6/15/2016 5:43 PM, Jecel wrote:
> > "the same command line" might be the key to our differences. In the
> > native C64 Basic command line I can type something like
> >
> > PRINT (MADD/4)+1
> >
> > and see the result. In a cross compiling Basic I can't do that.
> 
> There's the problem.  I'm using Forth.  I didn't know we were talking 
> about BASIC.

:-)

So we type

MADD @ 4 / 1 + .

instead. The point is that I don't have to first put that expression
in a colon definition, compile it, and then send it to the target
board to see the result.

> > The J1 can't address much memory, so a native Forth is possible but would
> > be a tight fit.
> 
> I don't recall the limitation, but I would expect it to be on the order 
> of many KB.

Let me check:

http://excamera.com/files/j1.pdf

"All target addresses - for call, jump and conditional branch
- are 13-bit. This limits code size to 8K words, or 16K bytes."

Data uses 15 bit byte addresses, but the top half of the memory
map is reserved for I/O. So was have 16KB in all to play with.

> Mecrisp is not so large and in fact, I'm pretty sure it has 
> been ported to the J1.  I seem to recall this was done using an open 
> source package (the only one I've ever heard of) that compiles to a bit 
> stream.  In a fit of enthusiasm I believe Matthias Koch ported his Forth 
> to this target making the entire effort open source.  I can't recall for 
> sure, but I'm pretty sure the hardware is also open source.

Ok, so the answer to the original question is "yes"? Good. I've had some
nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with
OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded
Forth that can be used interactively. Not only is token threading
really compact, but it can also be used on Harvard architecture chips
like the Atmel AVR8.

> > You mentioned a lack of mass storage on the target device, but these days
> > you can easily have 64Kb of Flash or more.
> 
> 64 kB of on target flash is not of much value for storing source.  You 
> have virtually no tools for printing, copying, backup, etc.  I use a PC 
> for all that.

Normally, I would agree. But for Forth or Basic (as in BasicStamp boards)
it might be enough. Most early microcomputers had 80KB floppy disks.

> > In any case, my own SiliconSqueak is way larger than the J1 and is meant
> > for boards with more resources, though not necessarily as large as a
> > Raspberry Pi.
> 
> You mean an FPGA board?  The rPi has a higher end ARM processor.

The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also
the case for some FPGA boards. And those with chips like Zynq have 
FPGAs and ARMs.

What I was saying was that I am also interested in FPGA boards with not
as much memory and with poorer I/O (VGA and PS/2, for example) than
the Pi.

-- Jecel



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

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