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
An approach that might be easier and cheaper than what you propose is a compact flash and controller-based approach like that provided by Xilinx as the SystemACE CF. Have a look at the web page listed below. http://www.xilinx.com/isp/systemace/systemacecf.htm Steven Derrien wrote: > Hello, > > This post is just for submitting an idea to those who are familiar with > embedded system design, in order to get some feed-back (with respect to > feasibility, cost, usefulness and so on?). > > The basic idea is the following : > > We want to design a reconfigurable SoC, which will be connected to an > IDE hard-drive, used by the application running on the SoC. One of the > key point, is that we need to perform dynamic reconfiguration of the > FPGA. > > Our idea is to use the Hard-drive memory to store the various FPGA > configurations, and to use a small 32 I/O MCU (8051) to perform the FPGA > reconfiguration from the HDD. (the 8051 would share the IDE bus with the > FPGA, but they would have a mutual exclusive use of the HDD, since the > MCU would only be used during reconfiguration) > > Since the FPGA should be a relatively big Virtex/Spartan-II, and since a > large density configuration EEPROMs (several Mbits) are quite expensive > compared to a small MCU, we feel that this could be a nice way to reduce > the total system cost. > > Now we are wondering whether this idea is good or not :), we are > specifically concerned with : > > - PCB layout and signal integrity problems due to the fact that the IDE > connection is shared between the MCU and the FPGA. For ex. would it be > possible to use high-speed IDE (50Mhz clock) protocols from the FPGA ? > > - Reliability : since the hard-drive will be used for both read and > write operation during the application, we must ensure that some part of > the HDD storage is locked (to guarantee that the configurations are not > overwritten by mistake) > > - Feasibility : How difficult would it be to design and debug such a > system ? > > Any advice, comments, critics, ideas are welcome, > > Thank you in advance. > StevenArticle: 38951
Falk Brunner wrote: > Iam curious how much these glitching contributes to power consumption?. > Just recently we had a presentation from our FAE about the new > Coolrunner-II, where everything was tried to save the last uA (disabeling > inputs to prevent internel nets from toggeling etc.) Yes, the same was done in the good old XC3000 with PowerDown. Any unnecessary excursion or activity costs energy. And glitches can contribute significantly, even when they do not jeopardize functionality. But that was not the original question. Peter AlfkeArticle: 38952
Falk Brunner wrote: > > "Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag > news:3C55764C.40E1023@earthlink.net... > > > Russell, the question wa: How man diffrent functions can a LUT > > implement. > > And the answer is 64K. > > It only taks a few minutes to describe few hundred completely > > different ones, not counting input permutations. > > I remember that there was a small file discussing the number of diffent > functions possible with a 4 input LUT, 2^16-permutations of inputs > But I cant find it anymore > www.fpga-faq.com ?? NO. > > AFAIR the number was somewhere around 1800. Hmm, different math functions vs different output functions. With a 4 input function, there's 16 distinct outputs. For a 3 input and 1 input function, there's 8+2=10 distinct outputs, and 8x2=16 combinations of outputs. For a 2 input and 2 input function, there's 4+4=8 distinct outputs, and 4x4=16 combinations of outputs. For a 2 input and 1 input and 1 input function, there's 4+2+2=8 distinct outputs, and 4x2x2=16 combinations of outputs. For a 1,1,1,1 input function, there's 2+2+2+2=8 distinct outputs, and 2x2x2x2=16 combinations of outputs. Therefore, total combinations= 5x16= 80 (assuming all LUT inputs are used) I'm glad i fail nitpicking interviews;)Article: 38953
Tim, No apology required. I said we were working on it, and it has taken forever, and for that I apologize. Smaller parts do require less, and we are in the process of finishing up the characterization before we publish it in the datasheet and commit ourselves for all future time. The issue is that Spartan is the low cost product line, and we definitely do not want to impact our yield by applying a spec that is too tight. If 100% pass the power on test now, can we get an acceptable yield with a lower criteria? This takes a lot of silicon over the dam, and a lot of process corners. That takes time. The better the yield, the lower our cost, and the better the price to customers. Please contact Kim.Goldblatt@xilinx.com (author of the app note) for details. Or you may email me directly: austin@xilinx.com. Austin Tim wrote: > Sorry to return to this topic yet again... > > XAPP450/451 show the SpartanII power-up current requirement as > 500mA for _all_ parts, provided the temperature requirements > are met. > > However, I have a distant recollection that someone (Austin?) > has at one time posted that the smaller parts need less than > this? Any ideas on the slope of the curve from the 2S15 > to the 2S200? > > I am particularly interested in the 2S30.Article: 38954
Franck Pissotte <franck.pissotte@free.fr> writes: > do you mean that a real 1MHz 6502 or 8 Mhz 8051 is faster > than a design implemented in a 20 mHz FPGA? Yes, those 20 mHz FPGAs are really slow! I didn't even think they still offered speed grades that slow. Actually, in my cycle-accurate 6502 design (work in progress), the data path synthesizes with a maximum clock of over 30 MHz in an XC2S200-5, with no manual placement. The control is only perhaps 50% complete, but it looks like it won't be in the critical path.Article: 38955
Arash Salarian wrote: > > Hi, > > I'm starting a new design in which I'm using a multi-channel A/D with a low > sampling-rate and Flash memory for the storage and the system is going to be > powered by battery. In this stage, I'm not yet sure if using a FPGA would be > wise, as I'm very concerned with the power consumption. The gate count of > the circuit will be 3k~4k in my opinion so basically any medium Spartan > family or even maybe XPLA would do. I've seen a device from ATmel (T87C5111) > that consumes only 5mA and I guess is a good candidate too. This makes me > hesitate to choose any FPGA over these types of micro-controller in designs > were every bit of current matters.. > > Does anyone has experience in using FPGAs in low power applications and is > there any suggestion in selection FPGAs over micros in these types of > designs? For a Data-Logger, a uC is the best solution. Where a S/CPLD can out-shine uC, in simple tasks, is usages like slave IO / keypad / and power management applications, and MOSFET drivers. Once you add Time and Address calculations (maths), the uC is doing what it does best. The T87C5111 is a very good choice, as it has 32KHz osc plus 12MHz buried burst oscillator, so can do the timestamp tasks at very low power, and then run fast to minimise the WRITE energy FPGA will never compete with a small uC, but in a large system, where the FPGA is needed already for data-path reasons, you can add a SOFT uC into the FPGA. The crunch is not the uC core, but the OP-CODE storage/delivery. -jg -- ======= 80x51 Tools & IP Specialists ========= = http://www.DesignTools.co.nzArticle: 38956
> I am looking for some code to define a glitch less clock > enable/disable circuit. The clock frequency is 100MHz. What I am > trying to say is that I have a counter with a 100MHz clock and I > want to avoid runt pulses on the clock. This could either be a > clock mux switching between 0 and clock on the output or a "safe" > clock enable that would eliminate (or at least minimize) the > possibility of metastability. The counter could be asynchronous if > that simplifies things. Any ideas, suggestions, sources, SpartanIIs have dedicated clock enable inputs on all flops. You should use those rather than gating clocks (which is very bad practice anyway) with logic[1]. Consult your synthesis guide for more info on how to do that in your HDL. Judging from your email address, I assume that you're a student. An interesting exercise is to run the tool fpga_editor, create an empty, small fpga and play with the CLBs. You can learn alot about how the fpgas actually implement logic in this way. [1] PAR will complain loudly if you do this, because you are no longer able to use dedicated clock routing resources so, glitches aside, you'll have big problems with skew. -- David Miller, BCMS (Hons) | When something disturbs you, it isn't the Endace Measurement Systems | thing that disturbs you; rather, it is Mobile: +64-21-704-djm | your judgement of it, and you have the Fax: +64-21-304-djm | power to change that. -- Marcus AureliusArticle: 38957
Russell Shaw wrote: > > Why should the order of generating 16 separate 1-bit values > matter? What fault could make them non independent? > > Peter Alfke wrote: > > > > Sorry, Russell, no job offer. ;-) > > > > There are 2, 3, 4-input AND, NAND, OR, NOR, XOR, XNOR functions and all sorts of > > combinations of them, including multiplexers. > > And then you can have an inversion on any input, etc. > > > > But the better reasoning goes like this: > > To test the functionality 100%, one must obviously apply sixteen "test vectors" to > > the group of four inputs. At the output, this will create a sequence of 16 bits. > > Treat that as a word, and, voila, there are 64K different 16-bit words. Yes, some > > are stupid ( stuck High, etc) and some are the result of input permutations, but > > there are still a lot of useful functions. Q: How many test patterns does Xilinx apply, in production, to confirm each LUT is functioning correctly ? -jgArticle: 38958
I think Peter triggerd some inner gost of mine. I want to compute the EXACT number of unique functions possible with a 4 input LUT. First start, lets have a look at the 2 input LUT. Lets call the inputs A and B and the result R, so the truth table looks like this. (Use a fixed font) B A R 0 0 R0 0 1 R1 1 0 R2 1 1 R3 For two inputs, there is only one permutation. If we change A with B (or verca vice ;-) we get the following table with the same logic function. A B R 0 0 R0 0 1 R2 1 0 R1 1 1 R3 Now we write down all possible 16 combinations for R0..R3 and compare them to their permutation. If the are identical, the code is a unique function. If they differ, we found a permutation function. Example 1 R permutated R0 0 0 R1 0 0 R2 0 0 R3 1 1 They are identical, so code 1000 is a unique function. Example 2 R permutated R0 0 0 R1 1 0 R2 0 1 R3 0 0 They are different, so its a permutation function. Now here the complete list for a 2 input LUT U . . . . . . . means unique function PxA, PxB . . . means Permutation number X, part A / B R3 R2 R1 R0 Type general function name 0 0 0 0 U LOW 0 0 0 1 U A NOR B 0 0 1 0 P1A A AND NOT B 0 0 1 1 P2A NOT B 0 1 0 0 P1B B AND NOT A 0 1 0 1 P2B NOT A 0 1 1 0 U A XOR B 0 1 1 1 U A NAND B 1 0 0 0 U A AND B 1 0 0 1 U A XNOR B 1 0 1 0 P3A A 1 0 1 1 P4A A OR NOT B 1 1 0 0 P3B B 1 1 0 1 P4B B OR not A 1 1 1 0 U A OR B 1 1 1 1 U HIGH So we see, a 2 input LUT has 2 fixed codes (LOW / HIGH) 6 unique functions 4 permutations of 2 codes ------------------------------ 16 functions overall OK, this was the first part. Now I will make a small programm to calculate all permutation of the 4 inputs of a 4 input LUT (which are 4! = 24), compare them all and write down a statistic. Stay tuned folks, I'll be back. -- MfG FalkArticle: 38959
Paul wrote: > > Anyone got any tips about web sites/newsgroups discussing problems/tips with > Altera devices and tools. http://www.altera.com/support/solutions/spt-search_solutions.html > Obviously there is a certain amount of excellent information here and in > c.l.vhdl, but I was surprised that there wasn't an altera newsgroup or > similar bulletin board for users to discuss things. I don't know. Doesn't seem to be Altera's style. --Mike TreselerArticle: 38960
Rick Filipkiewicz wrote: > <snip> > > One thing I've always wondered since I first came across LUT based architectures is: > > ``What is the LUT equivalent of Quine-McClusky sum of products reduction ?'' > > is there is such a thing. i.e is there a logic reduction algorithm that's always > guaranteed to find an implementation of any logic function in the minimum number of > ``levels'' ? Assuming all the inputs are equally critical and ignoring things like > F5MUXs, carry chains, etc. Not sure what you mean. In a LUT, any combination of 4 IP can be 'mapped', so there is no resource to save with logic minimise ? In a conventional PLD, with AND/OR structure, then product term minimise is very usefull, and does save resource. To compare the two, we have a 7 Segement Hexadecimal ROM design, minimised in CUPL, that can be thought of as 7 1 bit ROM (LUT) patterns of 4 inputs. In AND/OR logic, these minimise to this product term count : => 4.4.4.4.3.3.3 As a tutorial, we coded the Logic table of the S57/58 tinylogic, and that is a 3 IP LUT. The two 'most usefull ones' chosen from the '256 in-theory possible', can reduce to two product terms.Article: 38961
"Jim Granville" <jim.granville@............co.nz> wrote > Q: How many test patterns does Xilinx apply, in production, > to confirm each LUT is functioning correctly ? Q: I wonder how Xilinx came to invent the SRL? :)Article: 38962
Thanks for the solution Paul. I am not familiar with conduits, so was pretty much out of my depth. Not using conduits, you should not need the WIRE primitive and probably do something like http://www.tech-forge.com/bustest-steen.qar. Regards, -Steen "Paul" <nospam@nospamplease.com> wrote in message news:<UCG38.9500$4i5.1212763@news11-gui.server.ntli.net>... > Because I hate threads without an answer, I've posted my solution. > > After ripping the single bit from the output bus use a WIRE primitive and > connect the output of WIRE to the desired output signal. > > You do not seem to be able to use the block mapper to map say q[23..0] to > one signal bus as well as say q[7] to a single signal. Bring q[23..0] out > and name it to some arbitrary bus name and then also take the single bit > from that bus to the WIRE primitive. > > PaulArticle: 38963
This looks interesting : http://www.ebnonline.com/story/OEG20020128S0079 It has many spins (as expected :) on the problem, but it seems very relevant to fast-shrink-path SRAM FPGAs. Is there any information on the 'disturbance energy' for the various SRAM components of FPGAs :- - The Config Cells ( Slower/larger, but not zero FIT ? ) - The Fast SRAM Blocks - The sea of registers - The LUT array store The SRAM notes do not mention register errors, but since a SRAM cell is effectively a strobed latch, is it possible to disturb the BIT state in a latch, just as in a SRAM cell ? Error recovery in data blocks is possible with correction, but how does a system detect config or latch errors ? -jgArticle: 38964
who can post a verilog code or link about random?Article: 38965
> >If you have a slow clock and look at it on the oscilloscope, it may > >look perfect cause you have the timescale zoomed out. Measure the > >rise time and the fall time of your clock. I suspect it is too slow, > >and the cmos inputs are interpreting this as multiple clocks per > >transition. > > > >Newman > > Possible. The rise time, IIRC, was around 220 ns. I would guess that > this is fast enough, but I don't know. > > -Kevin 220 ns seems like an eternity. I looked up the input transition time in the Xilinx book for you. It is 250 ns max, but I would take that with a grain of salt, because perhaps that is for regular inputs, and not the clock. I assume that you are not using a DLL and are using a global clock. I went back to your previous thread (why did you start another one?), and you said that your clock come off a GPIO pin on another card. How did you connect the GPIO pin from one card to the Spartan II clock input pin? If it was by just tying a wire from point A to point B, you might want to twist a ground wire with it attached to a ground point at both ends close to where the signals are attached. This may help, or maybe it won't. If the connection from the GPIO port to the clock input is point to point (e.g. no other connection point involved. You may want to try a series source point termination where you add resistor (25 ohms?) to the GPIO pin, and reattach your clock to the other end of the resistor. This may not work because the GPIO may have a high output impedence, hence the long rise and fall time. If you are just experimenting around, you may want to try adding a bipolar Schmidt trigger inverter/buffer on the spartan board that attaches the incoming "clock" to the inverter/buffer, whose output is to the input of the FPGA. Try to make the connection to the FPGA as short as possible, with the wire close to the board. Of course you would disconnect the original clock connection to the FPGA. If the Spartan board already has a clock on it that is much faster (higher frequency) than the GPIO clock, you could bring the GPIO clock into a regular FPGA pin, and resample the GPIO clock with the Spartan board clock to generate a clock enable pulse that would shift your register using the board clock. You may have to think about how to detect the rising edge of the GPIO clock, while sampling it far enough apart to avoid having two samples in the 220 nS rise/fall time region. Hope you can get it to work, NewmanArticle: 38966
In article <1012267550.1627.0.nnrp-14.9e9832fa@news.demon.co.uk>, tim@rockylogic.com.nooospam.com says... > > "Jim Granville" <jim.granville@............co.nz> wrote > > > Q: How many test patterns does Xilinx apply, in production, > > to confirm each LUT is functioning correctly ? > > Q: I wonder how Xilinx came to invent the SRL? :) Does Xilinx use LSSD, or are your referring to the SRL16? ---- KeithArticle: 38967
Jim Granville wrote: > Rick Filipkiewicz wrote: > > > <snip> > > > > One thing I've always wondered since I first came across LUT based architectures is: > > > > ``What is the LUT equivalent of Quine-McClusky sum of products reduction ?'' > > > > is there is such a thing. i.e is there a logic reduction algorithm that's always > > guaranteed to find an implementation of any logic function in the minimum number of > > ``levels'' ? Assuming all the inputs are equally critical and ignoring things like > > F5MUXs, carry chains, etc. > > Not sure what you mean. > In a LUT, any combination of 4 IP can be 'mapped', so there is no > resource to > save with logic minimise ? > > The sort of thing I'm thinking of is an arbitrary logic function of a large number, N, of inputs: out = f(in0, in1, ..., inN) what you can always do is (i) determine the minimal sum of products and then (ii) re-arrange the function as a mux: out = in0 & g(in1, ..., inN) | !in0 & h (in1, ..., inN) doing the same for g & h and continuing on its easy to see that, with K input LUTs, the number of logic levels is no more than (N - K) + 1. For Xilinx this is N-3. This seems to be inefficient since most of the LUTs are only using 3 inputs. So the question becomes: Is there an algorithm that can do better than this ?Article: 38968
"Jim Granville" <jim.granville@.........ls.co.nz> wrote > Rick Filipkiewicz wrote: > > > <snip> > > > > One thing I've always wondered since I first came across LUT based architectures is: > > > > ``What is the LUT equivalent of Quine-McClusky sum of products reduction ?'' > > > > is there is such a thing. i.e is there a logic reduction algorithm that's always > > guaranteed to find an implementation of any logic function in the minimum number of > > ``levels'' ? Assuming all the inputs are equally critical and ignoring things like > > F5MUXs, carry chains, etc. > > Not sure what you mean. > In a LUT, any combination of 4 IP can be 'mapped', so there is no > resource to > save with logic minimise ? You need to go hunting for stuff which combines "BDD optimization" with "LUT mapping". Probably a recent DAC proceedings is a good place to start. Of course, min_levels has to be balanced against fanout. Routing costs.Article: 38969
I have been looking at using JTAG boundary scan for board test and it looks like there are more devices that support it than don't. Everything I have read about the Xilinx parts indicate that they will work in boundary scan and the download tool will configure a part with other devices in the chain. Likewise, the TI C67 DSP documentation and emulator software seem to support operation with other devices in the scan chain and the chips support boundary scan. But the fly in the ointment seems to be the MSP430. I have been told by TI support that the MSP430 chips do not support boundary scan. Also, the software does not allow operation while in a scan chain. This is a problem for me since the board I am working on is very small and does not have room for multiple JTAG connectors. Anyone know if the MSP430 can work with an emulator in a JTAG scan chain? The IAR is the only emulator I have looked at. Are there others that work correctly in this case? Are there other MCUs that support a full JTAG implementation along with all the features of the MSP430? The important features are: Self programmable Flash >=8K SRAM 2KB UART IOs >=48 ADC >=4 inputs Analog Comparator Watchdog Internal OSC (no Xtal needed) Very low power <= 10 mA @ full speed Ultra low standby power <= 1 mA at reduced speed And of course, JTAG emulation, programming and boundary scan. Not many devices meet all of these specs. The MSP430 and the PIC18F6620 are the only ones I have found that are also under $10 and the TI is not full JTAG. Anyone know about the PIC18F JTAG compatibility? Anyone have any alternatives??? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 38970
The worst thing you might build would be a synchronous counter with the clock enable fed to every bit in parallel. Don't do that! My sugestion is to build any counter you want, synchronous or ripple, but have a one-bit prescaler toggle-flip-flop generate the clock. This prescaler must use the Xilinx CE feature, which really is a multiplexer in the D input. Since CE changes asynchronously, but does not affect the clock, you never get a runt clock pulse, but you might ( once in a blue moon) get a longer Q delay. It will be many thousands (millions?) of years between the worst happening, when this extra metastable delay swallows one incoming clock tick. Peter Alfke, Xilinx Applications ================================== Theron Hicks wrote: > I am looking for some code to define a glitch less clock enable/disable > circuit. The clock frequency is 100MHz. What I am trying to say is that I > have a counter with a 100MHz clock and I want to avoid runt pulses on the > clock. This could either be a clock mux switching between 0 and clock on > the output or a "safe" clock enable that would eliminate (or at least > minimize) the possibility of metastability. The counter could be > asynchronous if that simplifies things. Any ideas, suggestions, sources, > etc. > > Thanks, > TheronArticle: 38971
Hi All, I am doing research work for a university, and I was recently supplied with a Spartan II VoIP demo kit from Memec. The instructions in the kit assume that I have Synplicity and ModelSim. Unfortunately I only have Xilinx ISE Foundation 4.1i. Part of the kit is a UDP stack core, the file which (I assume) contains the core is called UDPStack.ngo In the application note everything (synthesis and modeling) is done very neatly with pre-built batch files using Synplicity and ModelSim. How do I go about using an ngo file in Foundation so that I can use the core in my own project? I've tried almost every menu, option and tool, including the Core Generator, yet I've achieved no success. I'm fairly new to the programmable logic arena, though I'm learning fast. Please help if you can, as I'm absolutely stumped. Thanks in advance Simon HoffeArticle: 38972
> Thanks for the solution Paul. I am not familiar with conduits, so was > pretty much out of my depth. Not using conduits, you should not need > the WIRE primitive and probably do something like > http://www.tech-forge.com/bustest-steen.qar. > > Regards, > -Steen Thanks for that Steen, If you try and analyse the file however it comes up with various errors associated with the buses you've created. (I'm using 1.1 service pack 2 though, you use SP 1) I had in fact tried that solution since I believed it should work! Disconnecting the single wire from the bus (still calling it <<dataout[7]>>) works so far as analysis passes OK. If you don't disconnect you get width mismatches amongst other things. Unfortunately generating the VHDL shows that the tickpulse connection just gets ignored. I pointed this out in my service request (before I had the WIRE primitive fudge) and they acknowledged that this may be a bug. (In my mind its a bit dubious to happily generate incomplete VHDL. I'd prefer a syntax error or even crash rather than silently ignoring bits of my design....) The use of the WIRE primitive between <<dataout[7]>> and the 'tickpulse' output sorts things out correctly. Its not pretty but the VHDL is OK PaulArticle: 38973
Falk Brunner wrote: > > I think Peter triggerd some inner gost of mine. > I want to compute the EXACT number of unique functions possible with a 4 > input LUT... It depends on the exact definition of a function. To get 64k functions from a 4-bit lut, one could assume that all 4 input bits are dedicated to one function, and that all combinations of inputs are valid. Then by defining function as "the set of input->output maps", there'd by 2^16. However, the LUT inputs can be divided between smaller sub-LUTs, so that for two 2-input LUTs, each has 16 functions, so the total in this case is 2x16=32 functions. Its easy to give a seemingly wrong answer if the question doesn't have enough restrictions.Article: 38974
[push/pop 4 sets of 4 registers] >My question is: what are the pros and cons of instantiating muliplexors vs. >tri-stating a couple of small busses for each flop? This is still in the >planning phase, so I'm considering both gate count and speed. If you are interested in things like that, it's probably worth reading the data sheet a few times to get a better feel for the innards of the chip. (I find that I have to read them several times. The details fit together better each time.) The 4010 is a 20x20 array of CLBs. There are two tri-state lines per CLB. So you get a total of 40 of them. (Maybe two more at the top and bottom?) So you can easily make a 32 bit bus, or possibly two 16 bit busses, either interleaved or above/below eachother. The tri-state long lines go all the way across the chip. You can't split them up into shorter segments. I've never used one for a 3 input MUX. There are generally more valuable things you can do with them. I'm not sure what sort of design you have in mind. The suggestion of using the LUTs as a RAM is one way to avoid the MUX. Note that you might be able to pack two sets or registers (or all 4?) into one set of LUTs. Depends upon how many you need to read at the same time. (If you replicate the RAMs, you can read any two registers at the same time.) Another possibility is to make 4 copies of the rest of the logic. If you think of a column of CLBs as a register, you have some smarts in the LUTs in front of the FFs. If you can use counters rather than adders, you can make "smart" registers that can count, hold, or load without using a main ALU. Maybe you don't need the MUXes at all? For example, you might have one column/register be the DMA address for an external memory, use the tri state bus to get the address to the edge of the chip. Then use another column for the length remaining. You don't need an ALU to bump the pointer or decriment the count - the LUTs in front of the register are smart enough to do that. It's probably worth sketching out several designs and seeing how well they fit the chip resources. (As compared to picking a design and forcing the chip to implement it.) On the other hand, if you already have a design that does what you want and you toss it at the tools and whatever they give you meets timing, then you don't need to consider what's inside the chip. -- These are my opinions, not necessarily my employer's. I hate spam.
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