Tiny CPUs in programmable logic
rickman
"tiny" is the right word) CPU in an FPGA. The current design is
pushing 2000 LUTs and it is a 3000 LUT chip. The logic is mostly very
slow, so much of the current design could be done in the CPU allowing
much room for future expansion.
I asked in C.A.E and learned about the ZPU design which is open source
and GPL licensed. Oddly enough when I looked at it, it is a stack CPU
that is remarkably similar to one I designed some 6 years ago
specifically to run a forth like language as native machine code.
This one is smaller so it might well prefer it to my own. Also it is
supported by GCC.
To be honest, if I could use a core like this with a Forth development
environment, I would prefer that. But I have yet to find Forth tools
that even support arbitrary processors (ala GCC) much less provide a
good debugging environment. I know the Forth philosophy seems to be
that you can roll your own, but this is no small task if you want
"good" tools. I remember Brad creating TinyBoot and ultimately
abandoning it because it was too much work to make it as good as the
commercial tools. With my CPU, I used the HDL simulator to debug my
code since it was very small and not at all complex. This would be
harder with my current application because the time frame for the
running code is seconds which takes a long time to simulate.
I may stick with my core and continue to create code in Forth/assembly/
machine language. Or I may try the same approach with the ZPU. Or I
may use the GCC tools with ZPU. But I thought I would ask if anyone
had done anything with the ZPU?
Rick
Rod Pemberton
news:87c235a4-ee3d-477f...@34g2000hsh.googlegroups.com...
> I have an application that would be well served by a small (or perhaps
> "tiny" is the right word) CPU in an FPGA. The current design is
> pushing 2000 LUTs and it is a 3000 LUT chip. The logic is mostly very
> slow, so much of the current design could be done in the CPU allowing
> much room for future expansion.
>
"small cpu" and "slow". Here comes the obvious question... Something wrong
with 6502 or modern variants, Z80/Z80000, or older x86, ARM or the BASIC
Stamp (microcontroller w/BASIC interpreter)? Why are you designing your own
when so many cheap embedded market cpu solutions exist?
> I asked in C.A.E and learned about the ZPU design which is open source
> and GPL licensed. Oddly enough when I looked at it, it is a stack CPU
> that is remarkably similar to one I designed some 6 years ago
> specifically to run a forth like language as native machine code.
> This one is smaller so it might well prefer it to my own. Also it is
> supported by GCC.
Is this a one-time FPGA cpu? I.e., do you have hopes of commercial success?
Against x86 and/or ARM? No offense to FORTHers here, but IMO FORTH oriented
cpu's haven't had much market success... ever. Parallex produces Stamps
with languages other than BASIC: Java, SPIN. They have one version with 8
32-bit cores and a built in byte code interpreter... If someone created a
"FORTH Stamp", possibilities?
If one is designing a small cpu in an FPGA, I think one is better off by
adopting a new but simple cpu paradigm with biases from the older
commercially succesful designs like 6502, Z80, 8086 or modern like ARM,
Stamp. E.g., you could do something like reduce the 6502 instruction set to
10-20 instructions, add more registers, make the instructions orthogonal,
and extend it to 64-bits. I'd say skip all the advanced and complicated
stuff (CISC,VLIW, EPIC) and make it simple and easy for you to program.
> To be honest, if I could use a core like this with a Forth development
> environment, I would prefer that. But I have yet to find Forth tools
> that even support arbitrary processors (ala GCC) much less provide a
> good debugging environment. I know the Forth philosophy seems to be
> that you can roll your own, but this is no small task if you want
> "good" tools. I remember Brad creating TinyBoot and ultimately
> abandoning it because it was too much work to make it as good as the
> commercial tools. With my CPU, I used the HDL simulator to debug my
> code since it was very small and not at all complex. This would be
> harder with my current application because the time frame for the
> running code is seconds which takes a long time to simulate.
>
> I may stick with my core and continue to create code in Forth/assembly/
> machine language. Or I may try the same approach with the ZPU.
The ZPU website indicates they use 298 or 442 LUT's. I lost much interest
in EE about the time FPGA's were gaining much market success. So, I'm not
familiar with what level of complexity or scale that represents for a cpu in
an FPGA. But, you stated that your cpu has about 2000 LUT's. That seems
like a substantially larger amount. Is your cpu more functional, faster,
more registers, etc. to use more LUT's? I.e., would you loose the
advantages of your design by using their cpu? If the loss is minimal, then
perhaps you could scale up their design to your needs.
Rod Pemberton
Guy Macon
Rod Pemberton wrote:
>Is this a one-time FPGA cpu? I.e., do you have hopes of
>commercial success? Against x86 and/or ARM? No offense
>to FORTHers here, but IMO FORTH oriented cpu's haven't
>had much market success... ever.
Ho hum, another Usenet poster bloviating about which CPUs
have the most commercial success while mentioning only
bit players who have a tiny share of the total market.
x86, ARM, PIC, and even the mighty 8051 are niche products
compared to microcontrollers made by by GeneralPlus/SunPlus,
Elan/EMC, WinBond, Sonix, etc. This is an entire world
that is invisible to you unless you are a designer of
talking Barbie dolls, computer mice, or musical greeting
cards. In this world, nearly 100% of the software is
written in highly optimized assembly language with Forth
-- and AFAICT only Forth -- making some small inroads.
>If one is designing a small cpu in an FPGA, I think one
>is better off by adopting a new but simple cpu paradigm
>with biases from the older commercially successful designs
>like 6502, Z80, 8086 [...] you could do something like
reduce the 6502 instruction set to 10-20 instructions,
add more registers, make the instructions orthogonal,
and extend it to 64-bits.
That pretty much describes the high end of the chips I
listed above (the low end has devices with things like
hardware state machines or things that look like really
tiny programmable logic devices with the "programming"
in masked ROM). The tendency here is to have fewer
registers, fewer instructions, and tiny amounts of RAM
-- 64 bytes is typical -- along with huge amounts of
masked ROM (to hold the audio so that Elmo can talk).
The good news for toymakers is that many of these chips have
been simplified to the point where the die has a ring of
wirebonding pads that can't get any smaller and a fixed
space in the middle, and thus simplifying/shrinking the
actual CPU any further does not lower costs. This is why
there are no new 4-bit designs on the low end. The chip
manufacturers tend to buy obsolete fab technology from the
big boys, and as time goes on they are able to use smaller
and smaller feature sizes, thus allowing more power to fit
inside that ring of pads. Some day we might be able to get
a 68000 or a 80486 instead of a stripped down 6502 or worse.
--
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>
Guy Macon <http://www.GuyMacon.com/> Guy Macon <http://www.GuyMacon.com/>
Frank Buss
> x86, ARM, PIC, and even the mighty 8051 are niche products
> compared to microcontrollers made by by GeneralPlus/SunPlus,
> Elan/EMC, WinBond, Sonix, etc. This is an entire world
> that is invisible to you unless you are a designer of
> talking Barbie dolls, computer mice, or musical greeting
> cards. In this world, nearly 100% of the software is
> written in highly optimized assembly language with Forth
> -- and AFAICT only Forth -- making some small inroads.
My optical Dell computer mouse (costs 10 Euro, when buying as additional
equipment with a PC) has a CY7C63813, even in DIP case. Arrow has the SOIC
version for $2.94 for single units. It has 8k flash and 256 bytes RAM. With
an optimizing C compiler I think it should be possible to implement a mouse
device for it in C. The M8C instruction set is more powerful than 8051, but
the core is slow. But doesn't matter for many applications.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
rickman
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:87c235a4-ee3d-477f...@34g2000hsh.googlegroups.com...
>
> > I have an application that would be well served by a small (or perhaps
> > "tiny" is the right word) CPU in an FPGA. The current design is
> > pushing 2000 LUTs and it is a 3000 LUT chip. The logic is mostly very
> > slow, so much of the current design could be done in the CPU allowing
> > much room for future expansion.
>
> "small cpu" and "slow". Here comes the obvious question... Something wrong
> with 6502 or modern variants, Z80/Z80000, or older x86, ARM or the BASIC
> Stamp (microcontroller w/BASIC interpreter)? Why are you designing your own
> when so many cheap embedded market cpu solutions exist?
Yes, all of the devices you mention are huge compared to my board,
which, btw, is already designed an in production. I guess this was
explained in another thread elsewhere and I didn't include the
background here.
The current design is in a small FPGA, 3100 LUTs, and is using about
2000 of them. There is even a 16 x 16 multiplier which is using a
chunk, but not an overly large portion. My customer for this board
has indicated an interest in adding more functionality (which, btw, I
had suggested initially and was told it was much more than was
needed...:^) which may start to push the bounds of the device if done
purely in logic. I don't expect it would be a big problem, but until
a spec is provided you can't tell and this customer is not good at
providing specs.
So a small CPU could take care of all of the slower logic (higher
level protocol) and direct hardware would handle the CODEC serial
interface and various timing synchronization. I would also have
enough room for smarts which could do a pretty thorough self test.
> > I asked in C.A.E and learned about the ZPU design which is open source
> > and GPL licensed. Oddly enough when I looked at it, it is a stack CPU
> > that is remarkably similar to one I designed some 6 years ago
> > specifically to run a forth like language as native machine code.
> > This one is smaller so it might well prefer it to my own. Also it is
> > supported by GCC.
>
> Is this a one-time FPGA cpu? I.e., do you have hopes of commercial success?
> Against x86 and/or ARM? No offense to FORTHers here, but IMO FORTH oriented
> cpu's haven't had much market success... ever. Parallex produces Stamps
> with languages other than BASIC: Java, SPIN. They have one version with 8
> 32-bit cores and a built in byte code interpreter... If someone created a
> "FORTH Stamp", possibilities?
I don't understand where you are going with this. I am looking for a
***small*** cpu for an FPGA. No one said anything about competing
against Intel or ARM. I thought this would have been clear from my
description of hundreds of LUTs vs. some 7000 logic elements in the
Actel ARM version (IIRC). Please don't go off the deep end about
this.
> If one is designing a small cpu in an FPGA, I think one is better off by
> adopting a new but simple cpu paradigm with biases from the older
> commercially succesful designs like 6502, Z80, 8086 or modern like ARM,
> Stamp. E.g., you could do something like reduce the 6502 instruction set to
> 10-20 instructions, add more registers, make the instructions orthogonal,
> and extend it to 64-bits. I'd say skip all the advanced and complicated
> stuff (CISC,VLIW, EPIC) and make it simple and easy for you to program.
The 6502 and 8080 derived CPUs were dogs compared to today's
architectures. A lot has been learned over the years about
instruction sets and optimizing hardware for speed, power, size and
ease of use. The ARM is much bigger than what I need and I don't have
the several million to license it... well maybe if I got a good price
and sold a couple of houses...
Who said anything about "complicated stuff"??? I don't think I have
seen your posts before, but this reply has you assuming a lot from
what I said in my post. BTW, didn't you see the part where I said
there was a GCC compiler for the ZPU? Isn't C a simple enough
programming language??? Alternatively, I don't think you can get much
simpler then Forth... or is it you can *only* get simpler than
Forth... I'm not too sure. But it is definitely one of those
two... ;^)
> > To be honest, if I could use a core like this with a Forth development
> > environment, I would prefer that. But I have yet to find Forth tools
> > that even support arbitrary processors (ala GCC) much less provide a
> > good debugging environment. I know the Forth philosophy seems to be
> > that you can roll your own, but this is no small task if you want
> > "good" tools. I remember Brad creating TinyBoot and ultimately
> > abandoning it because it was too much work to make it as good as the
> > commercial tools. With my CPU, I used the HDL simulator to debug my
> > code since it was very small and not at all complex. This would be
> > harder with my current application because the time frame for the
> > running code is seconds which takes a long time to simulate.
>
> > I may stick with my core and continue to create code in Forth/assembly/
> > machine language. Or I may try the same approach with the ZPU.
>
> The ZPU website indicates they use 298 or 442 LUT's. I lost much interest
> in EE about the time FPGA's were gaining much market success. So, I'm not
> familiar with what level of complexity or scale that represents for a cpu in
> an FPGA. But, you stated that your cpu has about 2000 LUT's. That seems
> like a substantially larger amount. Is your cpu more functional, faster,
> more registers, etc. to use more LUT's? I.e., would you loose the
> advantages of your design by using their cpu? If the loss is minimal, then
> perhaps you could scale up their design to your needs.
No, I said my hardware design uses about 2000 LUTs. Actually I have
no idea why it is so large unless the multiplier is using a bigger
hunk than I realize. But my stack CPU uses about 600 LUTs and I think
that may be putting registers in FFs since it was compiled for an
older Altera architecture. Using a ram in LUT architecture I may be
significantly smaller... no, I forgot, it doesn't have registers... it
has stacks and memory. The only registers are maybe a dozen total
throughout the whole chip including the PSW, top of stacks, stack
pointers and such. Actually, I just counted and there are a total of
10 registers, some 16 bits wide (data), others 12 bits wide (address)
and some 8 bits (instruction path). So that is not making it large.
I need to work the design for modern registered memory (block rams)
and recompile to see what it takes and see where the size is. Still,
600 LUTs is not bad. But it was not too fast, 55 MHz in an ACEX
part. I expect with block rams and a bit of optimizing it should push
100 MHz in a current chip. But I only need 25 MHz in this design
which is the fastest clock.
I just don't have the time to dig into it at the moment. I have to
finish up some details and get a shipment out this week. Maybe in a
couple of weeks I'll get back to this and compare the ZPU to my CPU.
Rick
rickman
> Rod Pemberton wrote:
> >Is this a one-time FPGA cpu? I.e., do you have hopes of
> >commercial success? Against x86 and/or ARM? No offense
> >to FORTHers here, but IMO FORTH oriented cpu's haven't
> >had much market success... ever.
>
> Ho hum, another Usenet poster bloviating about which CPUs
> have the most commercial success while mentioning only
> bit players who have a tiny share of the total market.
Don't worry about this guy. He either didn't understand what I was
asking about or has seem some other oddball stuff that he is confusing
with what I said. Either way I think he just needs to hear more about
this and I think he will see that I am not asking for anything really
"out there" (except maybe the using Forth stuff... ;^).
> x86, ARM, PIC, and even the mighty 8051 are niche products
> compared to microcontrollers made by by GeneralPlus/SunPlus,
> Elan/EMC, WinBond, Sonix, etc. This is an entire world
> that is invisible to you unless you are a designer of
> talking Barbie dolls, computer mice, or musical greeting
> cards. In this world, nearly 100% of the software is
> written in highly optimized assembly language with Forth
> -- and AFAICT only Forth -- making some small inroads.
I am curious, who's forth gets used in this context? Is it one of the
big two? A smaller Forth player? Or do they roll their own?
Rick
Stan Barr
wrote:
>
>
>
>Rod Pemberton wrote:
>
>>Is this a one-time FPGA cpu? I.e., do you have hopes of
>>commercial success? Against x86 and/or ARM? No offense
>>to FORTHers here, but IMO FORTH oriented cpu's haven't
>>had much market success... ever.
>
>Ho hum, another Usenet poster bloviating about which CPUs
>have the most commercial success while mentioning only
>bit players who have a tiny share of the total market.
>
>x86, ARM,
I thought ARM was the most popular processor in the world.
Over 3 billion produced last year IIRC.
--
Cheers,
Stan Barr t-bone .at. dial .dot. pipex .dot. com
The future was never like this!
Rod Pemberton
> Don't worry about this guy. He either didn't understand what I was
> asking about or has seem some other oddball stuff that he is confusing
> with what I said. Either way I think he just needs to hear more about
> this and I think he will see that I am not asking for anything really
> "out there" (except maybe the using Forth stuff... ;^).
>
Sorry that I confused you... My post only covered things I thought you
didn't mention in your original post:
1) I asked about scale of your project: personal one-off cpu, small
specialty run, or commercial
2) I asked why an existing solution wouldn't work: cost, complexity, or
specialization, etc.
3) I mentioned a few possible non-FPGA, cpu solutions: older, modern, or
specialty
4) I mentioned some simple cpu design options - which you weren't
interested in...
Good luck,
Rod Pemberton
Rod Pemberton
news:IuOdnT22kuc...@giganews.com...
> >Is this a one-time FPGA cpu? I.e., do you have hopes of
> >commercial success? Against x86 and/or ARM? No offense
> >to FORTHers here, but IMO FORTH oriented cpu's haven't
> >had much market success... ever.
>
> Ho hum, another Usenet poster bloviating about which CPUs
> have the most commercial success while mentioning only
> bit players who have a tiny share of the total market.
What era? And, which market? The 6502 was a large commercial success
during it's era. It was the cheapest and most powerful chip of it's time.
The x86 is a large continuing commercial success in the PC market with
95-99% market share per year. The ARM (and someone else had to update me on
this fairly recently...) is a very large commercial success in the embedded
market (cellphones, PDA's, etc.).
> x86, ARM, PIC, and even the mighty 8051 are niche products
> compared to microcontrollers made by by GeneralPlus/SunPlus,
> Elan/EMC, WinBond, Sonix, etc. This is an entire world
> that is invisible to you unless you are a designer of
> talking Barbie dolls, computer mice, or musical greeting
> cards. In this world, nearly 100% of the software is
> written in highly optimized assembly language with Forth
> -- and AFAICT only Forth -- making some small inroads.
Well, WinBond says their ISDxxxx chips should be programmed in assembly or
C. So, FORTH is an implementors choice, but these 4-bit microcontrollers
don't run FORTH _natively_ anyway... They're not a FORTH microcontroller.
As for volume, you'll have to post links... I don't think your year and
half stint at Mattel eight years ago can provide relevant market data for
today. I don't doubt the musical card, or talking Barbies are decent
numbers. But, I know that while cards may be large numbers, very few cards
are musical cards today. Anyway, if there is public info on their volume, I
didn't find it...
http://www.arm.com/news/19720.html
http://www.xbitlabs.com/news/cpu/display/20070802231958.html
http://www.eetimes.com/rss/showArticle.jhtml?articleID=189602065
Rod Pemberton
Rod Pemberton
news:slrng874pe...@citadel.metropolis.local...
> >>commercial success? Against x86 and/or ARM? No offense
> >>to FORTHers here, but IMO FORTH oriented cpu's haven't
> >>had much market success... ever.
> >
> >Ho hum, another Usenet poster bloviating about which CPUs
> >have the most commercial success while mentioning only
> >bit players who have a tiny share of the total market.
> >
> >x86, ARM,
>
> I thought ARM was the most popular processor in the world.
I didn't...
> Over 3 billion produced last year IIRC.
You IIRC correctly:
http://www.arm.com/news/19720.html
http://www.xbitlabs.com/news/cpu/display/20070802231958.html
http://www.eetimes.com/rss/showArticle.jhtml?articleID=189602065
RP
jacko
> I asked in C.A.E and learned about the ZPU design which is open source
> and GPL licensed. Oddly enough when I looked at it, it is a stack CPU
> that is remarkably similar to one I designed some 6 years ago
> specifically to run a forth like language as native machine code.
> This one is smaller so it might well prefer it to my own. Also it is
> supported by GCC.
I am developing the indi core http://indi.hpsdr.com but at the moment
there are no tools, very low LUT count though. And do you include ROM
in this count? I am developing MID4th for mobile phones 16 bit ANS. I
intend to develop it further so that it may make ROM images for the
indi. I am sure the LUT count can be redued when VHDL specification is
used, but at present only a module based version exists.
> To be honest, if I could use a core like this with a Forth development
> environment, I would prefer that. But I have yet to find Forth tools
> that even support arbitrary processors (ala GCC) much less provide a
> good debugging environment. I know the Forth philosophy seems to be
> that you can roll your own, but this is no small task if you want
> "good" tools. I remember Brad creating TinyBoot and ultimately
> abandoning it because it was too much work to make it as good as the
> commercial tools. With my CPU, I used the HDL simulator to debug my
> code since it was very small and not at all complex. This would be
> harder with my current application because the time frame for the
> running code is seconds which takes a long time to simulate.
I intend an IO area with display of it, and a dynamic decompilier
showing trace information.
> I may stick with my core and continue to create code in Forth/assembly/
> machine language. Or I may try the same approach with the ZPU. Or I
> may use the GCC tools with ZPU. But I thought I would ask if anyone
> had done anything with the ZPU?
Never used it.
cheers jacko
rickman
common that when I start a thread in C.L.F it often gets hijacked to
discuss something of a personal nature and not on topic.
I understand how discussions migrate as they evolve, but this is going
to make it very hard for me to find with wheat in the chaff (if there
is any).
How about starting a new thread to discuss single chip MCUs?
Rick
Brad Eckert
Maybe Bernd Paysan's B16 is what you're looking for. It's simple
enough to understand and programs in Forth.
Or, you could use OpenFire, which is mostly binary compatible with
Microblaze but open source and a little smaller.
Most classic processor designs have a lot of muxes so they use up a
lot of LUTs. They are FPGA hogs. Processors like the OpenFire and
Microblaze use fewer LUTs because they were designed with FPGA
implementation in mind. Apparently the ZPU is one of these, since it's
so small.
Brad
Guy Macon
The "Forth" that was (and may still be -- I purposely do
not ask curent employees about the internal workings of
the engineering department other than what I need to know
to do a particular consulting job) in use at Mattel was
a Forthlike language based on a collection of existing
highly optimized assembly lnguage routines and principles
that came from the books starting forth and thinking forth.
It had/has everything one needs to program a toy, and nothing
that does not advance that goal. I am the one who introduced
Forth, after several engineers claimed that *no* language
other than hand-coded assembly could work in our environment.
I am really quite pleased with the results. Consider what
releasing code a day or two earlier means at production rates
topping 100,000 toys per hour...
Alas, I can't give more details without revealing too much to
the Hasbro spies who are reading this. :)
rickman
I took a look at OpenFire and couldn't find any info on its size. But
since it is a 32 bit processor, I expect it will not be as small as
the other candidates.
I had looked at the B16 a long time ago and didn't think it was really
suitable for an FPGA internal core. I want to say it is designed for
a 16 bit external RAM rather than internal memory. I also don't know
that there are any tools available for it. Has anyone else ended up
using it?
> Most classic processor designs have a lot of muxes so they use up a
> lot of LUTs. They are FPGA hogs. Processors like the OpenFire and
> Microblaze use fewer LUTs because they were designed with FPGA
> implementation in mind. Apparently the ZPU is one of these, since it's
> so small.
Yes, muxes are very expensive in an FPGA. Basically they are the same
amount of logic as multipliers. A 16 input, 16 bit mux uses the same
resources as a 16 x 16 multiplier, give or take. A stack processor
doesn't inherently have fewer muxes than does a register based
design. Any architecture has to be optimized for few muxes, but
usually at the expense of needing more clock cycles to do the various
data transfers.
Rick
jacko
Guy Macon
Rod Pemberton wrote:
>Well, WinBond says their ISDxxxx chips should be programmed in assembly or
>C. So, FORTH is an implementors choice, but these 4-bit microcontrollers
>don't run FORTH _natively_ anyway... They're not a FORTH microcontroller.
Right. I should have been clear that I was responding to comments
about x86s and ARMs, not uCs that run Forth directly.
>I don't think your year and half stint at Mattel eight years
>ago can provide relevant market data for today.
It isn't the 8 years that are a problem. My last consulting job
in the toy industry was a couple of months ago. The problem is
that someone working at Mattel only knows how many uCs Mattel
buys, not the worldwide market.
>Guy Macon <http://www.GuyMacon.com/> wrote
>
>> Ho hum, another Usenet poster bloviating about which CPUs
>> have the most commercial success while mentioning only
>> bit players who have a tiny share of the total market.
>
>What era?
Today.
>And, which market?
The entire world.
>The 6502 was a large commercial success during it's era.
6502 variants made by SunPlus are *still* a large commercial
success.
>The x86 is a large continuing commercial success in the PC market with
>95-99% market share per year.
Share of what? The PC market?
>As for volume, you'll have to post links...
Here are some claimed niumbers (many of which I don't believe;
the various uC makers who have sales only in Taiwan, production
in China, uCs selling for under 10 cents each, and minimum orders
of a millon masked-ROM units do NOT release sales figures).
According to
http://www.reuters.com/article/technologyNews/idUSL2324525420080623
The number of personal computers in use around the world has
just passed 1 billion.
According to
http://news.cnet.com/Running-the-numbers-on-Vista/2100-1016_3-6207375.html
128 million PCs were sold worldwide in 2001, 239 million in 2006.
Most of those PCs have uCs in the hard drive, CD-ROM drive, mouse,
keyboard, monitor, printer, USB flash drive, modem, etc. etc...
According to
http://www.electronics.ca/presscenter/articles/580/1/New-Study-Predicts-10-percent-Growth-for-Microcontrollers/Page1.html
total microcontroller sales are about 11 billion per year.
According to
http://academic.csuohio.edu/simond/courses/eec417/
total microcontroller sales topped 12 billion in 2002
http://www.ucpros.com/Newsletter/newsletter%202003%2011.htm
predicts 7 billion units in 2007
http://www.metrics2.com/blog/2006/11/16/global_semiconductor_sales_to_hit_321b_in_2009_at_1.html
has some info on revenue, keeping in mind that Intel makes
a lot more money per unit than the uC sellers do.
According to http://www.researchwikis.com/Toys_Market_Research
the the toy industry sells around 70 billion dollars worth of toys
every year, and according to http://www.nanovip.com/node/1843,
35% of that is electronic toys. The figure thrown around at Mattel
is 10%, so I suspect that the 35% figure includes things like
Xboxs and playstations.
Here is one good reason why I dount many of the above figures;
according to http://www.globalsources.com/gsol/I/Button-cell-battery/a/9000000085339.htm
6 billion button-cell batteries make up 20% of the global market.
That's 30 billion per year.
Very few button cells go into a product with no mivrocontroller,
but many products with microcontrollers don't use button cells
-- they use AAA or AA cells.
Again, I see no evidence that any of the above numbers include
unit sales from uC makers who have sales only in Taiwan,
production in China, uCs selling for under 10 cents each,
and minimum orders of a millon masked-ROM units
Rod Pemberton
> Can I ask that you guy discuss this somewhere else. I find it very
> common that when I start a thread in C.L.F it often gets hijacked to
> discuss something of a personal nature and not on topic.
I'm sorry that I offended you. But, this isn't a Google Group. You seem to
think it is. But, it's not. You posted to an Usenet newsgroup. It's
unmoderated and uncensored.
This is the official Usenet charter for comp.lang.forth:
"Discussion about Forth."
ftp://ftp.uu.net/usenet/control/comp/comp.lang.forth.Z
> not on topic.
I'd say your comments are less about FORTH than mine... Oh, you mean not on
YOUR TOPIC. Whatever...
We're sorry that you're feeling the pressure at work, and you need solutions
quick. But, that's not our problem, is it?...
HTH,
Rod Pemberton
rickman
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:ae569223-2611-4671...@w7g2000hsa.googlegroups.com...
>
> > Can I ask that you guy discuss this somewhere else. I find it very
> > common that when I start a thread in C.L.F it often gets hijacked to
> > discuss something of a personal nature and not on topic.
>
> I'm sorry that I offended you. But, this isn't a Google Group. You seem to
> think it is. But, it's not. You posted to an Usenet newsgroup. It's
> unmoderated and uncensored.
I am totally aware of the status of the Internet. It is pretty much
all lawless and uncontrolled... ***especially google groups***. But
that doesn't mean you have to be rude. I hadn't taken offense, at
least not until now. I was just asking that you take the discussion
to a new thread.
I made a simple request based on the fact that I was trying to get
some information that others might be aware of and willing to share.
But the thread has turned into a sparring contest between a couple of
people on unrelated topics.
> This is the official Usenet charter for comp.lang.forth:
>
> "Discussion about Forth."ftp://ftp.uu.net/usenet/control/comp/comp.lang.forth.Z
You can talk about anything you want. I am just asking that you do it
in another thread. Is that really an unreasonable request???
> > not on topic.
>
> I'd say your comments are less about FORTH than mine... Oh, you mean not on
> YOUR TOPIC. Whatever...
Yes, your posts in this thread are not on *my* topic, the basis of
this thread. Check the subject line that you are posting under. It
doesn't say anything about competing against Intel or subverting ARM
or how classy the venerable 6502 is. It is about tiny CPUs in
programmable logic.
> We're sorry that you're feeling the pressure at work, and you need solutions
> quick. But, that's not our problem, is it?...
But of course, you can't just respond in a civilized manner and honor
my request. You have to make disparaging remarks. No, my interests
are not your problem. So why are you making them your problem???
I'm not trying to be a jerk. I'm just trying to keep this thread on
the topic of tiny CPUs in programmable logic. Why not start a new
thread for the other CPUs you are discussing?
I will say that this is often a lot bigger issue in this group than
any other that I post in. People tend to wander into a thread,
migrate the topic to new ground and then post forever leaving the OT
in the dust.
Rick
Guy Macon
rickman wrote:
>I am totally aware of the status of the Internet. It is pretty much
>all lawless and uncontrolled... ***especially google groups***.
Why are you talking about Google Groups? This isn't Google
Groups. This is Usenet. Yes, I know that Google tells fibs
and says that the info they scrape from Usenet is part of
Google Groups, but that doesn't make it true. Usenet was
here long before Google Corporation,, and will be here long
after Google Corp. goes the way of Quantum Link.
See [ http://en.wikipedia.org/wiki/Quantum_Link ].
Bernd Paysan
> I had looked at the B16 a long time ago and didn't think it was really
> suitable for an FPGA internal core. I want to say it is designed for
> a 16 bit external RAM rather than internal memory. I also don't know
> that there are any tools available for it. Has anyone else ended up
> using it?
You can't have looked at the b16 I've loaded up. It uses an internal RAM,
but can also use an external one (the internal RAM of small FPGAs is often
small). Anyway, it's a *core*, it's up to you to connect it.
There's an assembler, simulator, and a small bootloader available for it,
it's part of the distribution. You might have missed it, because it's only
a few hundred lines long ;-).
We had a student who build a proof-of-the-concept C compiler with an old
stack-based compiler kit (was easier to do than with GCC), but it's not
ready for use.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
rickman
> rickman wrote:
> >I am totally aware of the status of the Internet. It is pretty much
> >all lawless and uncontrolled... ***especially google groups***.
>
> Why are you talking about Google Groups? This isn't Google
> Groups. This is Usenet.
Maybe you need to read and quote more of the post...
rickman wrote:
>
> On Jul 21, 7:32 pm, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> >
> > I'm sorry that I offended you. But, this isn't a Google Group. You seem to
> > think it is. But, it's not. You posted to an Usenet newsgroup. It's
> > unmoderated and uncensored.
>
> I am totally aware of the status of the Internet. It is pretty much
> all lawless and uncontrolled... ***especially google groups***. But
Do you see where I was responding to Rod? Is there something wrong
with replying to the comments of a post?
Rick
rickman
> rickman wrote:
> > I had looked at the B16 a long time ago and didn't think it was really
> > suitable for an FPGA internal core. I want to say it is designed for
> > a 16 bit external RAM rather than internal memory. I also don't know
> > that there are any tools available for it. Has anyone else ended up
> > using it?
>
> You can't have looked at the b16 I've loaded up. It uses an internal RAM,
> but can also use an external one (the internal RAM of small FPGAs is often
> small). Anyway, it's a *core*, it's up to you to connect it.
Sorry, I was working from memory. I looked at the docs and it would
seem that I was remembering some other CPU. The B16 is a like my CPU
in using dual stacks. But I don't see any real advantages. The size
is about the same (600 LUTs) and that number does not include
interfacing which mine does. It also seems to run a bit slow, but
that may be more a function of the chip used rather than design.
I couldn't tell from the document if the memories are registered like
block rams in FGPAs or if they are designed as async RAMs which is no
longer supported in most current FPGAs.
> There's an assembler, simulator, and a small bootloader available for it,
> it's part of the distribution. You might have missed it, because it's only
> a few hundred lines long ;-).
>
> We had a student who build a proof-of-the-concept C compiler with an old
> stack-based compiler kit (was easier to do than with GCC), but it's not
> ready for use.
I have not dug through the downloads. I did a search and found that
there seems to be a newer version that is reduced in size. I may take
a look at that.
Rick
Bernd Paysan
> Sorry, I was working from memory. I looked at the docs and it would
> seem that I was remembering some other CPU. The B16 is a like my CPU
> in using dual stacks. But I don't see any real advantages. The size
> is about the same (600 LUTs) and that number does not include
> interfacing which mine does. It also seems to run a bit slow, but
> that may be more a function of the chip used rather than design.
Altera or Xilinx LUTs? My number are Altera LUTs, which have about half the
capability of Xilinx, and it was the "large" version. The chip was quite
slow, indeed; the b16 runs between 250 and 500MHz in 0.18µ (real
TSMC-compatible silicon, standard gates), depending on which version you
use (small=slow, large=faster).
Rod Pemberton
You mentioned 3 cores that'll fit (~2000 of 3100 LUTs... ~1100 to go).
What's the problem? Pick one. Or, two even:
ZPU (16-bit 298 LUTs)
ZPU (32-bit 442 LUTs)
16-bit core by "rickman" (600 LUTs)
(If you own the "rickman" 16-bit core, not your employer, be smart and sell
it to them...)
> Do you see where I was responding to Rod? Is there something wrong
> with replying to the comments of a post?
I didn't think so... But, you said I was wrong. Can't have it both ways...
Because, that doesn't make sense. But, neither does posting about LUTs
and FPGA's in comp.lang.forth instead of comp.arch.fpga...
> rude
You asked for help about something "off-topic" and then rejected what help
was provided by those who had something to offer as being "off-topic
off-topic"... What type of response did you expect? Does this make any
sense to you?
RP
rickman
> rickman wrote:
> > Sorry, I was working from memory. I looked at the docs and it would
> > seem that I was remembering some other CPU. The B16 is a like my CPU
> > in using dual stacks. But I don't see any real advantages. The size
> > is about the same (600 LUTs) and that number does not include
> > interfacing which mine does. It also seems to run a bit slow, but
> > that may be more a function of the chip used rather than design.
>
> Altera or Xilinx LUTs? My number are Altera LUTs, which have about half the
> capability of Xilinx, and it was the "large" version. The chip was quite
> slow, indeed; the b16 runs between 250 and 500MHz in 0.18µ (real
> TSMC-compatible silicon, standard gates), depending on which version you
> use (small=slow, large=faster).
I have to say I have never seen a 2:1 difference in LUT usage between
Altera and Xilinx. I have seen more like a 10% or 205 difference and
this can go either way. I think there is more of a difference in the
tools than there are the chips, but both are constantly evolving.
My numbers were from a design done in an ACEX 1K. Which of the Altera
chips were your numbers from?
I need to rework my design a bit to make it compatible with the block
rams in current devices. The ACEX 1K parts still supported an async
mode which was used for the main memory block while sync rams were
used for the stack modules and a sync dual port was used for the
instruction ram. Changing the main memory design will add a clock for
each fetch or I will have to perform a memory fetch on each clock
cycle in anticipation of the next instruction being a memory read
which would use a bit more power.
Ala Mick and Brick, the slow path in the design is the flag
computation, mostly from the return stack pointer arithmetic, IIRC.
At some point I may return to work on this design, but it is a labor
of love at this point. I used it in a very small application which
only needed a very small program. Otherwise it would have been too
much work to develop tools and such. We'll see if I need a CPU in
this design in the coming months or not. It looks like there are
several good candidates without continuing to roll my own.
Rick
Bernd Paysan
> I have to say I have never seen a 2:1 difference in LUT usage between
> Altera and Xilinx. I have seen more like a 10% or 205 difference and
> this can go either way. I think there is more of a difference in the
> tools than there are the chips, but both are constantly evolving.
Hm, many people use the CLB count in Xilinx as "LUTs", and a Xilinx CLB
equals exactly 2 Altera LUTs. Has caused significant confusion in the past
(the Xilinx tools report CLBs, not LUTs).
If you break it down to real LUTs, the difference should be small, and go
either way (similar tool quality assumed).
rickman
> rickman wrote:
> > I have to say I have never seen a 2:1 difference in LUT usage between
> > Altera and Xilinx. I have seen more like a 10% or 205 difference and
> > this can go either way. I think there is more of a difference in the
> > tools than there are the chips, but both are constantly evolving.
>
> Hm, many people use the CLB count in Xilinx as "LUTs", and a Xilinx CLB
> equals exactly 2 Altera LUTs. Has caused significant confusion in the past
> (the Xilinx tools report CLBs, not LUTs).
>
> If you break it down to real LUTs, the difference should be small, and go
> either way (similar tool quality assumed).
As to the equivalence of Xilinx CLBs to any other metric, Xilinx
counts their CLBs as 2.25 LUTs!!! They claim that their CLB (slice
actually, the CLBs are anything from 1 to 4 slices with a slice having
2 LUTs) have more logic which they need to account for. Check their
data sheet. They show an XC3S100E as having 240 CLBs, 960 slices and
2,160 "logic cells". I guess "a logic cell is not a LUT" is the moral
of this story.
BTW, anyone who counts slices in place of LUTs is doing their design a
disservice. A slice is counted as used if just one LUT or one FF is
used. Obviously there will be more spare capacity than would be shown
by a slice count. This is especially true when using a smaller
fraction of a Xilinx part. A Xilinx user really needs to count LUTs
and FFs or they are not seeing the correct picture.
Rick
jacko
well if you try to find out anything about the ZPU instruction set,
(rickman seems to be the one promoting anyones interest), you can only
find a slide show which then does an unnecessary activeX to download
flash 9 (for static slide show?) AND IT NEEDS A REBOOT, WHICH SEEMS SO
TROJAN AS TO BE UNBELIVEABLE, (explorer plug in needs reboot?? don't
think so!), so industrial espionage with the profits of toys and spy
babies, being so important to fuck wits (its seems nowadays as the
oilies are paranoid).
Basically I've never seen such a hard to get hold of instruction set
architecture, and this is BSD (supposedly).
cheers
rickman
Like a lot of open source offerings, the documentation leaves
something to be desired. But there is a page in the CVS depository
describing the instruction set.
http://www.opencores.org/cvsweb.shtml/zpu/zpu/docs/zpu_arch.html?rev=1.6;content-type=text/plain
I'm not sure if this will take you to it. Opencores seems to put some
extra pages between you and the files.
There are some anomalies with the doc. It lists the LOAD instruction
twice with the same opcode, but two different descriptions.
You can see that this CPU was designed with C in mind. It has but one
stack and has stack pointer relative instructions. My stack CPU has
two stacks and everything is done on one, the other or both stacks
unless it is a memory load and store.
I am looking forward to working on my CPU some more.
Rick
Jecel
post. It is a variable length Forth processor called Nibbler. The data
paths and memories are four bits wide and the instructions have the
following format:
bit 3 - op
bit 2 - mode
bits 1, 0 - value
The "op" field selects between "push literal" (0) and "call" (1). The
"mode" indicates "in the instruction" (0) or "following the
instruction" (1). The last two bits is the operand in mode 0, or the
size of the operand in mode 1. A size of 00 is not valid and indicates
that the following nibble has the actual size (where 0 is defined to
mean 16). This allows operands of up to 64 bits.
The registers are PC (instruction pointer), RP (return stack pointer)
and DP (data stack pointer). The stacks are in memory and grow
upwards. Since variable sized data can be pushed on the stack, the
nibble pointed to by RP or DP has the size of the item just under it.
The registers are wide enough to address all memory but their actual
size isn't visible to the programmer.
Calls with mode 0 (instructions 1000 to 1011) or with operands 4 bits
wide (instructions 1101 0000 to 1101 1111) invoke the built in
primitives, so we have 1 (push) + 1 (call) + 4 + 16 = 22 instructions
in all. By carefully selecting the four most frequent instructions as
the mode 0 ones the average size shouldn't be that much over the 5
bits of MISCs. The load and store instructions should have an extra
argument saying the size of the operand in main memory. Another
version of load and store could leave the size tag as used on the
stacks.
-- Jecel
rickman
Can you explain what the intent of this design is? What is being
optimized and what is being sacrificed?
Rick
Jecel
> Can you explain what the intent of this design is? What is being
> optimized and what is being sacrificed?
The main goal was to see how to make the most scalable design
possible, going both way down (with a 4Kbit memory you only need three
10 bit registers) and way up (it could directly address many GB of
memory). I was also trying to have a compressed main memory to fit as
much as possible into whatever the machine has. A third goal was that
the implementation itself should be very small (not having done an
implementation nor even a detailed design, I don't know how well it
would do in this regard).
Performance is sacrificed in a big way, though my experience with
FPGAs is that sometimes you gain enough in clock rate by making things
narrower to partly offset the costs of being more serial. There is
also some overhead both in space and time due to the size fields
everywhere. Another thing that is sacrificed is the simple programming
model you get with fixed width cells in Forth. You need more than one
kind of load/store instructions and have to keep track of when to use
one or the other. You will also need extra instructions in many places
to keep this more complicated scheme working.
-- Jecel
rickman
> On Jul 27, 11:34 am, rickman wrote:
>
> > Can you explain what the intent of this design is? What is being
> > optimized and what is being sacrificed?
>
> The main goal was to see how to make the most scalable design
> possible, going both way down (with a 4Kbit memory you only need three
> 10 bit registers) and way up (it could directly address many GB of
> memory). I was also trying to have a compressed main memory to fit as
> much as possible into whatever the machine has. A third goal was that
> the implementation itself should be very small (not having done an
> implementation nor even a detailed design, I don't know how well it
> would do in this regard).
I think it will be fairly small. With so few registers it shouldn't
have too many interconnects for the data. Coupled with the small data
path, that should make it very small. The control logic may be a bit
more complex because it will require multiple clock cycles to execute
a given instruction. But that looks to be fairly simple too.
> Performance is sacrificed in a big way, though my experience with
> FPGAs is that sometimes you gain enough in clock rate by making things
> narrower to partly offset the costs of being more serial. There is
> also some overhead both in space and time due to the size fields
> everywhere. Another thing that is sacrificed is the simple programming
> model you get with fixed width cells in Forth. You need more than one
> kind of load/store instructions and have to keep track of when to use
> one or the other. You will also need extra instructions in many places
> to keep this more complicated scheme working.
Yes, this will have poor performance in terms of work per clock
cycle. The clock speed may or may not be fast however. There are any
number of things that limit CPU speed other than the data path. Your
PC still has to calculate jumps and calls. In an FPGA the stack can
be a speed limiting operation. You also have to consider the details
of implementation. Most paper designs treat memory as async. Most
FPGAs use sync memory with at least one internal register. So you need
to consider how to make that fit your design from the start.
The performance may or may not be an issue. That depends entirely on
the application. It is nice to design screamers, but mostly you just
need something simple that will work.
Rick
jacko
1. both a direct and a double indirect mode [-[val]+] are needed for
addressing. (1 bit)
2. 2 registers IP and working reg. (1 bit)
3. load and store operations (1 bit)
4. on load (+,??,xor,=) on store (2*,??,0,=) (2 bits)
So thats 5 bits op and any width dat per memory cell.
total number of memory cells is 2^(cellwidth-5)
What would be your favorite ?? pair for low logic AND good function.
A null memory store is when a direct store is left unused by never
being reloaded double indirect.
very simple processor.
Frank Buss
That's already a very complicated processor. Try this one:
http://en.wikipedia.org/wiki/Universal_Turing_machine
:-)
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
jacko
put the double indirect as a single indirect/no pre-post.
use wide acces to memory and the serial shift register adder cycles
can be a memory buffer shifter cycles, with equality latch, reducing
decode logic size to memory.
variables store conviniently atsome direct location (most used one)
and indirectly accessed everywhere else. A profile tool anyone??
AND is not my wishful choice for ?? as it is also =.
e.g. A AND A = A or store routing.
cheers.
jacko
>
> - Show quoted text -
The ALU routing can be made much simpler if the load ops are
(+,AND 2*+c,XOR,NIP) assuming top of stack is IN and second is A
this gives the SYMETRIC save ops
(2*+c,2*+c,0,NOP)
but this wastes one opcode by repetition and may make the program more
complex.
An extra or gate ?
AND 2* and 2* become the second operation?
Futher multiplexer reduction may be done, by always using the last in
latch on the stores.
not too interesting (all ones better but needs gates, but absorbed
into 4 in LUT)
(+,AND 2*+c,XOR,NIP) and (1-+c,2*+c,NOT,NOP)
A reasonably nice 8 instruction CPU?
(IN op A -> A) for load operations
(-1 op A -> OUT) for store operations
Thats my simplest, with carry, one input or sumation inhibit
controlling the op.
cheers
Guy Macon
Frank Buss wrote:
>That's already a very complicated processor. Try this one:
>
>http://en.wikipedia.org/wiki/Universal_Turing_machine
I did, but the infinitely long paper tape filled
the entire universe so I had to start over. :(