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
On Sun, 15 Mar 2009 05:42:11 -0700 (PDT) denish <dinesh.twanabasu@gmail.com> wrote: > Hi, > I am using "inout" signal for the first time in designing I2C > communication with cmos sensor module.I have completed the design. The > post map simulation worked fine and synthesized without warnings and > errors. But when I implemented the design in Spartan 3A DSP by using > pull up resistors for the pins I couldnot get the output.Suggest me > about using the "inout" pins. > Regards > Dinesh. I believe that you want to assign, at any given time, the values '0' or 'Z' to the pin. Then, if you want to use the pullups in the Spartan, you need to place a PULLUP on those pins in the UCF constraint file. Or, if you're talking about real people resistors, you don't. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 138951
Don't worry Plod is on the beat. On 16 Mar, 15:53, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 16, 5:20=A0pm, John Adair <g...@enterpoint.co.uk> wrote: > > > > > > > Some useful things linked on our websitehttp://www.enterpoint.co.uk/tec= hitips/techitips.html. > > > As to boards we have lots but maybe Drigmorn1http://www.enterpoint.co.u= k/component_replacements/drigmorn1.html > > would be a good starting place. > > > John Adair > > Enterpoint Ltd. > > > On 14 Mar, 19:41, Samuel Thomas Kerr <stk...@cs.purdue.edu> wrote: > > > > I'd like to design a custom microprocessor (just for learning purpose= s). I > > > used Lattice's GAL chips with ABEL before, but quickly ran out of spa= ce. > > > As such, I'd like to move over to an FPGA platform. > > > > However, I've never used FPGAs, VHDL, or Verilog before. > > > > I was wondering if someone could point me in the right direction? As = far a > > > development board to start with or a book on a programming language, = or > > > both? > > > > Thanks! > > I was so curious... > > ....to checkout if John's post has some info besides advertizement > inside. > > Antti- Hide quoted text - > > - Show quoted text -Article: 138952
On Mar 13, 6:55=A0am, David Fejes <fej...@gmail.com> wrote: > Hello, > > Maybe this is a bit offtopic but may I ask you what kind of I2C ipcore > do you use? I have to implement some i2c slave logic with some > readable and writable registers in my next design and I'm curious > about that.. > > thank you in advance I wrote my own for a simple slave interface. Look at this thread on the Xilinx forums: http://forums.xilinx.com/xlnx/board/message?board.id=3DSpartan&message.id= =3D268&query.id=3D674829#M268Article: 138953
Vesh a écrit : > Hi, > I am using the Xilinx Spartan 3E starter kit for driving the RFM12B RF > transceiver module. I need to have an SPI controller core that can > drive this module in SPI mode. The VHDL code that I wrote is totally > okay in simulations but its not working through the FPGA board. Can > anyone help me with it? I am not being able to debug this thing. The > simulation's all well but the RF module is not transmitting any data > and I have no idea how to debug it in FPGA hardware. Hello Have you checked your pinout constraint ? Have you tried to look at your SPI lines with an oscilloscope ? NicolasArticle: 138954
Vesh <veshrajsharma@gmail.com> wrote:
>Hi,
>I am using the Xilinx Spartan 3E starter kit for driving the RFM12B RF
>transceiver module. I need to have an SPI controller core that can
>drive this module in SPI mode. The VHDL code that I wrote is totally
>okay in simulations but its not working through the FPGA board. Can
>anyone help me with it? I am not being able to debug this thing. The
>simulation's all well but the RF module is not transmitting any data
>and I have no idea how to debug it in FPGA hardware.
A simple logic analyzer will be handy. Perhaps there is just a bit
missing or the frequency is too high.
--
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: 138955On 16 Mrz., 16:32, Vesh <veshrajsha...@gmail.com> wrote: > I have no idea how to debug it in FPGA hardware. Use this: http://www.xilinx.com/ise/optional_prod/cspro.htm Kolja SulimmaArticle: 138956
I have been following the development of the ZPU, a zero operand processor for FPGAs. The primary intent is to design a CPU that can span a range of sizes from very space efficient to high speed while being efficient at running C code. The original author has an open source compiler producing code for it which seems to be the part he is good at. However, it has been running rather slow in the benchmark they have been running, Dhrystone. I think I figured out why. The ISA is zero operand, but the stack in maintained in memory. There is no stack register architecture. So every stack operation consists of reading the operands, performing the operation and writing back the result. I can see why it is giving slow performance, even when pipelined. I believe the real issue is that the focus is on building a complex machine and trying "techniques" to make it simple and fast. The more I look at things like this, the more I am convinced that the Moore philosophy is right. You can achieve performance by adding more and more complexity, or you can simplify to the point of inherent speed. But then my thinking is biased. I am a hardware guy and my programming has always been the sort of stuff that can fit in a .com file, you know, the ones with the 64 kbyte limit. I still think Bill Gates was right when he said that no one would ever need more than 640 kbytes ;^) I just know that my current multi-GHz machine is not really any faster than my old 12 MHz 286 in many respects... It certainly does not boot any faster and is *much* slower to turn off. RickArticle: 138957
On Mon, 16 Mar 2009 19:10:56 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >I have been following the development of the ZPU, a zero operand >processor for FPGAs. The primary intent is to design a CPU that can >span a range of sizes from very space efficient to high speed while >being efficient at running C code. The original author has an open >source compiler producing code for it which seems to be the part he is >good at. > >However, it has been running rather slow in the benchmark they have >been running, Dhrystone. I think I figured out why. The ISA is zero >operand, but the stack in maintained in memory. There is no stack >register architecture. So every stack operation consists of reading >the operands, performing the operation and writing back the result. I >can see why it is giving slow performance, even when pipelined. Even a stack based ISA can be implemented to be fast. You can certainly make an out of order, multi-issue stack machine as long as you make the memory image consistent with an in-order cpu. In fact even this may not be a requirement if you're not interested in multi-core implementations. You can merge multiple instructions (micro and macro operator fusion) and retire instructions out of order etc by keeping an internal virtual register file which implements register renaming for various stack locations. Whether it's easier or more difficult to extract instruction level parallelism from a stack based ISA is not very clear to me but it certainly is possible. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138958
On Mar 14, 8:14=A0am, nntpman68 <news1...@free.fr> wrote: > Hi Mng, > > Could you please elaborate on this one? > What kit are you exactly talking about? > Is there any documentation. > I'd be quite interested in this info. > > bye > > N > > mng wrote: > > The Avnet Spartan-3A kit has the USB chip set up by default to provide > > a 115.2 kbaud virtual serial port to the FPGA. If that's all you need, > > then it could be a quick way to get started with your project. http://www.google.com/search?q=3DAvnet+Spartan-3A+kitArticle: 138959
On 16 Mrz., 17:18, Jaime Andr=E9s Aranguren Cardona <jaime.arangu...@gmail.com> wrote: > On 26 Feb., 23:02, Glen Herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > > > gabor wrote: > > > (snip) > > > > For Spartan 3 MIG, which is primitive compared to the Virtex 5 > > > MIG, the order of row vs. bank addressing is not important. > > > This is due to the fact that the MIG code only leaves one > > > row of one bank active at any time. =A0The column address should > > > be your low order address bits for linear addressing. =A0This > > > will prevent unnecessary row precharge / activate sequences > > > when performing linear access to memory. > > > One that I might try is a video display that also refreshes > > the RAM. =A0That is an old trick that might still work. > > > > Also note that > > > the least significant bits of the column address are > > > incremented inside the memory chip during a burst operation. > > > There is no carry out to the upper address bits, so when > > > starting a burst you should normally begin at a burst > > > boundary to avoid rapping back to previous addresses. > > > I don't expect any burst operations. =A0My first system will > > be 8080 based, and I don't believe that the 8080 does bursts. > > > > Be careful when using the MIG top level interface with > > > "linear" address. =A0It may be using the least significant > > > bits for the bank address (depends on which interface > > > typeDDR, DDR2, etc.). > > > -- glen > > Hi guys, > > Going further with the thread, I want to "report" that it seems to be > working, but partially. In simulation everything goes fine, both for > writing and reading data. I generate a sequence of numbers, fill the > memory with it, and then read all the positions back, comparing with > the sequence of numbers written. If an error is found, a counter is > incremented. At the end of the read sequence, if everything goes fine, > one led should glow, if not (even a single mismatch was found, which > means the error counter is different to zero) then 6 leds glow. > > I am testing my stuff on an S3E Kit. If I just run the test for a very > few rows (say 3), then most of the times the test passes, others it > does not. If I run for higher number of rows, then at all times it > fails. So, it seems to me that I am getting timing problems. Besides, > I have to add that I am not using an external 133 MHz clock to SMA > connector, I am using the onboard 50Mhz clock instead and a couple > DCMs, one for generating a 100 MHz clock and another one to generate > the 90 degree phase shifted clock. > > Reviewing the implementation reports (ISE 10.1 and ISE 9.2), I see > that the signal rst_dqs_div does not meet timing (MAX_DELAY 460 ps). > Looking into the details of the UCF, I see that this signal, which for > the S3E Starter kit is implemented as a loopback, has an assigment to > pin P13. I suppose that that is needed because of packaging to IOBs, > which is one of the project options for the MIG generated project. Is > there a way to make the signal always internal and not look for a > physical pin? > > The only way I have found to meet timing constraints was to remove > that constraint in the UCF (the one that assigns rst_dqs_div signal to > pin P13), but now another problem arises: when generating the > bitstream, it fails because DRC is not passed, saying that the signal > rst_dqs_div was assigned to bank3 which uses impedance controlled > buffers or has Vref requeriments, which rst_dqs_div does not meet. > > How can it be got to work reliably? Even the original project > generated by MIG (ver 2.1, ver 2.3) for the S3E Kit, without > modifications, fails to meet the timing constraints for signal > rst_dqs_div, which is supposed to be a critical timing signal > necessary to get the controller working correctly. > > All your comments and suggestion are very welcome. > > Kind regards. Hi, I bypassed the DRC test for bitstream generation, but results are even worse: now, most of the times it fails.... very seldom passes, even for just 3 rows. Any hint? Kind regards.Article: 138960
Hi Mng, Sorry my fault. I ordered my Spartan 3A kit from Avnet and I did not find any documentation about the initial serial mode of the USB chip. That's why I got curious when I rad your post. However I overlooked the obvious: I ordered from Avnet, but bought the Digilent kit, which unfortunately has no Cypris chip and no uart via USB bye N mng wrote: > On Mar 14, 8:14 am, nntpman68 <news1...@free.fr> wrote: >> Hi Mng, >> >> Could you please elaborate on this one? >> What kit are you exactly talking about? >> Is there any documentation. >> I'd be quite interested in this info. >> >> bye >> >> N >> >> mng wrote: >>> The Avnet Spartan-3A kit has the USB chip set up by default to provide >>> a 115.2 kbaud virtual serial port to the FPGA. If that's all you need, >>> then it could be a quick way to get started with your project. > > http://www.google.com/search?q=Avnet+Spartan-3A+kitArticle: 138961
On 13 Mrz., 07:16, StYm <satyam.dwiv...@gmail.com> wrote: > My Xilinx EDk (XPS) is not starting. It is giving error: > > "This application has failed to start because libXdh_Part_Anno.dll was > not found. Re-installing the application may fix this problem." > > I reinstalled, but of no use. > > Can anyone help ?? > > Thanks, > > Satyam Hi, Check that ..\EDK\lib\nt is in your global PATH environmental variable. I had a similar issue with libPortability.dll, and this solved it. In this case ".." means the folder where you installed the Xilinx software, for instance C:\Xilinx\10.1\ Regards.Article: 138962
On Mon, 16 Mar 2009 19:10:56 -0700 (PDT), rickman wrote: >[ZPU's] stack is maintained in memory. There is no stack >register architecture. So every stack operation consists of reading >the operands, performing the operation and writing back the result. I >can see why it is giving slow performance, even when pipelined. Strange. I'm sure you too can see what to do about this - same as you had to do on the AMD29K which used some of its huge register set to cache the top of the stack. Implement the stack in on-chip RAM, using circular addressing. When the on-chip stack threatens to overflow, "spill" some of the oldest part of it to main memory, using a fast block write operation. CPU operations then continue to use the on-chip stack but the circular addressing no longer overflows. Similarly, when the stack threatens to underflow, "fill" from main memory. Way back then, you could get quite good performance if you were careful to align the spill/fill operations with a DRAM page. The 29K used software trap routines to do the spill/fill, but I'm sure you could do it at least partly in hardware without too much trouble. Spill/fill can then be done speculatively, in the background, when there is spare bandwidth on the memory interface. Unfortunately the stack cache trashes multi-threading performance, because there is so much context to swap. I guess the correct compromise these days would be very different, with the stack cache probably about 16 words. With only a small stack cache you can keep several process's stacks in the on-chip memory (that's harder to plan, of course, but may still be helpful particularly in a small system). >I believe the real issue is that the focus is on building a complex >machine and trying "techniques" to make it simple and fast. The more >I look at things like this, the more I am convinced that the Moore >philosophy is right. You can achieve performance by adding more and >more complexity, or you can simplify to the point of inherent speed. Always provided you have sufficiently smart compilers to convert complicated real-world code into a suitable stream of your simple instructions. But in general I think I agree. Compilers _are_ pretty smart these days. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 138963
>Strange. I'm sure you too can see what to do about this - >same as you had to do on the AMD29K which used some of its >huge register set to cache the top of the stack. Implement >the stack in on-chip RAM, using circular addressing. When >the on-chip stack threatens to overflow, "spill" some of >the oldest part of it to main memory, using a fast block >write operation. CPU operations then continue to use the >on-chip stack but the circular addressing no longer overflows. >Similarly, when the stack threatens to underflow, "fill" >from main memory. Way back then, you could get quite good >performance if you were careful to align the spill/fill >operations with a DRAM page. The 29K used software trap >routines to do the spill/fill, but I'm sure you could >do it at least partly in hardware without too much trouble. >Spill/fill can then be done speculatively, in the background, >when there is spare bandwidth on the memory interface. You can simplify the hardware a lot by pushing the stack overflow problem back to the compiler. That is, the stack has a fixed size. The compiler can't generate code that overflows that limit. >Unfortunately the stack cache trashes multi-threading >performance, because there is so much context to swap. >I guess the correct compromise these days would be very >different, with the stack cache probably about 16 words. >With only a small stack cache you can keep several process's >stacks in the on-chip memory (that's harder to plan, >of course, but may still be helpful particularly in >a small system). I don't understand that comment. Multi-threading requires separate stacks. That's just more RAM in the CPU, perhaps the virtual CPU number is part of the RAM address if that's what you mean by multi-threading. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138964
On Tue, 17 Mar 2009 03:46:55 -0500, Hal Murray wrote: >You can simplify the hardware a lot by pushing >the stack overflow problem back to the compiler. >That is, the stack has a fixed size. The compiler >can't generate code that overflows that limit. OK. Getting the compiler to limit the stack size is clearly possible (Transputer, anyone? it had a 3-register stack). But this is certain to cause more memory references to escape to memory. It's a compromise, like everything else. >>Unfortunately the stack cache trashes multi-threading >>performance, because there is so much context to swap. [...] >I don't understand that comment. Multi-threading requires >separate stacks. That's just more RAM in the CPU Yes, but if a large swath of CPU register space is used to cache the top-of-stack, then that cache must be saved and restored on a context switch. You can only provide a finite number of stack spaces in the CPU's on-chip RAM, so at some point a context switch is sure to entail a large penalty as some other thread's stack cache must be evicted to main memory. Shallower on-chip stack cache means slower single- thread performance, but faster context switch and the opportunity to keep more threads' stacks on-chip. Compromises again. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 138965
Can anyone tell me how I can load an image file like .jpeg or .bmp on to the system ace compact flash embedded on virtex 2 Pro device? I need to store image onto the compact flash and then do some processing on it. I tried using the different functions in sysace_stdio.h header file like sysace_fopen etc but couldn't find a way to load an image file onto the compact flash, so please help me in this regardArticle: 138966
On Mar 17, 12:58=A0pm, mopra <mohitpra...@gmail.com> wrote: > Can anyone tell me how I can load an image file like .jpeg or .bmp on > to the system ace compact flash embedded on virtex 2 Pro device? > > I need to store image onto the compact flash and then do some > processing on it. I tried using the different functions in > sysace_stdio.h header file like sysace_fopen =A0etc but couldn't find a > way to load an image file onto the compact flash, so please help me in > this regard copy myimage.jpg f:\ where f: is the compact flash drive later just use file functions from your code, they do work ! AnttiArticle: 138967
Hey thanks for your help but can you explain it a little more elaborately. where should i use " copy myimage.jpg f:\ "? How to embed that in the C code? Please help me in this regard. Regards, MohitArticle: 138968
In comp.arch.fpga Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: > You can simplify the hardware a lot by pushing > the stack overflow problem back to the compiler. > That is, the stack has a fixed size. The compiler > can't generate code that overflows that limit. As is usually done for x87 floating point. The story is that the 8087 was designed such that software could detect the stack over/underflow and swap to/from memory. No-one tried writing the software until the hardware was done, and then it was found that it wasn't possible. Presumably it could have been fixed in later processors, but as far as I know, it wasn't changed. -- glenArticle: 138969
Hi Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) Another zero operand CPU http://nibz.googlecode.com cheers jacko Now available in free licence of one core per ASIC/FPGA/CPLD, with two conditions. 1. A K Ring Technologies Logo must be printed atop the chip or close by on the PCB at any resolution. 2. Any documentation produced must acknowledge copyright and provide the URL. This licence is for those folks who do not like the BSD derived work restrictions.Article: 138970
On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote: > Hi > > Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) > > Another zero operand CPUhttp://nibz.googlecode.com > > cheers jacko > > Now available in free licence of one core per ASIC/FPGA/CPLD, with two > conditions. > 1. A K Ring Technologies Logo must be printed atop the chip or close > by on the PCB at any resolution. > 2. Any documentation produced must acknowledge copyright and provide > the URL. > > This licence is for those folks who do not like the BSD derived work > restrictions. the difference between zpu and nibz is that ZPU is supported by GCC toolchain, while there are no tools to generate any meaningful code for nibz correct me if i am wrong AnttiArticle: 138971
On Mar 17, 9:58=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote: > > > > > Hi > > > Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) > > > Another zero operand CPUhttp://nibz.googlecode.com > > > cheers jacko > > > Now available in free licence of one core per ASIC/FPGA/CPLD, with two > > conditions. > > 1. A K Ring Technologies Logo must be printed atop the chip or close > > by on the PCB at any resolution. > > 2. Any documentation produced must acknowledge copyright and provide > > the URL. > > > This licence is for those folks who do not like the BSD derived work > > restrictions. > > the difference between zpu and nibz is that ZPU is supported > by GCC toolchain, while there are no tools to generate any > meaningful code for nibz > > correct me if i am wrong > > Antti Is that really the primary critera? I think you are right. But I have a similar CPU design that I expect to use on a project shortly and it will be programmed in assembly, but it will look a lot like Forth. I consider that to be close enough to a high level language. BTW, ZPU may have a GCC compiler, but without a debugger, is that really useful? There aren't many projects done in C that are debugged without an emulator. RickArticle: 138972
rickman wrote: > On Mar 17, 9:58 am, "Antti.Luk...@googlemail.com" > <Antti.Luk...@googlemail.com> wrote: >> On Mar 17, 3:24 pm, Jacko <jackokr...@gmail.com> wrote: >> >> >> >>> Hi >>> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) >>> Another zero operand CPUhttp://nibz.googlecode.com >>> cheers jacko >>> Now available in free licence of one core per ASIC/FPGA/CPLD, with two >>> conditions. >>> 1. A K Ring Technologies Logo must be printed atop the chip or close >>> by on the PCB at any resolution. >>> 2. Any documentation produced must acknowledge copyright and provide >>> the URL. >>> This licence is for those folks who do not like the BSD derived work >>> restrictions. >> the difference between zpu and nibz is that ZPU is supported >> by GCC toolchain, while there are no tools to generate any >> meaningful code for nibz >> >> correct me if i am wrong >> >> Antti > > Is that really the primary critera? I think you are right. But I > have a similar CPU design that I expect to use on a project shortly > and it will be programmed in assembly, but it will look a lot like > Forth. I consider that to be close enough to a high level language. > > BTW, ZPU may have a GCC compiler, but without a debugger, is that > really useful? There aren't many projects done in C that are debugged > without an emulator. > > Rick It's possible to do a lot of development without a debugger. I often do embedded development without one (though I prefer to have one available if possible). Until you've done debugging with only a single LED for signalling, you haven't really done embedded development. Bonus points if the microcontroller you're using only comes in OTP version. Even big projects can be done without a debugger: <http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html> So a compiler without a debugger is somewhat limited but still useful, but a debugger without a compiler is rather less useful!Article: 138973
On Mar 17, 5:09=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 17, 9:58=A0am, "Antti.Luk...@googlemail.com" > > > > > > <Antti.Luk...@googlemail.com> wrote: > > On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote: > > > > Hi > > > > Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) > > > > Another zero operand CPUhttp://nibz.googlecode.com > > > > cheers jacko > > > > Now available in free licence of one core per ASIC/FPGA/CPLD, with tw= o > > > conditions. > > > 1. A K Ring Technologies Logo must be printed atop the chip or close > > > by on the PCB at any resolution. > > > 2. Any documentation produced must acknowledge copyright and provide > > > the URL. > > > > This licence is for those folks who do not like the BSD derived work > > > restrictions. > > > the difference between zpu and nibz is that ZPU is supported > > by GCC toolchain, while there are no tools to generate any > > meaningful code for nibz > > > correct me if i am wrong > > > Antti > > Is that really the primary critera? =A0I think you are right. =A0But I > have a similar CPU design that I expect to use on a project shortly > and it will be programmed in assembly, but it will look a lot like > Forth. =A0I consider that to be close enough to a high level language. > > BTW, ZPU may have a GCC compiler, but without a debugger, is that > really useful? =A0There aren't many projects done in C that are debugged > without an emulator. > > Rick- Hide quoted text - > > - Show quoted text - well assembler is GOOD if it exist :) so any soft-core with assembler is ok but there is no assembler for nibz? so =3D=3D useless. no C, no assembler, =3D=3D not possible to use :( a non working somesort of forht partially adopted but not really tested does not count as development tool. a simple assembler would. I personally dont like C, but unfortunatly can not fully avoid it either AnttiArticle: 138974
On Tue, 17 Mar 2009 16:22:42 +0100, David Brown <david@westcontrol.removethisbit.com> wrote: >rickman wrote: >> On Mar 17, 9:58 am, "Antti.Luk...@googlemail.com" >> <Antti.Luk...@googlemail.com> wrote: >>> On Mar 17, 3:24 pm, Jacko <jackokr...@gmail.com> wrote: >>> >>> >>> >>>> Hi >>>> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) >>>> Another zero operand CPUhttp://nibz.googlecode.com >>>> cheers jacko >>>> Now available in free licence of one core per ASIC/FPGA/CPLD, with two >>>> conditions. >>>> 1. A K Ring Technologies Logo must be printed atop the chip or close >>>> by on the PCB at any resolution. >>>> 2. Any documentation produced must acknowledge copyright and provide >>>> the URL. >>>> This licence is for those folks who do not like the BSD derived work >>>> restrictions. >>> the difference between zpu and nibz is that ZPU is supported >>> by GCC toolchain, while there are no tools to generate any >>> meaningful code for nibz >>> >>> correct me if i am wrong >>> >>> Antti >> >> Is that really the primary critera? I think you are right. But I >> have a similar CPU design that I expect to use on a project shortly >> and it will be programmed in assembly, but it will look a lot like >> Forth. I consider that to be close enough to a high level language. >> >> BTW, ZPU may have a GCC compiler, but without a debugger, is that >> really useful? There aren't many projects done in C that are debugged >> without an emulator. >> >> Rick > >It's possible to do a lot of development without a debugger. I often do >embedded development without one (though I prefer to have one available >if possible). Until you've done debugging with only a single LED for >signalling, you haven't really done embedded development. Bonus points >if the microcontroller you're using only comes in OTP version. Hear, hear! You can dump an awful lot of information out of a single pin, even floating point numbers (don't ask). Emulators are slightly useful to check on whether one's understanding of the datasheet is correct but, unless they're a cycle-by-cycle exact replica of the microcontroller core *and* all of its peripherals then it's not really emulating, more like approximating -- and that path can lead to trouble. -- Rich Webb Norfolk, VA
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