On Wednesday, October 17, 2018 at 11:37:14 AM UTC-4, Niklas Holsti wrote:> On 18-10-17 17:08 , gnuarm.deletethisbit@gmail.com wrote: > > On Wednesday, October 17, 2018 at 2:35:46 AM UTC-4, Niklas Holsti > > wrote: > >> On 18-10-17 01:46 , David Brown wrote: ... > >>> When I am faced with someone else's code to examine or maintain, > >>> I often run it through Doxygen with "generate documentation for > >>> /everything/ - caller graphs, callee graphs, cross-linked source, > >>> etc." It can make it quick to jump around in the code. And > >>> recursive (or re-entrant, whichever you prefer) code stands out > >>> like a sore thumb, as long as the code is single-threaded - you > >>> get loops in the call graphs. > >> > >> Anecdote: some years ago, when I was applying a WCET analysis tool > >> to someone else's program, the tool found recursion. This surprised > >> the people I was working with, because they had generated call > >> graphs for the program, analysed them visually, and found no > >> recursive, looping paths. > >> > >> Turned out that they had asked the call-graph tool to optimize the > >> size of the window used to display the call-graphs. The tool did as > >> it was told, with the result that the line segments on the path for > >> the recursive call went down to the bottom edge of the diagram, > >> then *merged* with the lower border line of the diagram, followed > >> that lower border, went up one side of the diagram -- still merged > >> with the border line -- and then reentered the diagram to point at > >> the source of the recursive call, effectively making the loop very > >> hard to see... > >> > >> (It turned out that this recursion was intentional. At this point, > >> the program was sending an alarm message, but the alarm buffer was > >> full, so the alarm routine called itself to send an alarm about the > >> full buffer -- and that worked, because one buffer slot was > >> reserved, by design, for this "buffer full" alarm.) > > > > Seems to me what actually failed was that they knew they had > > recursion in the design but didn't realize the fact that they didn't > > see the recursion in the call graphs was an error that should have > > been caught. > > The guys creating and viewing the call-graphs were not the designers of > the program, either, so they didn't know, but for sure it was something > they should have discovered and remarked on as part of their work.Do you know the intended purpose of the call graphs? It seems to me that it would be to match expectations to what was coded. It shouldn't matter who was doing the evaluation, there should have been an accounting of expectations regarding the presence and/or absence of recursion. Much like a check list, it doesn't just assure the presence of everything on the list, it can be used to verify the absence of anything not on the list. Rick C.
$0.03 microcontroller
Started by ●October 9, 2018
Reply by ●October 17, 20182018-10-17
Reply by ●October 17, 20182018-10-17
Am 17.10.2018 um 18:43 schrieb upsidedown@downunder.com:> > While I have been playing around with the idea of making some RTOS for > such 1kW/64B machine (realistically supporting 2-3 tasks such as a > foregroud/bacground monitor) realistically having 2 or 8 thread is no > very realistic, even if the hardware supports it. > > The 8 core version might be usable for xCore style "pseudo-interupts" > running a single DSP sample or PLC loop at a time. This would require > 8 input pins, each starting its own thread. > > But of course, the same rules should apply to pseudo-interrupts as > real interrupts regarding re-entrancy etc. >Since the Padauk doesn't have much in term of integrated peripherals, there is another use for hardware threads: Have each thread do some I/O protocol (I²C, UART, etc) in software. Philipp
Reply by ●October 17, 20182018-10-17
On 18-10-17 20:04 , gnuarm.deletethisbit@gmail.com wrote:> On Wednesday, October 17, 2018 at 11:37:14 AM UTC-4, Niklas Holsti > wrote: >> On 18-10-17 17:08 , gnuarm.deletethisbit@gmail.com wrote: >>> On Wednesday, October 17, 2018 at 2:35:46 AM UTC-4, Niklas >>> Holsti wrote: >>>> On 18-10-17 01:46 , David Brown wrote: ... >>>>> When I am faced with someone else's code to examine or >>>>> maintain, I often run it through Doxygen with "generate >>>>> documentation for /everything/ - caller graphs, callee >>>>> graphs, cross-linked source, etc." It can make it quick to >>>>> jump around in the code. And recursive (or re-entrant, >>>>> whichever you prefer) code stands out like a sore thumb, as >>>>> long as the code is single-threaded - you get loops in the >>>>> call graphs. >>>> >>>> Anecdote: some years ago, when I was applying a WCET analysis >>>> tool to someone else's program, the tool found recursion. This >>>> surprised the people I was working with, because they had >>>> generated call graphs for the program, analysed them visually, >>>> and found no recursive, looping paths. >>>> >>>> Turned out that they had asked the call-graph tool to optimize >>>> the size of the window used to display the call-graphs. The >>>> tool did as it was told, with the result that the line segments >>>> on the path for the recursive call went down to the bottom edge >>>> of the diagram, then *merged* with the lower border line of the >>>> diagram, followed that lower border, went up one side of the >>>> diagram -- still merged with the border line -- and then >>>> reentered the diagram to point at the source of the recursive >>>> call, effectively making the loop very hard to see... >>>> >>>> (It turned out that this recursion was intentional. At this >>>> point, the program was sending an alarm message, but the alarm >>>> buffer was full, so the alarm routine called itself to send an >>>> alarm about the full buffer -- and that worked, because one >>>> buffer slot was reserved, by design, for this "buffer full" >>>> alarm.) >>> >>> Seems to me what actually failed was that they knew they had >>> recursion in the design but didn't realize the fact that they >>> didn't see the recursion in the call graphs was an error that >>> should have been caught. >> >> The guys creating and viewing the call-graphs were not the >> designers of the program, either, so they didn't know, but for sure >> it was something they should have discovered and remarked on as >> part of their work. > > Do you know the intended purpose of the call graphs?IIRC they were doing independent SW verification & validation of the program (and the WCET analysis was also a part of that). But it was many years ago, and I don't remember the details well enough to say much more, nor can I say why the program was recursive in this way, or if it could as easily have been made non-recursive. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
Reply by ●October 21, 20182018-10-21
On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin <no.email@nospam.invalid> wrote:>Clifford Heath <no.spam@please.net> writes: >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >> OTP, no SPI, UART or I�C, but still... > >That is impressive! Seems to be an 8-bit RISC with no registers, just >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. >I like that it's in a 6-pin SOT23 package since there aren't many other >MCUs that small.Slightly OT, but I have often wonder how primitive a computer architecture can be and still do some useful work. In the tube/discrete/SSI times, there were quite a lot 1 bit processors. There were at least two types, the PLC (programmable Logic Controller) type replacing relay logic. These had typically at least AND, OR, NOT, (XOR) instructions.The other group was used as truly serial computers with the same instructions as the PLC but also at least a 1 bit SUB (and ADD) instructions to implement all mathematical functions. However, in the LSI era, there down't seem to be many implement ions. One that immediately comes in mind is the MC14500B PLC building block, from the 1970's, which requires quite lot of support chips (code memory, PC, /O chips) to do some useful work. After much searching, I found the (NI) National Instruments SBA (Serial Boolean Analyser) http://www.wass.net/othermanuals/GI%20SBA.pdf from the same era, with 1024 word instructions (8 bit) ROM and four banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. For the re-entrance enthusiasts, it contains stack pointer relative addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 Darlington buffers may be needed to drive loads typically found in PLC environment. Anyone seen more modern 1 bit chips either for relay replacement or for truly serial computers ?
Reply by ●October 21, 20182018-10-21
On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote:> On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > <no.email@nospam.invalid> wrote: > > >Clifford Heath <no.spam@please.net> writes: > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > >> OTP, no SPI, UART or I涎, but still... > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > >I like that it's in a 6-pin SOT23 package since there aren't many other > >MCUs that small. > > Slightly OT, but I have often wonder how primitive a computer > architecture can be and still do some useful work. In the > tube/discrete/SSI times, there were quite a lot 1 bit processors. > There were at least two types, the PLC (programmable Logic Controller) > type replacing relay logic. These had typically at least AND, OR, NOT, > (XOR) instructions.The other group was used as truly serial computers > with the same instructions as the PLC but also at least a 1 bit SUB > (and ADD) instructions to implement all mathematical functions. > > However, in the LSI era, there down't seem to be many implement ions. > > One that immediately comes in mind is the MC14500B PLC building block, > from the 1970's, which requires quite lot of support chips (code > memory, PC, /O chips) to do some useful work. > > After much searching, I found the (NI) National Instruments SBA > (Serial Boolean Analyser) > http://www.wass.net/othermanuals/GI%20SBA.pdf > from the same era, with 1024 word instructions (8 bit) ROM and four > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > For the re-entrance enthusiasts, it contains stack pointer relative > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > Darlington buffers may be needed to drive loads typically found in PLC > environment. > > Anyone seen more modern 1 bit chips either for relay replacement or > for truly serial computers ?]> Anyone seen more modern 1 bit chips either for relay replacement or ]> for truly serial computers ? LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose (Logic Emulation Machine) https://opencores.org/project/lem1_9min Jim Brakefield
Reply by ●October 21, 20182018-10-21
On 10/21/2018 09:27, upsidedown@downunder.com wrote:> On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > <no.email@nospam.invalid> wrote: > >> Clifford Heath <no.spam@please.net> writes: >>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >>> OTP, no SPI, UART or I²C, but still... >> >> That is impressive! Seems to be an 8-bit RISC with no registers, just >> an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, >> enough for plenty of MCU things. Didn't check if it has an ADC or PWM. >> I like that it's in a 6-pin SOT23 package since there aren't many other >> MCUs that small. > > Slightly OT, but I have often wonder how primitive a computer > architecture can be and still do some useful work. In the > tube/discrete/SSI times, there were quite a lot 1 bit processors. > There were at least two types, the PLC (programmable Logic Controller) > type replacing relay logic. These had typically at least AND, OR, NOT, > (XOR) instructions.The other group was used as truly serial computers > with the same instructions as the PLC but also at least a 1 bit SUB > (and ADD) instructions to implement all mathematical functions. > > However, in the LSI era, there down't seem to be many implement ions. > > One that immediately comes in mind is the MC14500B PLC building block, > from the 1970's, which requires quite lot of support chips (code > memory, PC, /O chips) to do some useful work. > > After much searching, I found the (NI) National Instruments SBA > (Serial Boolean Analyser) > http://www.wass.net/othermanuals/GI%20SBA.pdf > from the same era, with 1024 word instructions (8 bit) ROM and four > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > For the re-entrance enthusiasts, it contains stack pointer relative > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > Darlington buffers may be needed to drive loads typically found in PLC > environment. > > Anyone seen more modern 1 bit chips either for relay replacement or > for truly serial computers ? >I have a memory of a 1-bit GPU from the late 70's, but can't pin it down. There is an article on Wikipedia https://en.wikipedia.org/wiki/1-bit_architecture -- Best wishes, --Phil pomartel At Comcast(ignore_this) dot net
Reply by ●October 21, 20182018-10-21
On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote:> On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > > <no.email@nospam.invalid> wrote: > > > > >Clifford Heath <no.spam@please.net> writes: > > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > >> OTP, no SPI, UART or I涎, but still... > > > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > > >I like that it's in a 6-pin SOT23 package since there aren't many other > > >MCUs that small. > > > > Slightly OT, but I have often wonder how primitive a computer > > architecture can be and still do some useful work. In the > > tube/discrete/SSI times, there were quite a lot 1 bit processors. > > There were at least two types, the PLC (programmable Logic Controller) > > type replacing relay logic. These had typically at least AND, OR, NOT, > > (XOR) instructions.The other group was used as truly serial computers > > with the same instructions as the PLC but also at least a 1 bit SUB > > (and ADD) instructions to implement all mathematical functions. > > > > However, in the LSI era, there down't seem to be many implement ions. > > > > One that immediately comes in mind is the MC14500B PLC building block, > > from the 1970's, which requires quite lot of support chips (code > > memory, PC, /O chips) to do some useful work. > > > > After much searching, I found the (NI) National Instruments SBA > > (Serial Boolean Analyser) > > http://www.wass.net/othermanuals/GI%20SBA.pdf > > from the same era, with 1024 word instructions (8 bit) ROM and four > > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > > For the re-entrance enthusiasts, it contains stack pointer relative > > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > > Darlington buffers may be needed to drive loads typically found in PLC > > environment. > > > > Anyone seen more modern 1 bit chips either for relay replacement or > > for truly serial computers ? > > ]> Anyone seen more modern 1 bit chips either for relay replacement or > ]> for truly serial computers ? > > LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose > (Logic Emulation Machine) https://opencores.org/project/lem1_9min > > Jim BrakefieldIt is hard for me to imagine applications where a 1 bit processor would be useful. A useful N bit processor can be built in a small number of LUTs. I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. I discussed this with someone once and he imagined apps where the processing speed requirement was quite low and you can save LUTs with a bit serial processor. I just don't know how many or why it would matter. Even the smallest FPGAs have thousands of LUTs. It's hard to picture an application where you couldn't spare a few hundred LUTs. Rick C.
Reply by ●October 21, 20182018-10-21
On Sunday, October 21, 2018 at 10:08:06 AM UTC-5, gnuarm.del...@gmail.com wrote:> On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote: > > On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > > > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > > > <no.email@nospam.invalid> wrote: > > > > > > >Clifford Heath <no.spam@please.net> writes: > > > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > > > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > >> OTP, no SPI, UART or I涎, but still... > > > > > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > > > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > > > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > > > >I like that it's in a 6-pin SOT23 package since there aren't many other > > > >MCUs that small. > > > > > > Slightly OT, but I have often wonder how primitive a computer > > > architecture can be and still do some useful work. In the > > > tube/discrete/SSI times, there were quite a lot 1 bit processors. > > > There were at least two types, the PLC (programmable Logic Controller) > > > type replacing relay logic. These had typically at least AND, OR, NOT, > > > (XOR) instructions.The other group was used as truly serial computers > > > with the same instructions as the PLC but also at least a 1 bit SUB > > > (and ADD) instructions to implement all mathematical functions. > > > > > > However, in the LSI era, there down't seem to be many implement ions. > > > > > > One that immediately comes in mind is the MC14500B PLC building block, > > > from the 1970's, which requires quite lot of support chips (code > > > memory, PC, /O chips) to do some useful work. > > > > > > After much searching, I found the (NI) National Instruments SBA > > > (Serial Boolean Analyser) > > > http://www.wass.net/othermanuals/GI%20SBA.pdf > > > from the same era, with 1024 word instructions (8 bit) ROM and four > > > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > > > For the re-entrance enthusiasts, it contains stack pointer relative > > > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > > > Darlington buffers may be needed to drive loads typically found in PLC > > > environment. > > > > > > Anyone seen more modern 1 bit chips either for relay replacement or > > > for truly serial computers ? > > > > ]> Anyone seen more modern 1 bit chips either for relay replacement or > > ]> for truly serial computers ? > > > > LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose > > (Logic Emulation Machine) https://opencores.org/project/lem1_9min > > > > Jim Brakefield > > It is hard for me to imagine applications where a 1 bit processor would be useful. A useful N bit processor can be built in a small number of LUTs. I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > I discussed this with someone once and he imagined apps where the processing speed requirement was quite low and you can save LUTs with a bit serial processor. I just don't know how many or why it would matter. Even the smallest FPGAs have thousands of LUTs. It's hard to picture an application where you couldn't spare a few hundred LUTs. > > Rick C.]>It's hard to picture an application where you couldn't spare a few hundred LUTs. There are advantages to using several soft core processors, each sized and customized to the need. ]>I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. There are many under 600 LUTs, including 32-bit. Had hoped the full featured LEM design would be under 100 LUTs. Have done some rough research of whats available for under 600 LUTs: https://opencores.org/project/up_core_list/downloads select: "By Performance Metric" A big rational for small soft core processors is that they replace LUTs (slow speed logic) with block RAM (instructions). And they are completely deterministic as opposed to doing the same by time slicing a ASIC (ARM) processor. Jim Brakefield
Reply by ●October 21, 20182018-10-21
On Sunday, October 21, 2018 at 12:31:34 PM UTC-4, jim.bra...@ieee.org wrote:> On Sunday, October 21, 2018 at 10:08:06 AM UTC-5, gnuarm.del...@gmail.com wrote: > > On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote: > > > On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > > > > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > > > > <no.email@nospam.invalid> wrote: > > > > > > > > >Clifford Heath <no.spam@please.net> writes: > > > > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > > > > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > > >> OTP, no SPI, UART or I涎, but still... > > > > > > > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > > > > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > > > > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > > > > >I like that it's in a 6-pin SOT23 package since there aren't many other > > > > >MCUs that small. > > > > > > > > Slightly OT, but I have often wonder how primitive a computer > > > > architecture can be and still do some useful work. In the > > > > tube/discrete/SSI times, there were quite a lot 1 bit processors. > > > > There were at least two types, the PLC (programmable Logic Controller) > > > > type replacing relay logic. These had typically at least AND, OR, NOT, > > > > (XOR) instructions.The other group was used as truly serial computers > > > > with the same instructions as the PLC but also at least a 1 bit SUB > > > > (and ADD) instructions to implement all mathematical functions. > > > > > > > > However, in the LSI era, there down't seem to be many implement ions. > > > > > > > > One that immediately comes in mind is the MC14500B PLC building block, > > > > from the 1970's, which requires quite lot of support chips (code > > > > memory, PC, /O chips) to do some useful work. > > > > > > > > After much searching, I found the (NI) National Instruments SBA > > > > (Serial Boolean Analyser) > > > > http://www.wass.net/othermanuals/GI%20SBA.pdf > > > > from the same era, with 1024 word instructions (8 bit) ROM and four > > > > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > > > > For the re-entrance enthusiasts, it contains stack pointer relative > > > > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > > > > Darlington buffers may be needed to drive loads typically found in PLC > > > > environment. > > > > > > > > Anyone seen more modern 1 bit chips either for relay replacement or > > > > for truly serial computers ? > > > > > > ]> Anyone seen more modern 1 bit chips either for relay replacement or > > > ]> for truly serial computers ? > > > > > > LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose > > > (Logic Emulation Machine) https://opencores.org/project/lem1_9min > > > > > > Jim Brakefield > > > > It is hard for me to imagine applications where a 1 bit processor would be useful. A useful N bit processor can be built in a small number of LUTs. I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > > > I discussed this with someone once and he imagined apps where the processing speed requirement was quite low and you can save LUTs with a bit serial processor. I just don't know how many or why it would matter. Even the smallest FPGAs have thousands of LUTs. It's hard to picture an application where you couldn't spare a few hundred LUTs. > > > > Rick C. > > ]>It's hard to picture an application where you couldn't spare a few hundred LUTs. > > There are advantages to using several soft core processors, each sized and customized to the need. > > ]>I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > There are many under 600 LUTs, including 32-bit. Had hoped the full featured LEM design would be under 100 LUTs. > Have done some rough research of whats available for under 600 LUTs: https://opencores.org/project/up_core_list/downloads > select: "By Performance Metric" > > A big rational for small soft core processors is that they replace LUTs (slow speed logic) with block RAM (instructions). And they are completely deterministic as opposed to doing the same by time slicing a ASIC (ARM) processor.I won't argue a bit that softcores and especially *customizable* softcore CPUs aren't useful. I was talking about there being at best a very tiny region of utility for 1-bit processors. My 600 LUT processor didn't trade off much for performance. It would run pretty fast and was pretty capable. In addition the word size was independent of the instruction set. That said, there are apps where a much less powerful processor would do fine and saving a few more LUTs would be useful. Rick C.
Reply by ●October 21, 20182018-10-21
On 21/10/2018 17:08, gnuarm.deletethisbit@gmail.com wrote:> > It is hard for me to imagine applications where a 1 bit processor > would be useful. A useful N bit processor can be built in a small > number of LUTs. I've built a 16 bit processor in just 600 LUTs and > I've seen processors in a bit less. > > I discussed this with someone once and he imagined apps where the > processing speed requirement was quite low and you can save LUTs with > a bit serial processor. I just don't know how many or why it would > matter. Even the smallest FPGAs have thousands of LUTs. It's hard > to picture an application where you couldn't spare a few hundred > LUTs. >There is not much point in 1-bit processing with modern architectures and FPGAs. But it used to be more useful, for cheap and scalable solutions. You got systems that scaled in parallel, using bit-slice processors to make cpus as wide as you want. And you got serial scaling, giving you practical numbers of bits with minimal die area (like the COP8 microcontrollers).
