Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 ThomasArticle: 160001
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. MKArticle: 160002
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 CArticle: 160003
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! JonArticle: 160004
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
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 CArticle: 160006
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
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. -- GaborArticle: 160008
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
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 - k5nwaArticle: 160010
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 CArticle: 160011
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
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? KristoffArticle: 160013
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 shiftArticle: 160014
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 CoombsArticle: 160015
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 CArticle: 160016
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 multiplexersArticle: 160017
> 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
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 CArticle: 160019
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 CArticle: 160020
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 shiftingArticle: 160021
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 CArticle: 160022
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: 160023On 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. -- JecelArticle: 160024
> 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:
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