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 Mar 13, 9:02 am, Herbert Kleebauer <k...@unibwm.de> wrote: > rickman wrote: > > > I am still looking for a good small soft-core, and well it seem > > > not to exist... > > > I seem to recall that you were trying to find a bit serial CPU that > > would be the smallest possible in an FPGA. > > I don't think it is possible to make a serial CPU smaller than > a parallel one. Here is a 16 bit CPU with interrupt support > built with only 65 flip-flop's. If you reduce the size to > 12 bit (3 kbyte memory space) you can even save 12 flip-flop's. > > http://www.bitlib.de/pub/mproz/mproz3_e.pdf (with internal RAM)http://www.bitlib.de/pub/mproz/mproz2a.pdf (with external RAM) > > schematics in the zip files: > > http://www.bitlib.de/pub/mproz/ Are you saying that this processor can't be made smaller? Registers can be stored in memory rather than FFs. By processing the registers serially the logic can be greatly reduced at the expense of more control logic. I don't see how you can say that any machine can't be reduced by replacing BTW, I don't know why you are stating the FF count as if this were a good measure of design size. Most designs in FPGAs use more LUTs than FFs. The logic of this beast is likely With 65 FFs this may well be designed for a CPLD which has more capable logic with each FF. But few of those parts have any ram. That means you need external ram and I don't consider that a "simple" or small design. Still, I have to say, this is one goofy processor. It does everything in memory and only has five instructions. Is this thing really of any use other than academic? RickArticle: 138901
On Mar 13, 3:56=A0pm, Herbert Kleebauer <k...@unibwm.de> wrote: > Walter Banks wrote: > > Herbert Kleebauer wrote: > > > I don't think it is possible to make a serial CPU smaller than > > > a parallel one. Here is a 16 bit CPU with interrupt support > > > built with only 65 flip-flop's. > > Serial processors only require a 1 bit alu, registers are shift registe= rs > > with a single in and out data line. The availability of large lowcost > > bit serial memories like SD cards opens the possibility of creating a > > small processor. > > Yes, you will save some logic if you use a 1 bit alu, but that's not > as much as you have to add for controlling the serial alu. > > The goal was to make the smallest possible CPU which can at > least address 32 kbyte RAM and supports interrupts. The first > idea was to use a serial design, but if you spend some time > thinking about it, then you will see that you never can get > it as small as a 16 bit design (also a 8 bit design is bigger > than a 16 bit design). This is at least true for the gate count, > if you also consider the routing resources then the difference > may be smaller. I don't follow your reasoning at all. The control logic does get slightly more complex going from N bits to 1, but the data path logic gets N times smaller. Even the last step of going from 2 bits to 1 bit data path only adds 1 more bit to the control registers so the balance is determined by which has more registers. Of course the logic is another matter. But you can't just talk about which is more complex. The only way to compare is to build and measure. The data path can be analyzed, the control logic requires an understanding of the details of the machine. RickArticle: 138902
On Mar 13, 1:41=A0pm, marcus.erlands...@gmail.com wrote: > On Mar 13, 6:10=A0pm, "Antti.Luk...@googlemail.com" > > > > <Antti.Luk...@googlemail.com> wrote: > > On 13 Mar, 13:21, marcus.erlands...@gmail.com wrote: > > > > The OpenCores team are putting in enormous resources in making sure > > > that > > > the OpenCores will continue to exist/expand. It is important that the > > > platform can continue to support good services to both > > > users and core-providers, also for the next 10-20 years. If possible > > > it is > > > also good if we can provide an even greater =93trust=94 and =93qualit= y=94 in > > > the > > > cores at OpenCores. > > > > The complete redesign of the OpenCores-platform enable us to support > > > all > > > users with a future-proof and professional site. It also support > > > integrating > > > new functionalities much easier then before, since the old > > > platform had grown out of proportion. > > > > We feel that we have listen to the community, since we get allot of > > > Feedback - i.e. complaining about poor statistics, forum structure, > > > etc. But > > > unfortunately we also get some few complaints from a small portion of > > > users > > > that are just against all changes :-( > > > > But for those users who has more concrete suggestion/ideas/ > > > improvements, > > > feel free to contact us at oc-t...@opencores.org > > > > Best regards, > > > > The OC-team > > > it seems that many links are now dead or then project deleted :( > > > too bad > > > Antti > > Hi Antti. > Actually, there are more project now visible, then before. But some > projects where started 2000-2004, but never completed and no one has > updated the project ever since. These project will be moved to another > category shortly, so that it is clear to all users which project that > are ready and not. Send an email to oc-t...@opencores.org and let us > know what project has been deleted, so that we can double check this. > > As for the links, we will be fixing allot of the "broken" links within > the next coming weeks.. > > Best regards, > The OC-team I think that is great. I have been watching the CPU projects for some time and there are many started that have never even been brought to the point of having code! It will be very helpful for the duds to be weeded out. RickArticle: 138903
Using MicroBlaze to access the DDR is quite easy using the Base System Builder in EDK/Platform Studio. However, EDK is not free. You can get an eval to try it out, but then it's $495. Xilinx and Avnet both have examples posted for this board using MicroBlaze and DDR. Although it is for DDR2 on a different board, you might be interested in an example we created at Avnet to modify the MIG testbench to simplify it and add comments. You can find it at www.em.avnet.com/spartan3a-dsp --> Support Files & Downloads --> S3A1800DSP DDR2 MIG Simplified Verilog User Logic. I think the similarities between DDR2 and DDR make it useful. BryanArticle: 138904
On 14 Mar, 00:36, Walter Banks <wal...@bytecraft.com> wrote: > Herbert Kleebauer wrote: > > Walter Banks wrote: > > > Herbert Kleebauer wrote: > > > > > I don't think it is possible to make a serial CPU smaller than > > > > a parallel one. Here is a 16 bit CPU with interrupt support > > > > built with only 65 flip-flop's. > > > > Serial processors only require a 1 bit alu, registers are shift registers > > > with a single in and out data line. The availability of large lowcost > > > bit serial memories like SD cards opens the possibility of creating a > > > small processor. > > > Yes, you will save some logic if you use a 1 bit alu, but that's not > > as much as you have to add for controlling the serial alu. > > Bit serial will be slow but remember that the data paths to registers > are reduced. The logic is considerably simpler. > > There are other advantages as well like the ability to have variable > length data types, reducing the number of instructions to do > multi-byte math. > > Bit serial is slower, to be sure. The controller needed to use a > SD card is not very much. > > There are many applications that could be well suited to a bit serial > processor, for example a data logger. > > Regards, > > -- > Walter Banks > Byte Craft Limitedhttp://www.bytecraft.com Hi Walter, your comments are always nice, right there are many uses ;) and some are not so obvious for people with only academic backgrounds. I published SD card init code for CoreABC, also the settings what options are enabled in the soft-core http://groups.google.com/group/antti-brain/browse_thread/thread/470711dbeb2c7d5d?hl=en when implemented in ProAsic where program rom is done from 3 input luts the design uses 620 tiles (each tile is either 3 input logic OR one flip flop) and one blockram (for 6 bytes scratch) I bet the same function (SD card init) could be implemented with far less resources when doing the statemachine in pure HDL, but the soft-core approuch is more flexible, we can add more functions by more code and relativly less extra resources, when doing it as one big statemachine at some point it gets too complex to maintain CoreABC is good example of specialized core, it is really good for the case that there is no initialized RAM (that is rom is made from logic) and flip flops are sparse as well. the smallest version of CoreABC would only include APB WRT and HALT instructions, and would be used to just initialize APB bus peripherals. But for more complex programs additional features can be enabled as needed AnttiArticle: 138905
Hi, I assume, you found already the solution, as the post is quite old. If not. You should create a dualport RAM with the quartus software and instantiate it. (It would be a synchronous RAM though and you had to change your design a little) Hnadwritten RAMs work only for small RAMs. bye N Jukka Marin wrote: > Hi, > > I started learning FPGA's and Verilog and seem to run into problems every > day :-) > > I'm trying to use dual-port RAM for buffering data between a serial link > and a 32-bit CPU bus. I wrote two separate always blocks, one which > receives data from the serial link and writes it in RAM and another one > which talks to the CPU bus and allows reading of the RAM. > > When I try to compile this design (using quartus ii), the compiler "never" > finishes and I believe it's trying to build the RAM array out of logic > gates. If I make the RAM small enough, the compiler succeeds (although > it takes a long time). > > I did a similar thing for serial link transmission and it worked as expected > (and the compiler used real RAM for the buffer, not logic gates). > > Is it wrong to access the same memory in two separate always blocks? The > serial link and the CPU bus are independent and the bus has no clock, so > I'm trying to make an async design. I'm getting no error messages about > RAM from the compiler, so I'm not sure what I'm doing wrong. (Quartus II > is usually pretty verbose, complaining about everything from unused pins > to the color of my socks, but this time it isn't helping at all.) > > I would try putting the RAM stuff inside one always block, but it seems a > bit difficult to do.. (or, I still can't think FPGA - my brain always > seems to enter software mode when opening a text editor). > > I'd appreciate pointers or examples which would get me unstuck. ;-) > > Thanks, > > -jmArticle: 138906
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.Article: 138907
"Kolja" <ksulimma@googlemail.com> wrote in message news:281d7f11-6695-436b-87bb-6778dfdbcf4d@v38g2000yqb.googlegroups.com... > Well, I herewith declare to happily ignore the DMCA while beeing > outside of the > US. I follow the laws of my country and international treaties. That > is more > than the US government can claim to do. > > Kolja > >> I herein promise todo all my best not to post on threads where >> previous postings may violate DMCA or copyrights. And of course I will >> not make such postings myself as I have not done to my knowledge >> before either. Although many countries have daft laws, we British can claim to have some of the daftest. Our libel laws are absolutely bonkers. We have libel tourists! http://www.theregister.co.uk/2009/03/13/echr_libel_law/ http://en.wikipedia.org/wiki/Libel_tourism And what other country could have an offence of "wanton and furious" cycling? Whatever, vive la difference. Syms.Article: 138908
On 14 Mar, 15:33, "Symon" <symon_bre...@hotmail.com> wrote: > "Kolja" <ksuli...@googlemail.com> wrote in message > > news:281d7f11-6695-436b-87bb-6778dfdbcf4d@v38g2000yqb.googlegroups.com... > > > Well, I herewith declare to happily ignore the DMCA while beeing > > outside of the > > US. I follow the laws of my country and international treaties. That > > is more > > than the US government can claim to do. > > > Kolja > > >> I herein promise todo all my best not to post on threads where > >> previous postings may violate DMCA or copyrights. And of course I will > >> not make such postings myself as I have not done to my knowledge > >> before either. > > Although many countries have daft laws, we British can claim to have some of > the daftest. Our libel laws are absolutely bonkers. We have libel tourists! > > http://www.theregister.co.uk/2009/03/13/echr_libel_law/ > > http://en.wikipedia.org/wiki/Libel_tourism > > And what other country could have an offence of "wanton and furious" > cycling? > > Whatever, vive la difference. > > Syms. haha now i understand why the french company put "englich court"... in NDA better to sue there :) AnttiArticle: 138909
Hi I am routing a pcb with some LVDS signals. Is there a way in Virtex 5 to invert the signal so that I can have P->N and N->P on the pcb. Cheers JonArticle: 138910
rickman wrote: > > http://www.bitlib.de/pub/mproz/mproz3_e.pdf (with nternal RAM) > > http://www.bitlib.de/pub/mproz/mproz2a.pdf (with external RAM) > Are you saying that this processor can't be made smaller? As long as I don't see it, I don't believe it. > Registers > can be stored in memory rather than FFs. There are no registers at all (beside the 15 bit program counter and the 2 bit status register). It is a two (mproz2) or three (mproz3) address machine with only memory operands. > By processing the registers > serially the logic can be greatly reduced at the expense of more > control logic. You have two operands and one result but there is only one data path to the serial memory. This means, you at least need one registers to temporary hold one of the operands and an address register to hold the address of the second operand. Mproz also only needs two temporary registers. But the control logic for a serial design becomes much more complex. Mproz only has 8 states, so the state machine can be implemented with only three flip-flop's (actual it's done as a one-hot machine with 8 flip-flop's because this reduces the logic count). > BTW, I don't know why you are stating the FF count as if this were a > good measure of design size. Most designs in FPGAs use more LUTs than > FFs. The logic of this beast is likely With 65 FFs this may well be > designed for a CPLD which has more capable logic with each FF. But As far as I remember, mproz uses about 250 two-input gates, that should fit well with 65 flip-flop's.Article: 138911
"maxascent" <maxascent@yahoo.co.uk> wrote in message news:0tSdnaEyPIToVSbU4p2dnAA@giganews.com... > Hi > > I am routing a pcb with some LVDS signals. Is there a way in Virtex 5 to > invert the signal so that I can have P->N and N->P on the pcb. Generally, yes. Just invert the data in your logic.Article: 138912
It looks to me that mproz is a memory to memory architecture with 3 instructions.Article: 138913
On Mar 14, 5:50=A0pm, Jacko <jackokr...@gmail.com> wrote: > It looks to me that mproz is a memory to memory architecture with 3 > instructions. really? ;) AnttiArticle: 138914
After configuration, all unused IOB pins are, usually, PULL DOWN. Does that include the unused global clock pins, too? TIAArticle: 138915
> > Yes, you will save some logic if you use a 1 bit alu, but that's not > > as much as you have to add for controlling the serial alu. > > I don't follow your reasoning at all. The control logic does get > slightly more complex going from N bits to 1, but the data path logic > gets N times smaller. Even the last step of going from 2 bits to 1 > bit data path only adds 1 more bit to the control registers so the > balance is determined by which has more registers. Of course the > logic is another matter. But you can't just talk about which is more > complex. The only way to compare is to build and measure. The data > path can be analyzed, the control logic requires an understanding of > the details of the machine. Feel free to make a BSD 1 bit version of nibz. It may be smaller, but will take 16 times as long to execute any code, yet will be bigger than 1/16th the size. Therefore the computational use density (instructions per cycle per area (m^2.s)^-1) will decrease. If resources are really tight to maintain budget, and the lower execution speed is not relevant for the task, then maybe the power efficiency implications of computational use density (CUD) are not important either. This was a major factor in nibz design, and is why pre/post dec/inc was included even though the area increases. The program area decreases. I would be interested in any figures on processor CUD bennchmarking or any suggested code examples. cheers jacko p.s. this is a CUD sell argument! ;-)Article: 138916
Has anyone an idea on how i can scale a two complement division result from range -0.00..x-+0.00..x to a new range of +16383 to -13684 with only the use of a two complement fpga divisor quotient and remainder? You see i want my result to be in a proper range so it can be used by a DAC. -- xristos ------------------------------------------------------------------------ xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15 View this thread: http://www.fpgacentral.com/group/showthread.php?t=88557Article: 138917
I made a mistake the new range that i want to have is +16383 to -16384. The quotient from the first division (without scaling) is always 0. -- xristos ------------------------------------------------------------------------ xristos's Profile: http://www.fpgacentral.com/group/member.php?userid=15 View this thread: http://www.fpgacentral.com/group/showthread.php?t=88557Article: 138918
On Mar 14, 12:52=A0pm, Jacko <jackokr...@gmail.com> wrote: > > > Yes, you will save some logic if you use a 1 bit alu, but that's not > > > as much as you have to add for controlling the serial alu. > > > I don't follow your reasoning at all. =A0The control logic does get > > slightly more complex going from N bits to 1, but the data path logic > > gets N times smaller. =A0Even the last step of going from 2 bits to 1 > > bit data path only adds 1 more bit to the control registers so the > > balance is determined by which has more registers. =A0Of course the > > logic is another matter. =A0But you can't just talk about which is more > > complex. =A0The only way to compare is to build and measure. =A0The dat= a > > path can be analyzed, the control logic requires an understanding of > > the details of the machine. > > Feel free to make a BSD 1 bit version of nibz. It may be smaller, but > will take 16 times as long to execute any code, yet will be bigger > than 1/16th the size. Therefore the computational use density > (instructions per cycle per area (m^2.s)^-1) will decrease. If > resources are really tight to maintain budget, and the lower execution > speed is not relevant for the task, then maybe the power efficiency > implications of computational use density (CUD) are not important > either. > > This was a major factor in nibz design, and is why pre/post dec/inc > was included even though the area increases. The program area > decreases. I would be interested in any figures on processor CUD > bennchmarking or any suggested code examples. > > cheers jacko > > p.s. this is a CUD sell argument! ;-) Your metric of CUD is not very useful when evaluating a processor for a given application. Although a higher CUD would be better if all the other requirements are met, a processor with an optimal CUD may not be the best choice for an application. I have no apps that require minimization of the CPU at all costs while needing a very low processing speed. But I can see where there might be a need for that in some apps. In general, the optimal CUD would come from matching the size of the processor data to the size of the data in the application. No need to use a 16 bit data path when you are only processing bytes. Widening a data path to 32 bits to process 32 bit data will produce a higher CUD than using a 16 bit machine for the same data. But that does not mean I will be using an 8 bit machine for 8 bit data or a 32 bit machine for 32 bit data. There is an overriding principle in engineering called "good enough". At some point optimizations are counter productive as they impose other constraints. All requirements need to be considered in an appropriate weight. RickArticle: 138919
On Mar 14, 11:11=A0am, Herbert Kleebauer <k...@unibwm.de> wrote: > rickman wrote: > > >http://www.bitlib.de/pub/mproz/mproz3_e.pdf(with nternal RAM) > > >http://www.bitlib.de/pub/mproz/mproz2a.pdf=A0(with external RAM) > > Are you saying that this processor can't be made smaller? > > As long as I don't see it, I don't believe it. Ok, I guess that pretty much limits the discussion. > > Registers > > can be stored in memory rather than FFs. =A0 > > There are no registers at all (beside the 15 bit program counter and > the 2 bit status register). It is a two (mproz2) or three (mproz3) > address machine with only memory operands. Yes, I read the description and I did not figure it out completely. This is a bizarre machine that has no practical value that I can see. You are defining it as a "minimal" machine because of its FF count. But it is just trading off FF based registers and LUT logic for memory usage. I don't see how that is "minimal" in any real way. Three words of memory to perform an ADD??? That's not minimal. > > By processing the registers > > serially the logic can be greatly reduced at the expense of more > > control logic. > > You have two operands and one result but there is only one data > path to the serial memory. This means, you at least need one > registers to temporary hold one of the operands and an address > register to hold the address of the second operand. Mproz > also only needs two temporary registers. But the control logic > for a serial design becomes much more complex. Mproz only has > 8 states, so the state machine can be implemented with only three > flip-flop's (actual it's done as a one-hot machine with 8 > flip-flop's because this reduces the logic count). Why do you need temporary registers? If the memory is serial, each bit can be fetched as needed. You are imposing a word access method on this. > > BTW, I don't know why you are stating the FF count as if this were a > > good measure of design size. =A0Most designs in FPGAs use more LUTs tha= n > > FFs. =A0The logic of this beast is likely =A0With 65 FFs this may well = be > > designed for a CPLD which has more capable logic with each FF. =A0But > > As far as I remember, mproz uses about 250 two-input gates, that > should fit well with 65 flip-flop's. How about the memory? I expect that will be an order of magnitude larger than the machine itself, even for a small program. RickArticle: 138920
On Mar 14, 8:49=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 14, 11:11=A0am, Herbert Kleebauer <k...@unibwm.de> wrote: > > > rickman wrote: > > > >http://www.bitlib.de/pub/mproz/mproz3_e.pdf(withnternal RAM) > > > >http://www.bitlib.de/pub/mproz/mproz2a.pdf=A0(with external RAM) > > > Are you saying that this processor can't be made smaller? > > > As long as I don't see it, I don't believe it. > > Ok, I guess that pretty much limits the discussion. > > > > Registers > > > can be stored in memory rather than FFs. =A0 > > > There are no registers at all (beside the 15 bit program counter and > > the 2 bit status register). It is a two (mproz2) or three (mproz3) > > address machine with only memory operands. > > Yes, I read the description and I did not figure it out completely. > This is a bizarre machine that has no practical value that I can see. > You are defining it as a "minimal" machine because of its FF count. > But it is just trading off FF based registers and LUT logic for memory > usage. =A0I don't see how that is "minimal" in any real way. =A0Three > words of memory to perform an ADD??? =A0That's not minimal. > > > > By processing the registers > > > serially the logic can be greatly reduced at the expense of more > > > control logic. > > > You have two operands and one result but there is only one data > > path to the serial memory. This means, you at least need one > > registers to temporary hold one of the operands and an address > > register to hold the address of the second operand. Mproz > > also only needs two temporary registers. But the control logic > > for a serial design becomes much more complex. Mproz only has > > 8 states, so the state machine can be implemented with only three > > flip-flop's (actual it's done as a one-hot machine with 8 > > flip-flop's because this reduces the logic count). > > Why do you need temporary registers? =A0If the memory is serial, each > bit can be fetched as needed. =A0You are imposing a word access method > on this. > > > > BTW, I don't know why you are stating the FF count as if this were a > > > good measure of design size. =A0Most designs in FPGAs use more LUTs t= han > > > FFs. =A0The logic of this beast is likely =A0With 65 FFs this may wel= l be > > > designed for a CPLD which has more capable logic with each FF. =A0But > > > As far as I remember, mproz uses about 250 two-input gates, that > > should fit well with 65 flip-flop's. > > How about the memory? =A0I expect that will be an order of magnitude > larger than the machine itself, even for a small program. > > Rick right mproz stands for minimal.. so it is minimal in terms of instructions and resources in the tradeoff of speed (8 clocks!) and program size the machine is funny, it can do subroutine calls by patching own code on the fly that is self modifying code is needed, normal instructions are 6 bytes or 8 bytes if new immediate constant is needed. Also shift and rotate are very clumsy i guess so the maximum 32K memory space would only hold say about 5K instructions ! AnttiArticle: 138921
I'd like to design a custom microprocessor (just for learning purposes). I used Lattice's GAL chips with ABEL before, but quickly ran out of space. 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!Article: 138922
I thought there may be a way to do it in the IOB rather than have to use some logic. > >"maxascent" <maxascent@yahoo.co.uk> wrote in message >news:0tSdnaEyPIToVSbU4p2dnAA@giganews.com... >> Hi >> >> I am routing a pcb with some LVDS signals. Is there a way in Virtex 5 to >> invert the signal so that I can have P->N and N->P on the pcb. > >Generally, yes. Just invert the data in your logic. > > >Article: 138923
Hello, Yes, the Virtex-5 IOB supports inversion of any input signal (LVDS or single ended) prior to the IOB flip-flop in the ILOGIC component. This feature is unique to Virtex-5 - Virtex-4 doesn't have it and you'd have to use a tiny bit of the logic fabric of the part. - Nathan On Mar 14, 12:47=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > I thought there may be a way to do it in the IOB rather than have to use > some logic. > > > > > > >"maxascent" <maxasc...@yahoo.co.uk> wrote in message > >news:0tSdnaEyPIToVSbU4p2dnAA@giganews.com... > >> Hi > > >> I am routing a pcb with some LVDS signals. Is there a way in Virtex 5 > to > >> invert the signal so that I can have P->N and N->P on the pcb. > > >Generally, yes. =A0Just invert the data in your logic.Article: 138924
Jacko wrote: > Feel free to make a BSD 1 bit version of nibz. It may be smaller, but > will take 16 times as long to execute any code, yet will be bigger > than 1/16th the size. Therefore the computational use density > (instructions per cycle per area (m^2.s)^-1) will decrease. If > resources are really tight to maintain budget, and the lower execution > speed is not relevant for the task, then maybe the power efficiency > implications of computational use density (CUD) are not important > either. A very first order metric. I am not arguing for bit serial processors but the 16 to 1 makes an assumption that the bit serial is only implementing a 16 bit data path. A well designed bit serial instruction set would change the metrics on both the hardware and the performance. You are correct that control overhead does not scale but bit serial processors can have a bunch of viable applications which has been my point. Low pin count to memory and I/O for example. The SDcard gives multiple gigabytes of memory with a few pins. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.com
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