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 160000

Article: 160000
Subject: Re: glitching AND gate
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Mon, 8 May 2017 06:01:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

Am Sonntag, 23. April 2017 15:37:50 UTC+2 schrieb David Bridgham:
> And there's my question.  Will the AND gate implementation in an FPGA do
> that?  Or are LUTs odd enough that I can't depend on it?  If the answer
> is FPGA specific, I'm using an Artix 7 FPGA.

About the LUT itself a lot told you in this thread. 
But be aware that your verilog code will be optimized by synthesis tool. Usually synthesis tools don't care about glitch free result, so you need to ensure your final result is glitch free. 

regards Thomas

Article: 160001
Subject: Re: Lattice iCE40 UltraLite DIPSY - what happened?
From: "Michael Kellett" <nospam@invalid.com>
Date: tue, 9 may 2017 14:02:01 +0100
Links: << >>  << T >>  << A >>
rickman:
> On 5/7/2017 8:19 AM, Michael Kellett wrote:
>> rickman:
>>> I was digging around for info on the iCE40 UL and found info on the
>>> DIPSY from 2015 when it was breaking news.  Not sure how I missed
it,
>>
>>> but this is a very small unit with a very tiny FPGA (likely the
>> smallest
>>> FPGA package ever - 2 mm^2) and an LDO for the core power and of
>> course
>>> some connectors.
>>>
>>> I found a github page with various design details and an Indiegogo
>> page.
>>>   There I found a video from Lattice that says this unit along with
a
>>
>>> programming board (over 100 times larger) is sold for $5.  It looks
>> like
>>> they received 140% of their goal.  What I don't find is any way to
buy
>>
>>> this.  The video says to go to the lattice web site for more info,
but
>> I
>>> don't find even a mention there.
>>>
>>> Maybe that's why I missed this unit.  It may have sold a few copies
to
>>
>>> the original contributors and then been dropped.
>>>
>>> Anyone know anything about this?  The guy behind it is Antti Lukats
>> who
>>> has been seen here from time to time.
>>>
>>> --
>>>
>>> Rick C
>>
>> Antti still lives and breathes and hangs out a little on Farnell's
>> Element14 site.
>>
>> I think he is currently working for Trenz Electronics who  are at
>> www.trenz-electronic.de
> 
> Yes, I've seen signs of Antti in various places, but he never seems to

> be terribly thorough about documenting his work.  I just looked at the

> Gerbers for this design and there is a list of the files in a file
with 
> an EXTREP suffix as if that would be remotely obvious...  Then the
drill 
> file isn't listed.  After opening nearly all the possible files it 
> turned out to be the .txt file.  Go figure.
> 
> Anyway, now that I can see the Gerbers, the PCB design rules are 2/2
mil 
> trace/space (0.05 mm) and 6 mil drills (0.15 mm).  I've never made a 
> board like this before.  It will require professional assembly as well
I 
> expect.
> 
> Anyone hand built a prototype with 0.35 mm center uBGAs before?
> 
> While the Indiegogo page has a video from Lattice Semi saying you can

> buy assembled boards from them for $5, I see no trace.  It appears the

> $5 price gets you a PCB directly from Antti according to a home page 
> http://dipsy.cool
> 
> Hard to tell really.  Lots of hype and little real info.  I guess it's

> all there if you can find it and figure it out.  I just don't know
where 
> I can get PCBs with 2/2 design rules made.
> 
> -- 
> 
> Rick C

I've had very mixed results with hand build and, as it turned out not
professional enough build of Lattice's tiny FPGAs.
I've had really good results with the iCE5LP4k in 48pin QFP - it is a
little larger but fairly easy to hand work on senisble design rule
boards. I'm looking forward to the UP5K in the same package when Lattice
can actually supply any.

MK

Article: 160002
Subject: Re: Lattice iCE40 UltraLite DIPSY - what happened?
From: rickman <gnuarm@gmail.com>
Date: Tue, 9 May 2017 13:42:38 -0400
Links: << >>  << T >>  << A >>
On 5/9/2017 9:02 AM, Michael Kellett wrote:
> rickman:
>> On 5/7/2017 8:19 AM, Michael Kellett wrote:
>>> rickman:
>>>> I was digging around for info on the iCE40 UL and found info on the
>>>> DIPSY from 2015 when it was breaking news.  Not sure how I missed
> it,
>>>
>>>> but this is a very small unit with a very tiny FPGA (likely the
>>> smallest
>>>> FPGA package ever - 2 mm^2) and an LDO for the core power and of
>>> course
>>>> some connectors.
>>>>
>>>> I found a github page with various design details and an Indiegogo
>>> page.
>>>>   There I found a video from Lattice that says this unit along with
> a
>>>
>>>> programming board (over 100 times larger) is sold for $5.  It looks
>>> like
>>>> they received 140% of their goal.  What I don't find is any way to
> buy
>>>
>>>> this.  The video says to go to the lattice web site for more info,
> but
>>> I
>>>> don't find even a mention there.
>>>>
>>>> Maybe that's why I missed this unit.  It may have sold a few copies
> to
>>>
>>>> the original contributors and then been dropped.
>>>>
>>>> Anyone know anything about this?  The guy behind it is Antti Lukats
>>> who
>>>> has been seen here from time to time.
>>>>
>>>> --
>>>>
>>>> Rick C
>>>
>>> Antti still lives and breathes and hangs out a little on Farnell's
>>> Element14 site.
>>>
>>> I think he is currently working for Trenz Electronics who  are at
>>> www.trenz-electronic.de
>>
>> Yes, I've seen signs of Antti in various places, but he never seems to
>
>> be terribly thorough about documenting his work.  I just looked at the
>
>> Gerbers for this design and there is a list of the files in a file
> with
>> an EXTREP suffix as if that would be remotely obvious...  Then the
> drill
>> file isn't listed.  After opening nearly all the possible files it
>> turned out to be the .txt file.  Go figure.
>>
>> Anyway, now that I can see the Gerbers, the PCB design rules are 2/2
> mil
>> trace/space (0.05 mm) and 6 mil drills (0.15 mm).  I've never made a
>> board like this before.  It will require professional assembly as well
> I
>> expect.
>>
>> Anyone hand built a prototype with 0.35 mm center uBGAs before?
>>
>> While the Indiegogo page has a video from Lattice Semi saying you can
>
>> buy assembled boards from them for $5, I see no trace.  It appears the
>
>> $5 price gets you a PCB directly from Antti according to a home page
>> http://dipsy.cool
>>
>> Hard to tell really.  Lots of hype and little real info.  I guess it's
>
>> all there if you can find it and figure it out.  I just don't know
> where
>> I can get PCBs with 2/2 design rules made.
>>
>> --
>>
>> Rick C
>
> I've had very mixed results with hand build and, as it turned out not
> professional enough build of Lattice's tiny FPGAs.
> I've had really good results with the iCE5LP4k in 48pin QFP - it is a
> little larger but fairly easy to hand work on senisble design rule
> boards. I'm looking forward to the UP5K in the same package when Lattice
> can actually supply any.

I would *love* to use QFP/QFN packages, but I need an ultra lite part. 
The bulk of the power consumption will be the quiescent power and the UL 
parts are half the UP parts.

-- 

Rick C

Article: 160003
Subject: Re: Lattice iCE40 UltraLite DIPSY - what happened?
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 10 May 2017 13:47:42 -0500
Links: << >>  << T >>  << A >>
rickman wrote:

Then the drill
> file isn't listed.  After opening nearly all the possible files it
> turned out to be the .txt file.  Go figure.
> 
Protel and derivatives (Tango, Altium) have used .txt for the drill 
(Excellon) file for some time.
> Anyway, now that I can see the Gerbers, the PCB design rules are 2/2 mil
> trace/space (0.05 mm) and 6 mil drills (0.15 mm).  I've never made a
> board like this before.  It will require professional assembly as well I
> expect.
> 
> Anyone hand built a prototype with 0.35 mm center uBGAs before?
> 
Yikes!

Jon

Article: 160004
Subject: increment or decrement one of 16, 16-bit registers
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Wed, 10 May 2017 16:42:59 -0500
Links: << >>  << T >>  << A >>
I've been geeking out on the COSMAC 1802 lately -- it was the first 
processor that I owned all just for me, and that I wrote programs for (in 
machine code -- not assembly).

One of the features of this chip is that while the usual ALU is 8-bit and 
centered around memory fetches and the accumulator (which they call the 
'D' register), there's a 16 x 16-bit register file.  Any one of these 
registers can be incremented or decremented, either as an explicit 
instruction or as part of a fetch (basically, you can use any one of them 
as an index, and you can "fetch and increment").

How would you do this most effectively today?  How might it have been 
done back in the mid 1970's when RCA made the chip?  Would it make a 
difference if you were working with a CPLD, FPGA, or some ASIC where you 
were determined to minimize chip area?

I'm assuming that the original had one selectable increment/decrement 
unit that wrote back numbers to the registers, but I could see them 
implementing each register as a loadable counter -- I just don't have a 
good idea of what might use the least real estate.

Thanks.

-- 

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

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

Article: 160005
Subject: Re: increment or decrement one of 16, 16-bit registers
From: rickman <gnuarm@gmail.com>
Date: Wed, 10 May 2017 18:56:36 -0400
Links: << >>  << T >>  << A >>
On 5/10/2017 5:42 PM, Tim Wescott wrote:
> I've been geeking out on the COSMAC 1802 lately -- it was the first
> processor that I owned all just for me, and that I wrote programs for (in
> machine code -- not assembly).
>
> One of the features of this chip is that while the usual ALU is 8-bit and
> centered around memory fetches and the accumulator (which they call the
> 'D' register), there's a 16 x 16-bit register file.  Any one of these
> registers can be incremented or decremented, either as an explicit
> instruction or as part of a fetch (basically, you can use any one of them
> as an index, and you can "fetch and increment").
>
> How would you do this most effectively today?  How might it have been
> done back in the mid 1970's when RCA made the chip?  Would it make a
> difference if you were working with a CPLD, FPGA, or some ASIC where you
> were determined to minimize chip area?
>
> I'm assuming that the original had one selectable increment/decrement
> unit that wrote back numbers to the registers, but I could see them
> implementing each register as a loadable counter -- I just don't have a
> good idea of what might use the least real estate.

A counter is a register with an adder (although only needing half adders 
at each bit), so of course the incrementer will take up more logic than 
a register.

Depending on what functions can be done while the register is 
incrementing, they may use the ALU for all arithmetic operations.  Most 
of the earlier processors conserved logic by time sequencing operations 
within an instruction.  That's why some instructions take so many cycles 
to complete, it's shuffling data around internally.

If you provide some instructions with their descriptions and the cycle 
counts I bet I can tell you how much is done sequentially and how much 
is done in parallel.

-- 

Rick C

Article: 160006
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Wed, 10 May 2017 18:20:43 -0500
Links: << >>  << T >>  << A >>
On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:

> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>> processor that I owned all just for me, and that I wrote programs for
>> (in machine code -- not assembly).
>>
>> One of the features of this chip is that while the usual ALU is 8-bit
>> and centered around memory fetches and the accumulator (which they call
>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
>> these registers can be incremented or decremented, either as an
>> explicit instruction or as part of a fetch (basically, you can use any
>> one of them as an index, and you can "fetch and increment").
>>
>> How would you do this most effectively today?  How might it have been
>> done back in the mid 1970's when RCA made the chip?  Would it make a
>> difference if you were working with a CPLD, FPGA, or some ASIC where
>> you were determined to minimize chip area?
>>
>> I'm assuming that the original had one selectable increment/decrement
>> unit that wrote back numbers to the registers, but I could see them
>> implementing each register as a loadable counter -- I just don't have a
>> good idea of what might use the least real estate.
> 
> A counter is a register with an adder (although only needing half adders
> at each bit), so of course the incrementer will take up more logic than
> a register.
> 
> Depending on what functions can be done while the register is
> incrementing, they may use the ALU for all arithmetic operations.  Most
> of the earlier processors conserved logic by time sequencing operations
> within an instruction.  That's why some instructions take so many cycles
> to complete, it's shuffling data around internally.
> 
> If you provide some instructions with their descriptions and the cycle
> counts I bet I can tell you how much is done sequentially and how much
> is done in parallel.

There's a surprisingly large ecosystem of users for the processor -- I 
think because it was a popular, dirt-cheap hobby system, and now there's 
all these experienced digital-heads playing with their old toys.  There's 
even an "Olduino" project that marries a 1802 board with Arduino 
shields.  

The 1802 is how I got into doing deep-embedded systems (you can run an RC 
servo!  With a counter!  In Software!!!).  So I understand the enthusiasm 
because I share it.

Here's the Whole Damned User's Manual:

http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf

All instructions take 16 or 24 clock cycles, on a fixed program of two or 
three phases (_everything_ happens on 8-cycle boundaries).  A typical 
instruction would load the byte pointed to by register N into D, then 
increment the register pointed to by N.

I think you may be right about using the ALU for incrementing registers 
-- they don't show it that way in their logical diagram, but I just now 
realized that they never increment or decrement a register AND do an 
arithmetic operation in the same instruction.

-- 

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

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

Article: 160007
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Gabor <nospam@nospam.com>
Date: Wed, 10 May 2017 22:28:34 -0400
Links: << >>  << T >>  << A >>
On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
> 
>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>>> processor that I owned all just for me, and that I wrote programs for
>>> (in machine code -- not assembly).
>>>
>>> One of the features of this chip is that while the usual ALU is 8-bit
>>> and centered around memory fetches and the accumulator (which they call
>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
>>> these registers can be incremented or decremented, either as an
>>> explicit instruction or as part of a fetch (basically, you can use any
>>> one of them as an index, and you can "fetch and increment").
>>>
>>> How would you do this most effectively today?  How might it have been
>>> done back in the mid 1970's when RCA made the chip?  Would it make a
>>> difference if you were working with a CPLD, FPGA, or some ASIC where
>>> you were determined to minimize chip area?
>>>
>>> I'm assuming that the original had one selectable increment/decrement
>>> unit that wrote back numbers to the registers, but I could see them
>>> implementing each register as a loadable counter -- I just don't have a
>>> good idea of what might use the least real estate.
>>
>> A counter is a register with an adder (although only needing half adders
>> at each bit), so of course the incrementer will take up more logic than
>> a register.
>>
>> Depending on what functions can be done while the register is
>> incrementing, they may use the ALU for all arithmetic operations.  Most
>> of the earlier processors conserved logic by time sequencing operations
>> within an instruction.  That's why some instructions take so many cycles
>> to complete, it's shuffling data around internally.
>>
>> If you provide some instructions with their descriptions and the cycle
>> counts I bet I can tell you how much is done sequentially and how much
>> is done in parallel.
> 
> There's a surprisingly large ecosystem of users for the processor -- I
> think because it was a popular, dirt-cheap hobby system, and now there's
> all these experienced digital-heads playing with their old toys.  There's
> even an "Olduino" project that marries a 1802 board with Arduino
> shields.
> 
> The 1802 is how I got into doing deep-embedded systems (you can run an RC
> servo!  With a counter!  In Software!!!).  So I understand the enthusiasm
> because I share it.
> 
> Here's the Whole Damned User's Manual:
> 
> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
> 
> All instructions take 16 or 24 clock cycles, on a fixed program of two or
> three phases (_everything_ happens on 8-cycle boundaries).  A typical
> instruction would load the byte pointed to by register N into D, then
> increment the register pointed to by N.
> 
> I think you may be right about using the ALU for incrementing registers
> -- they don't show it that way in their logical diagram, but I just now
> realized that they never increment or decrement a register AND do an
> arithmetic operation in the same instruction.
> 

No surprise on the multiple of 8 cycles.  The 1802 was a
one-bit serial processor.  It's ALU was therefore really
small.  A bit more logic for all the sequencing, but
overall it had a very small footprint in gates.

-- 
Gabor

Article: 160008
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Wed, 10 May 2017 23:09:48 -0500
Links: << >>  << T >>  << A >>
On Wed, 10 May 2017 22:28:34 -0400, Gabor wrote:

> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
>> 
>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>>>> processor that I owned all just for me, and that I wrote programs for
>>>> (in machine code -- not assembly).
>>>>
>>>> One of the features of this chip is that while the usual ALU is 8-bit
>>>> and centered around memory fetches and the accumulator (which they
>>>> call the 'D' register), there's a 16 x 16-bit register file.  Any one
>>>> of these registers can be incremented or decremented, either as an
>>>> explicit instruction or as part of a fetch (basically, you can use
>>>> any one of them as an index, and you can "fetch and increment").
>>>>
>>>> How would you do this most effectively today?  How might it have been
>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
>>>> you were determined to minimize chip area?
>>>>
>>>> I'm assuming that the original had one selectable increment/decrement
>>>> unit that wrote back numbers to the registers, but I could see them
>>>> implementing each register as a loadable counter -- I just don't have
>>>> a good idea of what might use the least real estate.
>>>
>>> A counter is a register with an adder (although only needing half
>>> adders at each bit), so of course the incrementer will take up more
>>> logic than a register.
>>>
>>> Depending on what functions can be done while the register is
>>> incrementing, they may use the ALU for all arithmetic operations. 
>>> Most of the earlier processors conserved logic by time sequencing
>>> operations within an instruction.  That's why some instructions take
>>> so many cycles to complete, it's shuffling data around internally.
>>>
>>> If you provide some instructions with their descriptions and the cycle
>>> counts I bet I can tell you how much is done sequentially and how much
>>> is done in parallel.
>> 
>> There's a surprisingly large ecosystem of users for the processor -- I
>> think because it was a popular, dirt-cheap hobby system, and now
>> there's all these experienced digital-heads playing with their old
>> toys.  There's even an "Olduino" project that marries a 1802 board with
>> Arduino shields.
>> 
>> The 1802 is how I got into doing deep-embedded systems (you can run an
>> RC servo!  With a counter!  In Software!!!).  So I understand the
>> enthusiasm because I share it.
>> 
>> Here's the Whole Damned User's Manual:
>> 
>> http://datasheets.chipdb.org/RCA/
MPM-201B_CDP1802_Users_Manual_Nov77.pdf
>> 
>> All instructions take 16 or 24 clock cycles, on a fixed program of two
>> or three phases (_everything_ happens on 8-cycle boundaries).  A
>> typical instruction would load the byte pointed to by register N into
>> D, then increment the register pointed to by N.
>> 
>> I think you may be right about using the ALU for incrementing registers
>> -- they don't show it that way in their logical diagram, but I just now
>> realized that they never increment or decrement a register AND do an
>> arithmetic operation in the same instruction.
>> 
>> 
> No surprise on the multiple of 8 cycles.  The 1802 was a one-bit serial
> processor.  It's ALU was therefore really small.  A bit more logic for
> all the sequencing, but overall it had a very small footprint in gates.

How did they manage the 16-bit register increment and decrement, then?

-- 

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

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

Article: 160009
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Cecil Bayona <cbayona@cbayona.com>
Date: Wed, 10 May 2017 23:59:43 -0500
Links: << >>  << T >>  << A >>
On 5/10/2017 9:28 PM, Gabor wrote:
> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
>>
>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>>>> processor that I owned all just for me, and that I wrote programs for
>>>> (in machine code -- not assembly).
>>>>
>>>> One of the features of this chip is that while the usual ALU is 8-bit
>>>> and centered around memory fetches and the accumulator (which they call
>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
>>>> these registers can be incremented or decremented, either as an
>>>> explicit instruction or as part of a fetch (basically, you can use any
>>>> one of them as an index, and you can "fetch and increment").
>>>>
>>>> How would you do this most effectively today?  How might it have been
>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
>>>> you were determined to minimize chip area?
>>>>
>>>> I'm assuming that the original had one selectable increment/decrement
>>>> unit that wrote back numbers to the registers, but I could see them
>>>> implementing each register as a loadable counter -- I just don't have a
>>>> good idea of what might use the least real estate.
>>>
>>> A counter is a register with an adder (although only needing half adders
>>> at each bit), so of course the incrementer will take up more logic than
>>> a register.
>>>
>>> Depending on what functions can be done while the register is
>>> incrementing, they may use the ALU for all arithmetic operations.  Most
>>> of the earlier processors conserved logic by time sequencing operations
>>> within an instruction.  That's why some instructions take so many cycles
>>> to complete, it's shuffling data around internally.
>>>
>>> If you provide some instructions with their descriptions and the cycle
>>> counts I bet I can tell you how much is done sequentially and how much
>>> is done in parallel.
>>
>> There's a surprisingly large ecosystem of users for the processor -- I
>> think because it was a popular, dirt-cheap hobby system, and now there's
>> all these experienced digital-heads playing with their old toys.  There's
>> even an "Olduino" project that marries a 1802 board with Arduino
>> shields.
>>
>> The 1802 is how I got into doing deep-embedded systems (you can run an RC
>> servo!  With a counter!  In Software!!!).  So I understand the enthusiasm
>> because I share it.
>>
>> Here's the Whole Damned User's Manual:
>>
>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
>>
>> All instructions take 16 or 24 clock cycles, on a fixed program of two or
>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
>> instruction would load the byte pointed to by register N into D, then
>> increment the register pointed to by N.
>>
>> I think you may be right about using the ALU for incrementing registers
>> -- they don't show it that way in their logical diagram, but I just now
>> realized that they never increment or decrement a register AND do an
>> arithmetic operation in the same instruction.
>>
> 
> No surprise on the multiple of 8 cycles.  The 1802 was a
> one-bit serial processor.  It's ALU was therefore really
> small.  A bit more logic for all the sequencing, but
> overall it had a very small footprint in gates.
> 
I believe you are incorrect, several RCA manuals shows the ALU as being 
8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing 
improved many of the chips could get to 8Mhz but they were sold a 2MHz 
parts.

Do you have a link that shows the ALU is serial instead of 8 bit parallel?

-- 
Cecil - k5nwa

Article: 160010
Subject: Re: increment or decrement one of 16, 16-bit registers
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 May 2017 01:17:05 -0400
Links: << >>  << T >>  << A >>
On 5/11/2017 12:59 AM, Cecil Bayona wrote:
> On 5/10/2017 9:28 PM, Gabor wrote:
>> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
>>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
>>>
>>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>>>>> processor that I owned all just for me, and that I wrote programs for
>>>>> (in machine code -- not assembly).
>>>>>
>>>>> One of the features of this chip is that while the usual ALU is 8-bit
>>>>> and centered around memory fetches and the accumulator (which they
>>>>> call
>>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
>>>>> these registers can be incremented or decremented, either as an
>>>>> explicit instruction or as part of a fetch (basically, you can use any
>>>>> one of them as an index, and you can "fetch and increment").
>>>>>
>>>>> How would you do this most effectively today?  How might it have been
>>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
>>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
>>>>> you were determined to minimize chip area?
>>>>>
>>>>> I'm assuming that the original had one selectable increment/decrement
>>>>> unit that wrote back numbers to the registers, but I could see them
>>>>> implementing each register as a loadable counter -- I just don't
>>>>> have a
>>>>> good idea of what might use the least real estate.
>>>>
>>>> A counter is a register with an adder (although only needing half
>>>> adders
>>>> at each bit), so of course the incrementer will take up more logic than
>>>> a register.
>>>>
>>>> Depending on what functions can be done while the register is
>>>> incrementing, they may use the ALU for all arithmetic operations.  Most
>>>> of the earlier processors conserved logic by time sequencing operations
>>>> within an instruction.  That's why some instructions take so many
>>>> cycles
>>>> to complete, it's shuffling data around internally.
>>>>
>>>> If you provide some instructions with their descriptions and the cycle
>>>> counts I bet I can tell you how much is done sequentially and how much
>>>> is done in parallel.
>>>
>>> There's a surprisingly large ecosystem of users for the processor -- I
>>> think because it was a popular, dirt-cheap hobby system, and now there's
>>> all these experienced digital-heads playing with their old toys.
>>> There's
>>> even an "Olduino" project that marries a 1802 board with Arduino
>>> shields.
>>>
>>> The 1802 is how I got into doing deep-embedded systems (you can run
>>> an RC
>>> servo!  With a counter!  In Software!!!).  So I understand the
>>> enthusiasm
>>> because I share it.
>>>
>>> Here's the Whole Damned User's Manual:
>>>
>>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
>>>
>>> All instructions take 16 or 24 clock cycles, on a fixed program of
>>> two or
>>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
>>> instruction would load the byte pointed to by register N into D, then
>>> increment the register pointed to by N.
>>>
>>> I think you may be right about using the ALU for incrementing registers
>>> -- they don't show it that way in their logical diagram, but I just now
>>> realized that they never increment or decrement a register AND do an
>>> arithmetic operation in the same instruction.
>>>
>>
>> No surprise on the multiple of 8 cycles.  The 1802 was a
>> one-bit serial processor.  It's ALU was therefore really
>> small.  A bit more logic for all the sequencing, but
>> overall it had a very small footprint in gates.
>>
> I believe you are incorrect, several RCA manuals shows the ALU as being
> 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing
> improved many of the chips could get to 8Mhz but they were sold a 2MHz
> parts.
>
> Do you have a link that shows the ALU is serial instead of 8 bit parallel?

I have looked at serializing adders and multipliers.  The control logic 
is large enough that it greatly mitigates the logic saving of a bit 
arithmetic unit versus an 8 bit unit.  Even for a multiplier a full bit 
serial unit is not much smaller than a word wide add/shift design.  Any 
time you have bit wide logic the registers need multiplexers which are 
not much different from adders.

-- 

Rick C

Article: 160011
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Thu, 11 May 2017 08:39:54 +0100
Links: << >>  << T >>  << A >>
On 11/05/17 00:20, Tim Wescott wrote:
> The 1802 is how I got into doing deep-embedded systems (you can run an RC
> servo!  With a counter!  In Software!!!).  So I understand the enthusiasm
> because I share it.

You might like the XMOS processors for *hard* real-time systems.
Wide range available on Digikey.

Multicore, "FPGA like" I/O (I/O occurre on specified clock
cycles), xC is its CSP/Occam/Transputer event-based programming
model.

Loop and function times guaranteed by the development
environment based on its examining the binary file.

I've just started playing with them, and have already managed
to use a single-core as a "software frequency counter" that
counts the transitions in a 50Mb/s serial data stream. Replicate
that in another core and you have the basis of a frequency ratio
meter.

Article: 160012
Subject: size lattice iCE40 config files
From: kristoff <kristoff@skypro.be>
Date: Thu, 11 May 2017 13:44:37 +0200
Links: << >>  << T >>  << A >>
Hi all,


I am working on a STM32-based programmer for the olimex iCE40HX1K-EVB 
fpga dev.board.
(now trying to implement the "SPI Slave configuration" protocol).


Looking at the Lattice "programming and Configuration guide" (page 11), 
it is noted on table 8 that a FLASH EPROM for a ICE40-LP/LX1K must be at 
least 34112 bytes.
However, all binary-files as created by the icestorm-tools are all 
smaller: all 32220 bytes.
(and the smaller file does seams to match for the format as described in 
the lattice documentation).

Does anybody have any idea where this "34112 bytes" figure comes from in 
the lattice doc comes from?


Kristoff

Article: 160013
Subject: Re: increment or decrement one of 16, 16-bit registers
From: lasselangwadtchristensen@gmail.com
Date: Thu, 11 May 2017 08:44:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman:
> On 5/11/2017 12:59 AM, Cecil Bayona wrote:
> > On 5/10/2017 9:28 PM, Gabor wrote:
> >> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
> >>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
> >>>
> >>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
> >>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
> >>>>> processor that I owned all just for me, and that I wrote programs for
> >>>>> (in machine code -- not assembly).
> >>>>>
> >>>>> One of the features of this chip is that while the usual ALU is 8-bit
> >>>>> and centered around memory fetches and the accumulator (which they
> >>>>> call
> >>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
> >>>>> these registers can be incremented or decremented, either as an
> >>>>> explicit instruction or as part of a fetch (basically, you can use any
> >>>>> one of them as an index, and you can "fetch and increment").
> >>>>>
> >>>>> How would you do this most effectively today?  How might it have been
> >>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
> >>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
> >>>>> you were determined to minimize chip area?
> >>>>>
> >>>>> I'm assuming that the original had one selectable increment/decrement
> >>>>> unit that wrote back numbers to the registers, but I could see them
> >>>>> implementing each register as a loadable counter -- I just don't
> >>>>> have a
> >>>>> good idea of what might use the least real estate.
> >>>>
> >>>> A counter is a register with an adder (although only needing half
> >>>> adders
> >>>> at each bit), so of course the incrementer will take up more logic than
> >>>> a register.
> >>>>
> >>>> Depending on what functions can be done while the register is
> >>>> incrementing, they may use the ALU for all arithmetic operations.  Most
> >>>> of the earlier processors conserved logic by time sequencing operations
> >>>> within an instruction.  That's why some instructions take so many
> >>>> cycles
> >>>> to complete, it's shuffling data around internally.
> >>>>
> >>>> If you provide some instructions with their descriptions and the cycle
> >>>> counts I bet I can tell you how much is done sequentially and how much
> >>>> is done in parallel.
> >>>
> >>> There's a surprisingly large ecosystem of users for the processor -- I
> >>> think because it was a popular, dirt-cheap hobby system, and now there's
> >>> all these experienced digital-heads playing with their old toys.
> >>> There's
> >>> even an "Olduino" project that marries a 1802 board with Arduino
> >>> shields.
> >>>
> >>> The 1802 is how I got into doing deep-embedded systems (you can run
> >>> an RC
> >>> servo!  With a counter!  In Software!!!).  So I understand the
> >>> enthusiasm
> >>> because I share it.
> >>>
> >>> Here's the Whole Damned User's Manual:
> >>>
> >>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
> >>>
> >>> All instructions take 16 or 24 clock cycles, on a fixed program of
> >>> two or
> >>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
> >>> instruction would load the byte pointed to by register N into D, then
> >>> increment the register pointed to by N.
> >>>
> >>> I think you may be right about using the ALU for incrementing registers
> >>> -- they don't show it that way in their logical diagram, but I just now
> >>> realized that they never increment or decrement a register AND do an
> >>> arithmetic operation in the same instruction.
> >>>
> >>
> >> No surprise on the multiple of 8 cycles.  The 1802 was a
> >> one-bit serial processor.  It's ALU was therefore really
> >> small.  A bit more logic for all the sequencing, but
> >> overall it had a very small footprint in gates.
> >>
> > I believe you are incorrect, several RCA manuals shows the ALU as being
> > 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing
> > improved many of the chips could get to 8Mhz but they were sold a 2MHz
> > parts.
> >
> > Do you have a link that shows the ALU is serial instead of 8 bit parallel?
> 
> I have looked at serializing adders and multipliers.  The control logic 
> is large enough that it greatly mitigates the logic saving of a bit 
> arithmetic unit versus an 8 bit unit.  Even for a multiplier a full bit 
> serial unit is not much smaller than a word wide add/shift design.  Any 
> time you have bit wide logic the registers need multiplexers which are 
> not much different from adders.

when you have cycles to spare you can just shift 


Article: 160014
Subject: Re: size lattice iCE40 config files
From: Jan Coombs <jenfhaomndgfwutc@murmic.plus.com>
Date: Thu, 11 May 2017 19:03:48 +0100
Links: << >>  << T >>  << A >>
On Thu, 11 May 2017 13:44:37 +0200
kristoff <kristoff@skypro.be> wrote:

> Looking at the Lattice "programming and Configuration
> guide" (page 11), it is noted on table 8 that a FLASH EPROM
> for a ICE40-LP/LX1K must be at least 34112 bytes.
> However, all binary-files as created by the icestorm-tools are
> all smaller: all 32220 bytes.
> (and the smaller file does seams to match for the format as
> described in the lattice documentation).
> 
> Does anybody have any idea where this "34112 bytes" figure
> comes from in the lattice doc comes from?
> 
> 
> Kristoff

Adding RAM initialisation increases the configuration file size. 

Jan Coombs

Article: 160015
Subject: Re: increment or decrement one of 16, 16-bit registers
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 May 2017 14:08:28 -0400
Links: << >>  << T >>  << A >>
On 5/11/2017 11:44 AM, lasselangwadtchristensen@gmail.com wrote:
> Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman:
>> On 5/11/2017 12:59 AM, Cecil Bayona wrote:
>>> On 5/10/2017 9:28 PM, Gabor wrote:
>>>> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
>>>>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
>>>>>
>>>>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>>>>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>>>>>>> processor that I owned all just for me, and that I wrote programs for
>>>>>>> (in machine code -- not assembly).
>>>>>>>
>>>>>>> One of the features of this chip is that while the usual ALU is 8-bit
>>>>>>> and centered around memory fetches and the accumulator (which they
>>>>>>> call
>>>>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
>>>>>>> these registers can be incremented or decremented, either as an
>>>>>>> explicit instruction or as part of a fetch (basically, you can use any
>>>>>>> one of them as an index, and you can "fetch and increment").
>>>>>>>
>>>>>>> How would you do this most effectively today?  How might it have been
>>>>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
>>>>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
>>>>>>> you were determined to minimize chip area?
>>>>>>>
>>>>>>> I'm assuming that the original had one selectable increment/decrement
>>>>>>> unit that wrote back numbers to the registers, but I could see them
>>>>>>> implementing each register as a loadable counter -- I just don't
>>>>>>> have a
>>>>>>> good idea of what might use the least real estate.
>>>>>>
>>>>>> A counter is a register with an adder (although only needing half
>>>>>> adders
>>>>>> at each bit), so of course the incrementer will take up more logic than
>>>>>> a register.
>>>>>>
>>>>>> Depending on what functions can be done while the register is
>>>>>> incrementing, they may use the ALU for all arithmetic operations.  Most
>>>>>> of the earlier processors conserved logic by time sequencing operations
>>>>>> within an instruction.  That's why some instructions take so many
>>>>>> cycles
>>>>>> to complete, it's shuffling data around internally.
>>>>>>
>>>>>> If you provide some instructions with their descriptions and the cycle
>>>>>> counts I bet I can tell you how much is done sequentially and how much
>>>>>> is done in parallel.
>>>>>
>>>>> There's a surprisingly large ecosystem of users for the processor -- I
>>>>> think because it was a popular, dirt-cheap hobby system, and now there's
>>>>> all these experienced digital-heads playing with their old toys.
>>>>> There's
>>>>> even an "Olduino" project that marries a 1802 board with Arduino
>>>>> shields.
>>>>>
>>>>> The 1802 is how I got into doing deep-embedded systems (you can run
>>>>> an RC
>>>>> servo!  With a counter!  In Software!!!).  So I understand the
>>>>> enthusiasm
>>>>> because I share it.
>>>>>
>>>>> Here's the Whole Damned User's Manual:
>>>>>
>>>>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
>>>>>
>>>>> All instructions take 16 or 24 clock cycles, on a fixed program of
>>>>> two or
>>>>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
>>>>> instruction would load the byte pointed to by register N into D, then
>>>>> increment the register pointed to by N.
>>>>>
>>>>> I think you may be right about using the ALU for incrementing registers
>>>>> -- they don't show it that way in their logical diagram, but I just now
>>>>> realized that they never increment or decrement a register AND do an
>>>>> arithmetic operation in the same instruction.
>>>>>
>>>>
>>>> No surprise on the multiple of 8 cycles.  The 1802 was a
>>>> one-bit serial processor.  It's ALU was therefore really
>>>> small.  A bit more logic for all the sequencing, but
>>>> overall it had a very small footprint in gates.
>>>>
>>> I believe you are incorrect, several RCA manuals shows the ALU as being
>>> 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing
>>> improved many of the chips could get to 8Mhz but they were sold a 2MHz
>>> parts.
>>>
>>> Do you have a link that shows the ALU is serial instead of 8 bit parallel?
>>
>> I have looked at serializing adders and multipliers.  The control logic
>> is large enough that it greatly mitigates the logic saving of a bit
>> arithmetic unit versus an 8 bit unit.  Even for a multiplier a full bit
>> serial unit is not much smaller than a word wide add/shift design.  Any
>> time you have bit wide logic the registers need multiplexers which are
>> not much different from adders.
>
> when you have cycles to spare you can just shift

What does that have to do with anything?

-- 

Rick C

Article: 160016
Subject: Re: increment or decrement one of 16, 16-bit registers
From: lasselangwadtchristensen@gmail.com
Date: Thu, 11 May 2017 11:27:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den torsdag den 11. maj 2017 kl. 20.08.30 UTC+2 skrev rickman:
> On 5/11/2017 11:44 AM, lasselangwadtchristensen@gmail.com wrote:
> > Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman:
> >> On 5/11/2017 12:59 AM, Cecil Bayona wrote:
> >>> On 5/10/2017 9:28 PM, Gabor wrote:
> >>>> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
> >>>>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
> >>>>>
> >>>>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
> >>>>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
> >>>>>>> processor that I owned all just for me, and that I wrote programs for
> >>>>>>> (in machine code -- not assembly).
> >>>>>>>
> >>>>>>> One of the features of this chip is that while the usual ALU is 8-bit
> >>>>>>> and centered around memory fetches and the accumulator (which they
> >>>>>>> call
> >>>>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
> >>>>>>> these registers can be incremented or decremented, either as an
> >>>>>>> explicit instruction or as part of a fetch (basically, you can use any
> >>>>>>> one of them as an index, and you can "fetch and increment").
> >>>>>>>
> >>>>>>> How would you do this most effectively today?  How might it have been
> >>>>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
> >>>>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
> >>>>>>> you were determined to minimize chip area?
> >>>>>>>
> >>>>>>> I'm assuming that the original had one selectable increment/decrement
> >>>>>>> unit that wrote back numbers to the registers, but I could see them
> >>>>>>> implementing each register as a loadable counter -- I just don't
> >>>>>>> have a
> >>>>>>> good idea of what might use the least real estate.
> >>>>>>
> >>>>>> A counter is a register with an adder (although only needing half
> >>>>>> adders
> >>>>>> at each bit), so of course the incrementer will take up more logic than
> >>>>>> a register.
> >>>>>>
> >>>>>> Depending on what functions can be done while the register is
> >>>>>> incrementing, they may use the ALU for all arithmetic operations.  Most
> >>>>>> of the earlier processors conserved logic by time sequencing operations
> >>>>>> within an instruction.  That's why some instructions take so many
> >>>>>> cycles
> >>>>>> to complete, it's shuffling data around internally.
> >>>>>>
> >>>>>> If you provide some instructions with their descriptions and the cycle
> >>>>>> counts I bet I can tell you how much is done sequentially and how much
> >>>>>> is done in parallel.
> >>>>>
> >>>>> There's a surprisingly large ecosystem of users for the processor -- I
> >>>>> think because it was a popular, dirt-cheap hobby system, and now there's
> >>>>> all these experienced digital-heads playing with their old toys.
> >>>>> There's
> >>>>> even an "Olduino" project that marries a 1802 board with Arduino
> >>>>> shields.
> >>>>>
> >>>>> The 1802 is how I got into doing deep-embedded systems (you can run
> >>>>> an RC
> >>>>> servo!  With a counter!  In Software!!!).  So I understand the
> >>>>> enthusiasm
> >>>>> because I share it.
> >>>>>
> >>>>> Here's the Whole Damned User's Manual:
> >>>>>
> >>>>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
> >>>>>
> >>>>> All instructions take 16 or 24 clock cycles, on a fixed program of
> >>>>> two or
> >>>>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
> >>>>> instruction would load the byte pointed to by register N into D, then
> >>>>> increment the register pointed to by N.
> >>>>>
> >>>>> I think you may be right about using the ALU for incrementing registers
> >>>>> -- they don't show it that way in their logical diagram, but I just now
> >>>>> realized that they never increment or decrement a register AND do an
> >>>>> arithmetic operation in the same instruction.
> >>>>>
> >>>>
> >>>> No surprise on the multiple of 8 cycles.  The 1802 was a
> >>>> one-bit serial processor.  It's ALU was therefore really
> >>>> small.  A bit more logic for all the sequencing, but
> >>>> overall it had a very small footprint in gates.
> >>>>
> >>> I believe you are incorrect, several RCA manuals shows the ALU as being
> >>> 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing
> >>> improved many of the chips could get to 8Mhz but they were sold a 2MHz
> >>> parts.
> >>>
> >>> Do you have a link that shows the ALU is serial instead of 8 bit parallel?
> >>
> >> I have looked at serializing adders and multipliers.  The control logic
> >> is large enough that it greatly mitigates the logic saving of a bit
> >> arithmetic unit versus an 8 bit unit.  Even for a multiplier a full bit
> >> serial unit is not much smaller than a word wide add/shift design.  Any
> >> time you have bit wide logic the registers need multiplexers which are
> >> not much different from adders.
> >
> > when you have cycles to spare you can just shift
> 
> What does that have to do with anything?
> 

you said you needed multiplexers 

Article: 160017
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 11 May 2017 14:55:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
> All instructions take 16 or 24 clock cycles, on a fixed program of two or 
> three phases (_everything_ happens on 8-cycle boundaries).  

24 cycles?  Holy smokes.  I remember most of the 6502 instructions being 2-3 cycles.

Article: 160018
Subject: Re: increment or decrement one of 16, 16-bit registers
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 May 2017 18:20:43 -0400
Links: << >>  << T >>  << A >>
On 5/11/2017 2:27 PM, lasselangwadtchristensen@gmail.com wrote:
> Den torsdag den 11. maj 2017 kl. 20.08.30 UTC+2 skrev rickman:
>> On 5/11/2017 11:44 AM, lasselangwadtchristensen@gmail.com wrote:
>>> Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman:
>>>> On 5/11/2017 12:59 AM, Cecil Bayona wrote:
>>>>> On 5/10/2017 9:28 PM, Gabor wrote:
>>>>>> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
>>>>>>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
>>>>>>>
>>>>>>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>>>>>>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>>>>>>>>> processor that I owned all just for me, and that I wrote programs for
>>>>>>>>> (in machine code -- not assembly).
>>>>>>>>>
>>>>>>>>> One of the features of this chip is that while the usual ALU is 8-bit
>>>>>>>>> and centered around memory fetches and the accumulator (which they
>>>>>>>>> call
>>>>>>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
>>>>>>>>> these registers can be incremented or decremented, either as an
>>>>>>>>> explicit instruction or as part of a fetch (basically, you can use any
>>>>>>>>> one of them as an index, and you can "fetch and increment").
>>>>>>>>>
>>>>>>>>> How would you do this most effectively today?  How might it have been
>>>>>>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
>>>>>>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
>>>>>>>>> you were determined to minimize chip area?
>>>>>>>>>
>>>>>>>>> I'm assuming that the original had one selectable increment/decrement
>>>>>>>>> unit that wrote back numbers to the registers, but I could see them
>>>>>>>>> implementing each register as a loadable counter -- I just don't
>>>>>>>>> have a
>>>>>>>>> good idea of what might use the least real estate.
>>>>>>>>
>>>>>>>> A counter is a register with an adder (although only needing half
>>>>>>>> adders
>>>>>>>> at each bit), so of course the incrementer will take up more logic than
>>>>>>>> a register.
>>>>>>>>
>>>>>>>> Depending on what functions can be done while the register is
>>>>>>>> incrementing, they may use the ALU for all arithmetic operations.  Most
>>>>>>>> of the earlier processors conserved logic by time sequencing operations
>>>>>>>> within an instruction.  That's why some instructions take so many
>>>>>>>> cycles
>>>>>>>> to complete, it's shuffling data around internally.
>>>>>>>>
>>>>>>>> If you provide some instructions with their descriptions and the cycle
>>>>>>>> counts I bet I can tell you how much is done sequentially and how much
>>>>>>>> is done in parallel.
>>>>>>>
>>>>>>> There's a surprisingly large ecosystem of users for the processor -- I
>>>>>>> think because it was a popular, dirt-cheap hobby system, and now there's
>>>>>>> all these experienced digital-heads playing with their old toys.
>>>>>>> There's
>>>>>>> even an "Olduino" project that marries a 1802 board with Arduino
>>>>>>> shields.
>>>>>>>
>>>>>>> The 1802 is how I got into doing deep-embedded systems (you can run
>>>>>>> an RC
>>>>>>> servo!  With a counter!  In Software!!!).  So I understand the
>>>>>>> enthusiasm
>>>>>>> because I share it.
>>>>>>>
>>>>>>> Here's the Whole Damned User's Manual:
>>>>>>>
>>>>>>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
>>>>>>>
>>>>>>> All instructions take 16 or 24 clock cycles, on a fixed program of
>>>>>>> two or
>>>>>>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
>>>>>>> instruction would load the byte pointed to by register N into D, then
>>>>>>> increment the register pointed to by N.
>>>>>>>
>>>>>>> I think you may be right about using the ALU for incrementing registers
>>>>>>> -- they don't show it that way in their logical diagram, but I just now
>>>>>>> realized that they never increment or decrement a register AND do an
>>>>>>> arithmetic operation in the same instruction.
>>>>>>>
>>>>>>
>>>>>> No surprise on the multiple of 8 cycles.  The 1802 was a
>>>>>> one-bit serial processor.  It's ALU was therefore really
>>>>>> small.  A bit more logic for all the sequencing, but
>>>>>> overall it had a very small footprint in gates.
>>>>>>
>>>>> I believe you are incorrect, several RCA manuals shows the ALU as being
>>>>> 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing
>>>>> improved many of the chips could get to 8Mhz but they were sold a 2MHz
>>>>> parts.
>>>>>
>>>>> Do you have a link that shows the ALU is serial instead of 8 bit parallel?
>>>>
>>>> I have looked at serializing adders and multipliers.  The control logic
>>>> is large enough that it greatly mitigates the logic saving of a bit
>>>> arithmetic unit versus an 8 bit unit.  Even for a multiplier a full bit
>>>> serial unit is not much smaller than a word wide add/shift design.  Any
>>>> time you have bit wide logic the registers need multiplexers which are
>>>> not much different from adders.
>>>
>>> when you have cycles to spare you can just shift
>>
>> What does that have to do with anything?
>>
>
> you said you needed multiplexers

Do you understand how shifting happens?  It uses multiplexers to switch 
between loading and shifting.

-- 

Rick C

Article: 160019
Subject: Re: increment or decrement one of 16, 16-bit registers
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 May 2017 18:21:32 -0400
Links: << >>  << T >>  << A >>
On 5/11/2017 5:55 PM, Kevin Neilson wrote:
>> All instructions take 16 or 24 clock cycles, on a fixed program of two or
>> three phases (_everything_ happens on 8-cycle boundaries).
>
> 24 cycles?  Holy smokes.  I remember most of the 6502 instructions being 2-3 cycles.

No one ever said the 1802 was fast.  If you want slow, you should have 
seen the 1801!  lol ;)

-- 

Rick C

Article: 160020
Subject: Re: increment or decrement one of 16, 16-bit registers
From: lasselangwadtchristensen@gmail.com
Date: Thu, 11 May 2017 15:46:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den fredag den 12. maj 2017 kl. 00.20.45 UTC+2 skrev rickman:
> On 5/11/2017 2:27 PM, lasselangwadtchristensen@gmail.com wrote:
> > Den torsdag den 11. maj 2017 kl. 20.08.30 UTC+2 skrev rickman:
> >> On 5/11/2017 11:44 AM, lasselangwadtchristensen@gmail.com wrote:
> >>> Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman:
> >>>> On 5/11/2017 12:59 AM, Cecil Bayona wrote:
> >>>>> On 5/10/2017 9:28 PM, Gabor wrote:
> >>>>>> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
> >>>>>>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
> >>>>>>>
> >>>>>>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
> >>>>>>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
> >>>>>>>>> processor that I owned all just for me, and that I wrote programs for
> >>>>>>>>> (in machine code -- not assembly).
> >>>>>>>>>
> >>>>>>>>> One of the features of this chip is that while the usual ALU is 8-bit
> >>>>>>>>> and centered around memory fetches and the accumulator (which they
> >>>>>>>>> call
> >>>>>>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
> >>>>>>>>> these registers can be incremented or decremented, either as an
> >>>>>>>>> explicit instruction or as part of a fetch (basically, you can use any
> >>>>>>>>> one of them as an index, and you can "fetch and increment").
> >>>>>>>>>
> >>>>>>>>> How would you do this most effectively today?  How might it have been
> >>>>>>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
> >>>>>>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
> >>>>>>>>> you were determined to minimize chip area?
> >>>>>>>>>
> >>>>>>>>> I'm assuming that the original had one selectable increment/decrement
> >>>>>>>>> unit that wrote back numbers to the registers, but I could see them
> >>>>>>>>> implementing each register as a loadable counter -- I just don't
> >>>>>>>>> have a
> >>>>>>>>> good idea of what might use the least real estate.
> >>>>>>>>
> >>>>>>>> A counter is a register with an adder (although only needing half
> >>>>>>>> adders
> >>>>>>>> at each bit), so of course the incrementer will take up more logic than
> >>>>>>>> a register.
> >>>>>>>>
> >>>>>>>> Depending on what functions can be done while the register is
> >>>>>>>> incrementing, they may use the ALU for all arithmetic operations.  Most
> >>>>>>>> of the earlier processors conserved logic by time sequencing operations
> >>>>>>>> within an instruction.  That's why some instructions take so many
> >>>>>>>> cycles
> >>>>>>>> to complete, it's shuffling data around internally.
> >>>>>>>>
> >>>>>>>> If you provide some instructions with their descriptions and the cycle
> >>>>>>>> counts I bet I can tell you how much is done sequentially and how much
> >>>>>>>> is done in parallel.
> >>>>>>>
> >>>>>>> There's a surprisingly large ecosystem of users for the processor -- I
> >>>>>>> think because it was a popular, dirt-cheap hobby system, and now there's
> >>>>>>> all these experienced digital-heads playing with their old toys.
> >>>>>>> There's
> >>>>>>> even an "Olduino" project that marries a 1802 board with Arduino
> >>>>>>> shields.
> >>>>>>>
> >>>>>>> The 1802 is how I got into doing deep-embedded systems (you can run
> >>>>>>> an RC
> >>>>>>> servo!  With a counter!  In Software!!!).  So I understand the
> >>>>>>> enthusiasm
> >>>>>>> because I share it.
> >>>>>>>
> >>>>>>> Here's the Whole Damned User's Manual:
> >>>>>>>
> >>>>>>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
> >>>>>>>
> >>>>>>> All instructions take 16 or 24 clock cycles, on a fixed program of
> >>>>>>> two or
> >>>>>>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
> >>>>>>> instruction would load the byte pointed to by register N into D, then
> >>>>>>> increment the register pointed to by N.
> >>>>>>>
> >>>>>>> I think you may be right about using the ALU for incrementing registers
> >>>>>>> -- they don't show it that way in their logical diagram, but I just now
> >>>>>>> realized that they never increment or decrement a register AND do an
> >>>>>>> arithmetic operation in the same instruction.
> >>>>>>>
> >>>>>>
> >>>>>> No surprise on the multiple of 8 cycles.  The 1802 was a
> >>>>>> one-bit serial processor.  It's ALU was therefore really
> >>>>>> small.  A bit more logic for all the sequencing, but
> >>>>>> overall it had a very small footprint in gates.
> >>>>>>
> >>>>> I believe you are incorrect, several RCA manuals shows the ALU as being
> >>>>> 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing
> >>>>> improved many of the chips could get to 8Mhz but they were sold a 2MHz
> >>>>> parts.
> >>>>>
> >>>>> Do you have a link that shows the ALU is serial instead of 8 bit parallel?
> >>>>
> >>>> I have looked at serializing adders and multipliers.  The control logic
> >>>> is large enough that it greatly mitigates the logic saving of a bit
> >>>> arithmetic unit versus an 8 bit unit.  Even for a multiplier a full bit
> >>>> serial unit is not much smaller than a word wide add/shift design.  Any
> >>>> time you have bit wide logic the registers need multiplexers which are
> >>>> not much different from adders.
> >>>
> >>> when you have cycles to spare you can just shift
> >>
> >> What does that have to do with anything?
> >>
> >
> > you said you needed multiplexers
> 
> Do you understand how shifting happens?  It uses multiplexers to switch 
> between loading and shifting.

you could also do load by shifting 




Article: 160021
Subject: Re: increment or decrement one of 16, 16-bit registers
From: rickman <gnuarm@gmail.com>
Date: Thu, 11 May 2017 20:33:59 -0400
Links: << >>  << T >>  << A >>
On 5/11/2017 6:46 PM, lasselangwadtchristensen@gmail.com wrote:
> Den fredag den 12. maj 2017 kl. 00.20.45 UTC+2 skrev rickman:
>> On 5/11/2017 2:27 PM, lasselangwadtchristensen@gmail.com wrote:
>>> Den torsdag den 11. maj 2017 kl. 20.08.30 UTC+2 skrev rickman:
>>>> On 5/11/2017 11:44 AM, lasselangwadtchristensen@gmail.com wrote:
>>>>> Den torsdag den 11. maj 2017 kl. 07.17.08 UTC+2 skrev rickman:
>>>>>> On 5/11/2017 12:59 AM, Cecil Bayona wrote:
>>>>>>> On 5/10/2017 9:28 PM, Gabor wrote:
>>>>>>>> On Wednesday, 5/10/2017 7:20 PM, Tim Wescott wrote:
>>>>>>>>> On Wed, 10 May 2017 18:56:36 -0400, rickman wrote:
>>>>>>>>>
>>>>>>>>>> On 5/10/2017 5:42 PM, Tim Wescott wrote:
>>>>>>>>>>> I've been geeking out on the COSMAC 1802 lately -- it was the first
>>>>>>>>>>> processor that I owned all just for me, and that I wrote programs for
>>>>>>>>>>> (in machine code -- not assembly).
>>>>>>>>>>>
>>>>>>>>>>> One of the features of this chip is that while the usual ALU is 8-bit
>>>>>>>>>>> and centered around memory fetches and the accumulator (which they
>>>>>>>>>>> call
>>>>>>>>>>> the 'D' register), there's a 16 x 16-bit register file.  Any one of
>>>>>>>>>>> these registers can be incremented or decremented, either as an
>>>>>>>>>>> explicit instruction or as part of a fetch (basically, you can use any
>>>>>>>>>>> one of them as an index, and you can "fetch and increment").
>>>>>>>>>>>
>>>>>>>>>>> How would you do this most effectively today?  How might it have been
>>>>>>>>>>> done back in the mid 1970's when RCA made the chip?  Would it make a
>>>>>>>>>>> difference if you were working with a CPLD, FPGA, or some ASIC where
>>>>>>>>>>> you were determined to minimize chip area?
>>>>>>>>>>>
>>>>>>>>>>> I'm assuming that the original had one selectable increment/decrement
>>>>>>>>>>> unit that wrote back numbers to the registers, but I could see them
>>>>>>>>>>> implementing each register as a loadable counter -- I just don't
>>>>>>>>>>> have a
>>>>>>>>>>> good idea of what might use the least real estate.
>>>>>>>>>>
>>>>>>>>>> A counter is a register with an adder (although only needing half
>>>>>>>>>> adders
>>>>>>>>>> at each bit), so of course the incrementer will take up more logic than
>>>>>>>>>> a register.
>>>>>>>>>>
>>>>>>>>>> Depending on what functions can be done while the register is
>>>>>>>>>> incrementing, they may use the ALU for all arithmetic operations.  Most
>>>>>>>>>> of the earlier processors conserved logic by time sequencing operations
>>>>>>>>>> within an instruction.  That's why some instructions take so many
>>>>>>>>>> cycles
>>>>>>>>>> to complete, it's shuffling data around internally.
>>>>>>>>>>
>>>>>>>>>> If you provide some instructions with their descriptions and the cycle
>>>>>>>>>> counts I bet I can tell you how much is done sequentially and how much
>>>>>>>>>> is done in parallel.
>>>>>>>>>
>>>>>>>>> There's a surprisingly large ecosystem of users for the processor -- I
>>>>>>>>> think because it was a popular, dirt-cheap hobby system, and now there's
>>>>>>>>> all these experienced digital-heads playing with their old toys.
>>>>>>>>> There's
>>>>>>>>> even an "Olduino" project that marries a 1802 board with Arduino
>>>>>>>>> shields.
>>>>>>>>>
>>>>>>>>> The 1802 is how I got into doing deep-embedded systems (you can run
>>>>>>>>> an RC
>>>>>>>>> servo!  With a counter!  In Software!!!).  So I understand the
>>>>>>>>> enthusiasm
>>>>>>>>> because I share it.
>>>>>>>>>
>>>>>>>>> Here's the Whole Damned User's Manual:
>>>>>>>>>
>>>>>>>>> http://datasheets.chipdb.org/RCA/MPM-201B_CDP1802_Users_Manual_Nov77.pdf
>>>>>>>>>
>>>>>>>>> All instructions take 16 or 24 clock cycles, on a fixed program of
>>>>>>>>> two or
>>>>>>>>> three phases (_everything_ happens on 8-cycle boundaries).  A typical
>>>>>>>>> instruction would load the byte pointed to by register N into D, then
>>>>>>>>> increment the register pointed to by N.
>>>>>>>>>
>>>>>>>>> I think you may be right about using the ALU for incrementing registers
>>>>>>>>> -- they don't show it that way in their logical diagram, but I just now
>>>>>>>>> realized that they never increment or decrement a register AND do an
>>>>>>>>> arithmetic operation in the same instruction.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No surprise on the multiple of 8 cycles.  The 1802 was a
>>>>>>>> one-bit serial processor.  It's ALU was therefore really
>>>>>>>> small.  A bit more logic for all the sequencing, but
>>>>>>>> overall it had a very small footprint in gates.
>>>>>>>>
>>>>>>> I believe you are incorrect, several RCA manuals shows the ALU as being
>>>>>>> 8 bits wide. In the early 70s the CMOS logic was slow, as manufacturing
>>>>>>> improved many of the chips could get to 8Mhz but they were sold a 2MHz
>>>>>>> parts.
>>>>>>>
>>>>>>> Do you have a link that shows the ALU is serial instead of 8 bit parallel?
>>>>>>
>>>>>> I have looked at serializing adders and multipliers.  The control logic
>>>>>> is large enough that it greatly mitigates the logic saving of a bit
>>>>>> arithmetic unit versus an 8 bit unit.  Even for a multiplier a full bit
>>>>>> serial unit is not much smaller than a word wide add/shift design.  Any
>>>>>> time you have bit wide logic the registers need multiplexers which are
>>>>>> not much different from adders.
>>>>>
>>>>> when you have cycles to spare you can just shift
>>>>
>>>> What does that have to do with anything?
>>>>
>>>
>>> you said you needed multiplexers
>>
>> Do you understand how shifting happens?  It uses multiplexers to switch
>> between loading and shifting.
>
> you could also do load by shifting

Only if the entire CPU were 100% bit serial.  I seriously doubt that is 
the case with the 1802.

-- 

Rick C

Article: 160022
Subject: Re: size lattice iCE40 config files
From: kristoff <kristoff@skypro.be>
Date: Fri, 12 May 2017 17:39:54 +0200
Links: << >>  << T >>  << A >>
Hello Jan,



On 11-05-17 20:03, Jan Coombs wrote:
>> Looking at the Lattice "programming and Configuration
>> guide" (page 11), it is noted on table 8 that a FLASH EPROM
>> for a ICE40-LP/LX1K must be at least 34112 bytes.
>> However, all binary-files as created by the icestorm-tools are
>> all smaller: all 32220 bytes.
>> (and the smaller file does seams to match for the format as
>> described in the lattice documentation).
>> Does anybody have any idea where this "34112 bytes" figure
>> comes from in the lattice doc comes from?

> Adding RAM initialisation increases the configuration file size.


I have been doing a little more research on this.

As documented on the "project icestorm" webpage, the Lattice 
configuration-file is not just a "memory dump" of the configuration and 
block-ram data, it's actually a bit like a programming-language.

I guess you are correct that there is certain things not present in the 
32220 bytes file created by icestorm, but it all BRAM data is there 
(based on output of the "iceunpack" tool).


Anycase, for my original issue ("what is the size of the configuration 
file to be uploaded by the programmer to the ice40"), the answer is "not 
defined, the FPGA just reads the configuration data until it receives 
"01 06" ("wake up") sequence.



> Jan Coombs
Kristoff


Article: 160023
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Jecel <jecel@merlintec.com>
Date: Sat, 13 May 2017 13:07:40 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, May 11, 2017 at 7:21:33 PM UTC-3, rickman wrote:
> On 5/11/2017 5:55 PM, Kevin Neilson wrote:
> > 24 cycles?  Holy smokes.  I remember most of the 6502 instructions
> > being 2-3 cycles.
>=20
> No one ever said the 1802 was fast.  If you want slow, you should have=20
> seen the 1801!  lol ;)

Indeed, many early microprocessors looked a lot more impressive until you s=
aw how many clock cycles each instruction took.

But it is important to remember that there were two different clock styles =
and it is complicated to compare them directly.

The 6502, 6800 and ARM2 used two non overlapping clocks. This required two =
pins and a more complicated external circuit but simplified the internal ci=
rcuit. In a 1MHz 6502, for example, you have four different times in which =
things happen in each microsecond: when clock 1 is high, when both are low,=
 when clock 2 is high and when both are low again.

Many processors had a single clock pin, which allowed you to use a simple o=
scillator externally. But to have the same functionality of the 1MHz 6502 t=
his single clock would have to be 4MHz so you could do four things in each =
microsecond. This was the case of the 68000, for example. The Z80 only need=
ed to do three things.

-- Jecel

Article: 160024
Subject: Re: increment or decrement one of 16, 16-bit registers
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Sat, 13 May 2017 13:26:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Indeed, many early microprocessors looked a lot more impressive until you=
 saw how many clock cycles each instruction took.
>=20
> But it is important to remember that there were two different clock style=
s and it is complicated to compare them directly.

I do remember reading some marketing on the 6502 that asserted that the 650=
2 could do more at 1MHz than the other duplicitous companies which had fast=
er processors but did little per cycle.  Thus began the MHz wars.  (When yo=
u buy a Macbook now, do they even advertise the clock rate?)  I remember th=
e big deal they made out of the "zero page" instructions, which saved a fet=
ch cycle when using registers in the first page (256 bytes) of RAM.



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