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
nico@puntnl.niks (Nico Coesel) writes: > Ever looked at the price, size and power consumption of tiny logic > in a sot23-5 package? Ever try to fix a bad board design without a respin? Doesn't matter what the price and power are if it doesn't work. Also, consider all those old electronics (console games, etc) where people are trying to find ancient chips, and end up replacing them with CPLDs or FPGAs.Article: 142526
On Aug 12, 10:12=A0am, John Adair <g...@enterpoint.co.uk> wrote: > Ed > > Even if the FMC connectors hit $7-8 that still a major hit when you > sell modules in the area of $20-40 as many of our smaller modules are. > As it happens we were formally quoted several times that number for > the LPC FMC procluding anything other than mid to high range module > products. > > If we get into partial I/O variants on this spec is that not going to > defeat the purpose. I can just imagine the number of calls our support > line will get if we have a partial I/O implementation on a board. Even > if you have a FAQ saying so the number of people that will not see or > understand the implications will be large. > > Out of interest do have some example pricing and types of module > Xilinx will sell? > > John Adair > Enterpoint Ltd. > I checked with Samtec on their pricing for the connectors. Roughly speaking, the HPC version has a range of $12-16 depending and the LPC version has a range of $7-9. My understanding is that Samtec sells all of their material direct, so you should be getting consistent pricing. FMC with partial IO busses are expected and we will have partials on some of our boards. This will likely have very little effect on the modules as the bus widths aren't multiples of 8 so it isn't very likely that all of the pins will be used. Compatibability verification can/will be done by comparing XML based descriptions of CC and FMC. We don't have customer pricing set for any FMC modules at this time. Ed McGettigan -- Xilinx Inc.Article: 142527
braver wrote: > In the past , when I instantiate some IP like fifo , I don't connect > some port like wr_count.It never affect synthesizer. Synthesis does not require that *all* outputs are used, but at least one must be, as well as the supporting inputs. -- Mike TreselerArticle: 142528
I typically use down counters that are loaded with an initial value and output a flag when reaching zero. Sometimes the tools use the carry chain and other times they don't. I seem to recall that this was discussed here a few months ago and someone posted a function or other VHDL code that would produce a carry chain every time. I typically use a MOD operator for the counter, but the code I saw used an integer for the count and subtracted one in the conditional of an IF, then used the same expression in the counter assignment if the result was not less than zero. It appears that this was optimized to share the same logic for both expressions. I can't find this thread. Anyone remember it and some keywords that would let me find it? There may be something wrong with Google groups. I search on "counter carry chain" and it finds *NO* results. RickArticle: 142529
On Aug 14, 6:36=A0pm, rickman <gnu...@gmail.com> wrote: > I typically use down counters that are loaded with an initial value > and output a flag when reaching zero. =A0 > > I can't find this thread. =A0Anyone remember it and some keywords that > would let me find it? =A0There may be something wrong with Google > groups. =A0I search on "counter carry chain" and it finds *NO* I think this is the link you're looking for. Andy's post from June 19 is the 8th one in the thread. http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/36d7833968f= 3e102/452a230826d347aa?q=3Ddown+counter+%22Andy%22+group:comp.lang.vhdl Kevin JenningsArticle: 142530
On Aug 14, 9:17 pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Aug 14, 6:36 pm, rickman <gnu...@gmail.com> wrote: > > > I typically use down counters that are loaded with an initial value > > and output a flag when reaching zero. > > > I can't find this thread. Anyone remember it and some keywords that > > would let me find it? There may be something wrong with Google > > groups. I search on "counter carry chain" and it finds *NO* > > I think this is the link you're looking for. Andy's post from June 19 > is the 8th one in the thread. > > http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/36d78... > > Kevin Jennings I guess that is the one. I don't see where they brought out the carry flag to use elsewhere though and when I implement this, I get two adders and the one generating the term count uses extra logic just to get the carry out of the chain. This is using the Lattice tools in their XP parts. I seem to recall making this work by adding an extra bit to the input value and separating the msb of the output as the carry. I'll give that a try. RickArticle: 142531
Hi everyone, The latest version of GTKWave (3.2.2) windows binary is available here: http://www.dspia.com/gtkwave.html -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 142532
Hi i have several requests asking when i will publish it, i guess i should do it soon, in the form it is at the moment, and issue updates from time to time. just a small "outcome" of the research so far: 1) there is almost no small (real small) useable soft-core optimized for FPGA architecture in generic with decent compiler support. The best is possible Eric5 (110 Altera LE's, has C compiler), unfortunatly Eric5 is highly CLOSED project (no ISA spec. available, no free Assembler). It is using GPL v2 licensed SDCC derived compiler. I bet the C code is not very small, and not useable in smallest Eric5 configurations. Everything else is larger (or very limited): Picoblaze/Latticemico8 need distributed RAM (not available in Actel, Altera, Silicon Blue FPGA's). Plenty of other "small and smallest" cores are actually not so small, or have other issues, like Mproz3 is real tiny, but most instructions eat up 6 bytes of code memory, etc. So, as a result of that research, well there is a need for a new architecture! ..and its mostly finalized (yesterday afternoon)! programs in high level language are already compiled, and the compiled code executed in HDL simulator. I would not have made a new one, if I would have found anything comparable to the features i was looking for: *1 useable in any FPGA with Block RAM (not needing dist. RAM) *2 somewhat compiler friendly *3 size: < 200 slice/LE(<30% smallest Altera/Lattice/Xilinx/SBT), < 500 Versatiles (to fit A3P060, 30%) ABM (Advanced Brain Machine) core does fulfill, [1], [2], [3] current status: + jump/call/return + register banking/context switching + ALU basic - ALU more instructions - conditional branches ===> 95 Spartan3 slices + 1 BRAM or 298 Actel Versatiles + 2 BRAM's 2) for anything larger there are plenty of interesting options already Antti PS any hints and links to other interesting soft processor cores are welcome, as usual...Article: 142533
Antti <antti.lukats@googlemail.com> wrote:
>Hi
>
>i have several requests asking when i will publish it, i guess i
>should do it soon,
>in the form it is at the moment, and issue updates from time to time.
>
>just a small "outcome" of the research so far:
>
>1) there is almost no small (real small) useable soft-core optimized
>for FPGA architecture in generic with decent compiler support.
>
>The best is possible Eric5 (110 Altera LE's, has C compiler),
>unfortunatly Eric5 is highly CLOSED project (no ISA spec. available,
>no free Assembler). It is using GPL v2 licensed SDCC derived compiler.
>I bet the C code is not very small, and not useable in smallest Eric5
>configurations.
>
>Everything else is larger (or very limited):
>
>
>
>2) for anything larger there are plenty of interesting options already
>
>Antti
>PS any hints and links to other interesting soft processor cores are
>welcome, as usual...
Did you check the 68HC11?
See:
http://www.opencores.org/?do=project&who=gup
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142534On Aug 16, 12:47=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > Antti <antti.luk...@googlemail.com> wrote: > >Hi > > >i have several requests asking when i will publish it, i guess i > >should do it soon, > >in the form it is at the moment, and issue updates from time to time. > > >just a small "outcome" of the research so far: > > >1) there is almost no small (real small) useable soft-core optimized > >for FPGA architecture in generic with decent compiler support. > > >The best is possible Eric5 (110 Altera LE's, has C compiler), > >unfortunatly Eric5 is highly CLOSED project (no ISA spec. available, > >no free Assembler). It is using GPL v2 licensed SDCC derived compiler. > >I bet the C code is not very small, and not useable in smallest Eric5 > >configurations. > > >Everything else is larger (or very limited): > > >2) for anything larger there are plenty of interesting options already > > >Antti > >PS any hints and links to other interesting soft processor cores are > >welcome, as usual... > > Did you check the 68HC11? > > See:http://www.opencores.org/?do=3Dproject&who=3Dgup > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg= er hammer!" > --------------------------------------------------------------- Hide quot= ed text - > > - Show quoted text - LOL YES, there is no need to point to the "usual suspects" unless there is a real feeling, i have missed something obvious. I have some 68HC11 on some SimmStick boards, and yes I have check the cores too, while HC11 is nice, it would not in the wildest dreams be as small as I was looking for. for "next category", yes its an option for sure, but just not for the smallest ones AnttiArticle: 142535
Antti.Lukats@googlemail.com <antti.lukats@googlemail.com> wrote: (big snip) > YES, there is no need to point to the "usual suspects" > unless there is a real feeling, i have missed something obvious. How about the 8080? I don't know how small it is in an FPGA, but it is pretty small in actual transistors. If done carefully, it might come out pretty small in an FPGA, too. Though it might run slow that way. (That is, if you can build a cycle accurate 8080.) -- glenArticle: 142536
On Aug 16, 1:03=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Antti.Luk...@googlemail.com <antti.luk...@googlemail.com> wrote: > > (big snip) > > > YES, there is no need to point to the "usual suspects" > > unless there is a real feeling, i have missed something obvious. > > How about the 8080? =A0I don't know how small it is in an > FPGA, but it is pretty small in actual transistors. =A0 > > If done carefully, it might come out pretty small in an > FPGA, too. =A0Though it might run slow that way. =A0 > (That is, if you can build a cycle accurate 8080.) > > -- glen most 8080 soft cores are large, Light8080 is surpsingly small, not bad at all. but, have you tried some i8080 C compiler? looked at the output? now, think you have 512 byte of Block RAM for both code and data! with ABM, C code can be compiled to single block ram easily, as there is no overhead, sure the C code that can be used is limited too, but its pretty much usable already. AnttiArticle: 142537
Antti.Lukats@googlemail.com wrote: > with ABM, C code can be compiled to single > block ram easily, as there is no overhead, > sure the C code that can be used is limited > too, but its pretty much usable already. You could use Forth instead of C. The Forth guys are always claiming that their code is multiple times smaller than the same functionality in C. Even the source code is half the size of C, see e.g. this article: http://www.inventio.co.uk/forthnc.htm Maybe you know already my first try for a Forth CPU: http://www.frank-buss.de/forth/cpu1/ But it is too big. A better one for small size cores might be this one: http://www.colorforth.com/inst.htm This is used in Chuck's new 40 core CPU. But it would be only for hard core Forthers, because you have to use colorForth. But maybe an ANS Forth to colorForth compiler should be not too difficult to implement. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142538
I'm implementing BCD adders in a Spartan 3 using instance arrays of these:
module BCD_ADDER (
input [3:0] a,
input [3:0] b,
input cin,
output cout,
output [3:0] s);
wire [4:0] unadj = a+b+cin;
assign {cout, s} = unadj<10? unadj : unadj+6;
endmodule
This article http://www.edn.com/archives/1996/021596/04di3.htm shows a more
resource-efficient way to do it, using wider binary adders, requiring access
to the fast carry chain between slices. The slices have outputs XB and YB
which tap the carry chain; but I can't get the tools to use them. This
doesn't do what I want:
module Test(
input [7:0] a,
input [7:0] b,
output [7:0] s,
output yb
);
assign {yb,s[3:0]} = a[3:0]+b[3:0];
assign s[7:4] = a[7:4]+b[7:4]+yb;
endmodule
Any tips would be appreciated.
TIA
Article: 142539
I'm implementing BCD adders in a Spartan 3 using instance arrays of these:
module BCD_ADDER (
input [3:0] a,
input [3:0] b,
input cin,
output cout,
output [3:0] s);
wire [4:0] unadj = a+b+cin;
assign {cout, s} = unadj<10? unadj : unadj+6;
endmodule
This article http://www.edn.com/archives/1996/021596/04di3.htm shows a more
resource-efficient way to do it, using wider binary adders, requiring access
to the fast carry chain between slices. The slices have outputs XB and YB
which tap the carry chain; but I can't get the tools to use them. This
doesn't do what I want:
module Test(
input [7:0] a,
input [7:0] b,
output [7:0] s,
output yb
);
assign {yb,s[3:0]} = a[3:0]+b[3:0];
assign s[7:4] = a[7:4]+b[7:4]+yb;
endmodule
Any tips would be appreciated.
TIA
Article: 142540
"Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com> wrote:
>On Aug 16, 12:47=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>> Antti <antti.luk...@googlemail.com> wrote:
>> >Hi
>>
>> >i have several requests asking when i will publish it, i guess i
>> >should do it soon,
>> >in the form it is at the moment, and issue updates from time to time.
>>
>> >just a small "outcome" of the research so far:
>>
>> >1) there is almost no small (real small) useable soft-core optimized
>> >for FPGA architecture in generic with decent compiler support.
>>
>> >The best is possible Eric5 (110 Altera LE's, has C compiler),
>> >unfortunatly Eric5 is highly CLOSED project (no ISA spec. available,
>> >no free Assembler). It is using GPL v2 licensed SDCC derived compiler.
>> >I bet the C code is not very small, and not useable in smallest Eric5
>> >configurations.
>>
>> >Everything else is larger (or very limited):
>>
>> >2) for anything larger there are plenty of interesting options already
>>
>> >Antti
>> >PS any hints and links to other interesting soft processor cores are
>> >welcome, as usual...
>>
>> Did you check the 68HC11?
>>
>> See:http://www.opencores.org/?do=3Dproject&who=3Dgup
>>
>> --
>> Failure does not prove something is impossible, failure simply
>> indicates you are not using the right tools...
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg=
>er hammer!"
>> --------------------------------------------------------------- Hide quot=
>ed text -
>>
>> - Show quoted text -
>
>LOL
>
>YES, there is no need to point to the "usual suspects"
>unless there is a real feeling, i have missed something obvious.
>
>I have some 68HC11 on some SimmStick boards, and yes I
>have check the cores too, while HC11 is nice, it would not
>in the wildest dreams be as small as I was looking for.
How big is the 68HC11?
>for "next category", yes its an option for sure, but just not
>for the smallest ones
Just to make sure: do you have a working gcc for your CPU?
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142541Antti wrote: > 1) there is almost no small (real small) useable soft-core optimized > for FPGA architecture in generic with decent compiler support. A real small processor isn't programmed in a HLL but in assembly. > Plenty of other "small and smallest" cores are actually not so small, > or have other issues, like Mproz3 is real tiny, but most instructions > eat up 6 bytes of code memory, etc. An instruction is 6 bytes for Mproz3 (4 bytes for Mproz2) only if you need 64 kbyte RAM. If you reduce the word size from 16 to 12 bit (3 kbyte RAM) you get 4.5 byte for Mproz3 and 3 byte for Mproz2. And because a jump is always just one word, the average instruction size is even smaller. But if you have 64 kbyte RAM, you can always spend 1-2 kbyte to implement an interpreter for a denser instruction set. So I don't think that code density is a problem but maybe speed. But where else do you get a 16 bit CPU with interrupt support with only 65 flip-flops (if hand made, don't know how big it is if you use VHDL). Xproz has a much larger instruction set (instruction length from 2 - 8 byte), supports 5 levels of hardware interrupts and still fits on an ACTEL 1020 or a small part of a XILINX XC3195. And about code density: a complete multi tasking OS including all drivers (graphics-, SCSI-, serial-, parallel- and keyboard-card), the hierarchical file system and the system tools (like dir, copy, format, tasklist, kill, ...) fits in 64 kbyte ROM. But it all was written in assembly an not in a HLL. With minimal additional hardware, Xproz2 also implements a DRAM controller and a MMU which allows physical addressing of 8 Gbyte memory and supports on demand paging. Each user task has a virtual address space of 128 kbyte code and 32 Mbyte data. The small code space isn't really a problem because of the very fast task switch (the CPU doesn't have any registers beside the status register, not even a program counter). > So, as a result of that research, well there is a need for a new > architecture! > current status: > + jump/call/return > + register banking/context switching > + ALU basic > - ALU more instructions > - conditional branches A CPU without conditional branches?Article: 142542
On Aug 15, 10:13 pm, rickman <gnu...@gmail.com> wrote: > > I seem to recall making this work by adding an extra bit to the input > value and separating the msb of the output as the carry. I'll give > that a try. > Not specific to your down counter problem, but I posted a snippet a few years back that showed operand padding to pull out the carry/overflow: http://www.fpga-faq.com/archives/99500.html#99517 I'd first seen that in another post years ago, that I can't locate anymore... I've also noticed troubles with the google archive search, I've been using the archive search on fpga-faq.com instead http://www.fpga-faq.com/archives/index.html BrianArticle: 142543
What about xr16 from fpgacpu.org. The website is inactive for some time but the code and compiler are there. Link: http://www.fpgacpu.org/xsoc/xr16.html The CPU is restricted to academic use only but is about 200 Xilinx slices (if I remember correctly). I do not fully understand you goal. I guess you are not restricting your search for GPL or free CPU cores. Regarding the light8080, it is small and will probably execute slow but the problem is finding a compiler. MotiArticle: 142544
On Aug 16, 5:47=A0pm, Moti Litochevski <motil...@gmail.com> wrote: > What about xr16 from fpgacpu.org. The website is inactive for some > time but the code and compiler are there. > Link:http://www.fpgacpu.org/xsoc/xr16.html > The CPU is restricted to academic use only but is about 200 Xilinx > slices (if I remember correctly). > I do not fully understand you goal. I guess you are not restricting > your search for GPL or free CPU cores. > Regarding the light8080, it is small and will probably execute slow > but the problem is finding a compiler. > Moti Hi I reply to multiple responses in once =3D=3D=3D xr16 (core cpu) - 260 Spartan3 SLICES, USES distributed RAM gr0040 (small soc) - 222 Spartan3 SLICES, USES distributed RAM both are REAL old, BOTH abondoned, but bound to somewhat restricting license =3D=3D=3D yes, I am not restricting to free or opensource of GPL or anything, just looking for what is available =3D=3D=3D Light8080 is really small, compiler could be found, but.. the code is not much compact =3D=3D=3D XProz3, YES I have looked, remember i have even translated the schematic to VHDL and made a testbench verification for XProz3 well, if you only have 1 Block RAM (1KByte or even just 512 byte), how much of XProz3 code would fit? If there is a lot of memory, then there is also usually more resources to include little bit bigger processor than XProz(3), but no doubt XProz'es is a nice approuch ASM vs HLL, I am not the one who needs to be told, there is no need/ use for HLL for small microcontrollers. Well I happened to write a VERY HLL compiler for Atmel AVR, it was launched commercially 1 sept 1997, what to my knowledge is about 1 month after first AVR was sold to general market. And, yes that HLL compiler did targer AT90S1200, with no soft stack, and no ram and only 512 instruction of code space. And, yes it makes sense to use HLL, as my AVR HLL compiler is able to produce code more dense than AVR assembler (it really is!). .. I listed the features implemented and counted for in the resource estimate conditional branches do exist, just they are not reflected in the resource count given =3D=3D=3D gcc: no, i dont have. I have kinda almost C looking code compiling to binary and that is executing well. C compiler would be also easy (within the limitations) =3D=3D=3D forth: I have used forth, and actually I did design a single chip computer based on PIC16C84 that used the 1Kbyte code space for *forth interpreter *software serial comm *code editor *single step debugger the program code was hold in the 64 byte eeprom there are plenty of FORTH/like cores, but this category is the most "messy" one, means its very hard to make sense or use them (except ZPU where c compiler emits code for forth like cpu) Frank's forth, well it takes 276 Slices so yes too big colorforth, hm, maybe, I even fetched the sea-24 whatever it was archive when it was available (it no longer is) well, if there is chance that normal people need to write programs, then its better to avoid forth :( I may be ok with it, but the general audience isnt ------------------------ I looked again the gray soc's well ABM is VERY similar, but it is really design "from scratch" 100% and designed to work in modern FPGA's not in XC4K AnttiArticle: 142545
I have obtained some Virtex 4 devices that have a code on them of ES4. Looking around the web it seems that these are engineering samples. My question is are these devices good to use or can they be used in a production board? JonArticle: 142546
Herbert Kleebauer <klee@unibwm.de> wrote:
>Antti wrote:
>
>> 1) there is almost no small (real small) useable soft-core optimized
>> for FPGA architecture in generic with decent compiler support.
>
>A real small processor isn't programmed in a HLL but in assembly.
>
>
>> Plenty of other "small and smallest" cores are actually not so small,
>> or have other issues, like Mproz3 is real tiny, but most instructions
>> eat up 6 bytes of code memory, etc.
>
>system and the system tools (like dir, copy, format, tasklist,
>kill, ...) fits in 64 kbyte ROM. But it all was written in assembly
>an not in a HLL.
That would take ages. Last week I was investigating whether I could
take some load from a CPU into an FPGA. Ofcourse I didn't want to
rewrite some complicated algorithm with assembly language.
Besides, a modern C compiler produces faster or more compact code
(depending on the optmisation settings) than an assembly programmer.
Ofcourse you'll need C code which is biased to speed or size to begin
with.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142547On Aug 14, 8:17=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Aug 14, 6:36=A0pm, rickman <gnu...@gmail.com> wrote: > > > I typically use down counters that are loaded with an initial value > > and output a flag when reaching zero. =A0 > > > I can't find this thread. =A0Anyone remember it and some keywords that > > would let me find it? =A0There may be something wrong with Google > > groups. =A0I search on "counter carry chain" and it finds *NO* > > I think this is the link you're looking for. =A0Andy's post from June 19 > is the 8th one in the thread. > > http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/36d78... > > Kevin Jennings Wow, what's old is new again... I should note that since then, I have noticed that while the RTL view from Synplify indicates using the next bit (carry), the technology view sometimes comes up with something better, not necessarily using the carry chain the way one would expect. That said, I have never seen it do worse than a "count =3D 0" comparison. Also be aware that the "count - 1 < 0" (or "count + 1 > 2**n-1") trick only works with integer types, not with unsigned vector types. AndyArticle: 142548
On Sun, 16 Aug 2009 11:53:01 -0500, "maxascent" <maxascent@yahoo.co.uk> wrote: >I have obtained some Virtex 4 devices that have a code on them of ES4. >Looking around the web it seems that these are engineering samples. My >question is are these devices good to use or can they be used in a >production board? Engineering samples sometimes have issues which need to be worked around so if you can work around them or if you can live with them you may use them. Check the following documents to see what errata the V4 might have: www.nuhorizons.com/ProductChange/Xilinx/en017.pdf www.nuhorizons.com/ProductChange/Xilinx/en016.pdf Also check this directory: http://www.nuhorizons.com/ProductChange/xilinxprev06.asp -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 142549
"Antti.Lukats@googlemail.com" wrote: > well, if you only have 1 Block RAM (1KByte or even just 512 byte), how > much of XProz3 > code would fit? If there is a lot of memory, then there is also > usually more resources > to include little bit bigger processor than XProz(3) You always have to compare the total cost. RAM is in opposite to logic and routing resources a very compact structure. How many flip-flops and gates can you add to a FPGA-CPU design until it consumes more chip area than an additional RAM block? Define an concrete application then we can compare the logic count for the CPU and the necessary RAM size. > And, yes it makes sense to use HLL, as my AVR HLL compiler is able to > produce > code more dense than AVR assembler (it really is!). > .. Funny, and I thought you are a serious person. Can you show me the code? But now we can prove that any program for the AVR can be reduced to size zero: 1. write the program in assembly 2. rewrite it in C and it will be at least one byte smaller 3. disassemble the binary to get an assembly program of the same size as the C binary 4. goto 2.
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