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 Feb 13, 11:08=A0am, "Symon" <symon_bre...@hotmail.com> wrote: > > Hi Mike, > Did you try Google? > fpga vs microcontroller > Please come back when you have a specific application in mind that a Googl= e > search does help with. > Cheers, Syms. > > p.s. It's very close on Googlefight!http://googlefight.com/index.php?lang= =3Den_GB&word1=3Dfpga&word2=3Dmicrocon... Well, I wasn't really thinking in terms of fpga vs. micro, although I'm sure that's one tradeoff. I was asking more about fpga (with or without a soft core) vs. every other solution, and when fpgas are the right choice, and when they might not be the right choice. Does that make sense? And I don't have any application in mind - just interested in expanding my horizons. MikeArticle: 129051
Mike Silva wrote: > On Feb 13, 11:08 am, "Symon" <symon_bre...@hotmail.com> wrote: >> >> Hi Mike, >> Did you try Google? >> fpga vs microcontroller >> Please come back when you have a specific application in mind that a >> Google >> search does help with. >> Cheers, Syms. >> >> p.s. It's very close on >> Googlefight!http://googlefight.com/index.php?lang=en_GB&word1=fpga&word2=microcon... > > Well, I wasn't really thinking in terms of fpga vs. micro, although > I'm sure that's one tradeoff. I was asking more about fpga (with or > without a soft core) vs. every other solution, and when fpgas are the > right choice, and when they might not be the right choice. Does that > make sense? > > And I don't have any application in mind - just interested in > expanding my horizons. > > Mike Hi Mike, OK, in your OP you mentioned micros, that's why I replied as I did. I'm unsure what else you want to compare with. DSPs are the other old chestnut. Google works for that also! CPLDs? 74 series logic? Cheers, Syms.Article: 129052
>[I posted this to comp.lang.vhdl, but maybe you FPGA experts know the >answer.] > >Hi >I'm not a VHDL expert, just learning, so please don't shout. > >I'm using Xilinx ISE9.2sp4 and have the following code as part of a state >machine: >CP_IN_OUTPUT_DECODE: process (state_cp_in) > begin > if state_cp_in = sta_idle then > RDY <= 'Z'; > BUSY <= '0'; > end if; > > if state_cp_in = sta_1 then > RDY <= '0'; > BUSY <= '0'; > end if; > > if state_cp_in = sta_2 then > RDY <= '1'; > BUSY <= '1'; > end if; >... >...etc > >The state machine goes from sta_idle, then to sta_1, then to sta_2, etc. >RDY is a pin on the device. >During operation, I can see RDY go low in sta_1, but not high in sta_2. I >know it gets to sta_2 as I can observe BUSY. I don't think RDY is tri-stated >in sta_2 as there is an external pull-up; it just stays low. Gray encoding >is used. > >If I change the RDY to rdyi (signal) and then have: >RDY <= 'Z' when state_cp_in = sta_idle else rdyi; >outside of the decode process then it all behaves itself. > >Apart from lack of experience, what mistake(s) have I made? >Thanks. > Check that RDY is not being assigned from another process or concurrent assignment. Check that RDY is not being assigned later in the CP_IN_OUTPUT_DECODE process. That will take precedence. What happens in simulation?Article: 129053
Hi All, I just found this, and thought it might be of interest. Seems to work quite well. http://home.in.tum.de/~jain/software/oe-quotefix/ Cheers, Syms. p.s. I know, I should be using Thunderbird...Article: 129054
"RCIngham" <robert.ingham@gmail.com> wrote in message news:O9mdnTt96ZdbsC7aRVn_vwA@giganews.com... > >[I posted this to comp.lang.vhdl, but maybe you FPGA experts know the >>answer.] >> >>Hi >>I'm not a VHDL expert, just learning, so please don't shout. >> >>I'm using Xilinx ISE9.2sp4 and have the following code as part of a > state >>machine: >>CP_IN_OUTPUT_DECODE: process (state_cp_in) >> begin >> if state_cp_in = sta_idle then >> RDY <= 'Z'; >> BUSY <= '0'; >> end if; >> >> if state_cp_in = sta_1 then >> RDY <= '0'; >> BUSY <= '0'; >> end if; >> >> if state_cp_in = sta_2 then >> RDY <= '1'; >> BUSY <= '1'; >> end if; >>... >>...etc >> >>The state machine goes from sta_idle, then to sta_1, then to sta_2, etc. >>RDY is a pin on the device. >>During operation, I can see RDY go low in sta_1, but not high in sta_2. > I >>know it gets to sta_2 as I can observe BUSY. I don't think RDY is > tri-stated >>in sta_2 as there is an external pull-up; it just stays low. Gray > encoding >>is used. >> >>If I change the RDY to rdyi (signal) and then have: >>RDY <= 'Z' when state_cp_in = sta_idle else rdyi; >>outside of the decode process then it all behaves itself. >> >>Apart from lack of experience, what mistake(s) have I made? >>Thanks. >> > > Check that RDY is not being assigned from another process or concurrent > assignment. RDY isn't assigned in another process. > Check that RDY is not being assigned later in the CP_IN_OUTPUT_DECODE > process. That will take precedence. The state machine has 9 states. RDY is assigned in each state, and only tri-stated in sta_idle. Is this wrong? It seems to be the tri-state assignment that throws it. > What happens in simulation? Ah yes, simulation. As this was supposed to be a simple design, I went straight to hardware and a scope. Thanks.Article: 129055
Mike Silva wrote: > I've been programming embedded micros for a long time, and have a > decent understanding of hardware. I finally ordered an FPGA > development kit (still in the mail) because I find the whole FPGA > concept fascinating. What I don't grasp is when an FPGA is the best > choice. To get a better feel for this, I'd like to hear some comments > on when an FPGA is the best fit, and also when an FPGA turned out to > be a poor choice. Many thanks for any advice. When you cannot do the task with a Microcontroller alone. It is very common to have both, so then the question is one of task allocation, rather than "when an FPGA is the best choice". Micros have advanced quite a bit in recent times, and Atmel are claiming above 200MIPS from flash with AT91SAM9XE series. This uses 128 bit fetch & starts at $7.30/10K - so that device would make a good FPGA companion. -jgArticle: 129056
I would like to know if a FPGA is suited for this application: sound sources localization and separation. The algorithm comes in 3 steps: sources detection using a steered beamformer (in frequency-domain), a particle filter to track the sources and a combination of a geometric source separation algorithm and a non-linear post-filter for source separation. Also, the audio stream comes from an array of 8 microphones, and all possible microphone pairs must be considered during the detection phase. This algorithm is already implemented of a floating point DSP and I would like to know if a FPGA could be a good choice to improve performance. I heard that a FPGA wouldn't beat a DSP in floating point calculation, what do you think about that? Still, I know that an implementation on a FPGA will require a lot of work to translate the code anyway, so I suppose it wouldn't be harder to rethink it directly in fixed point. The FPGA could be used to improve only a fraction of the algorithm too. Thanks for your comments. L-CArticle: 129057
"Dwayne Dilbeck" <ddilbeck@yahoo.com> wrote: >Don't try it. XST will complain that the second operand of DIV and MOD >operators have to be powers of two, atleast, in the webpack version. > >I ran your code and the below code through the Cadence HDL-ICE synthesizer. >(For Emulation only) The case statement was mapped to 188 cells in thier >library, the DIV/MOD mapped to 92 cells. (AND02,OR02,XOR02,INV,etc.) > >But since this code doesn't work in the free ISE it doesn't matter. > >module bcd(ibin, bcd2,bcd1,bcd0); > > input [7:0] ibin; > output[3:0] bcd2, bcd1, bcd0; > > wire [7 : 0] temp [0:1]; > > assign temp[0] = ibin/4'd10; > assign bcd0 = ibin%4'd10; > assign temp[1]= temp[0]/4'd10; > assign bcd1 = temp[0]%4'd10; > assign bcd2 = temp[1]%4'd10; > >endmodule This is static logic, each output is defined by a logical equation containing inputs. Regardless of how you express it in HDL the equations are the same and the synthesiser should minimise and fit them just the same. Shitty that your synthesiser didn't, assuming you really did express the same thing in different ways. --Article: 129058
DJ Delorie wrote: > Jon Elson <elson@wustl.edu> writes: > >>Aughhh! Isn't there a better way to do the binary to BCD conversion? >>Not that there'd be any difference in performance or area, just that >>the brute-force enumeration of all possible states seems ugly. > > > It was pointed out elsewhere that it can be done like this: > > 214 : bcd <= 10'h214 ; > 215 : bcd <= 10'h215 ; > If you can do this, then you can write it in a loop in about 4 lines! (Either Verilog or VHDL) JonArticle: 129059
Mike Silva wrote: > I've been programming embedded micros for a long time, and have a > decent understanding of hardware. I finally ordered an FPGA > development kit (still in the mail) because I find the whole FPGA > concept fascinating. What I don't grasp is when an FPGA is the best > choice. To get a better feel for this, I'd like to hear some comments > on when an FPGA is the best fit, and also when an FPGA turned out to > be a poor choice. Many thanks for any advice. CPU's are serial, they do one thing at a time. One other thing is they can't be clocked by an external transition, ie. that their time to respond to an external event is VERY finite. Something I have made a LOT of are quadrature encoder counters, where you don't want to miss transitions on the quadrature lines. I have the counter clocked at 1 MHz, so I can implement some digital filtering on the quadrature inputs. This allows the counter to count with absolutely guaranteed reliability up to at least 300,000 counts/second. One FPGA handles 4 channels like this with parallel logic. I'd challenge anyone to make a traditional microcontroller do this without dedicated logic on the CPU, just by sampling the input ports. This is a trivial exercise on an FPGA. I also generate PWM signals with 100 ns resolution. This could be done easily with counter/timer functions. JonArticle: 129060
Mike Silva <snarflemike@yahoo.com> wrote: >I've been programming embedded micros for a long time, and have a >decent understanding of hardware. I finally ordered an FPGA >development kit (still in the mail) because I find the whole FPGA >concept fascinating. What I don't grasp is when an FPGA is the best >choice. To get a better feel for this, I'd like to hear some comments >on when an FPGA is the best fit, and also when an FPGA turned out to >be a poor choice. Many thanks for any advice. When you have algorithms that can benefit from: * Parallism * Pipelining * Tight I/O timing FPGA might be an improvement over an asic microcontroller in these cases. FPGA enables you to replicate a microcontroller in FPGA. And add instructions for special hardware operations such that you can combine the simple structure of an MCU with the performance of lowlevel gate operations. FPGA gates are however slower compared to ASIC. So one challenge is to use it in a way that it doesn't matter.Article: 129061
everphilski@gmail.com <everphilski@gmail.com> wrote: > Could I get you to expand on the difference between "DSP hardware" and > "FPGA" in this context? My (albeit new) understanding was, DSP > techniques were implemented on FPGA hardware to do digital signal > processing. Well, first of all, DSP is probably the topic of yours that I know the least about so take anything I say with a couple grains of salt. When I personally think DSP, what comes to mind are things like the TI DSP processors which were/are more like general purpose CPUs with an emphasis on high-speed fixed- or floating-point math rather than being a general purpose "sea of gates" as an FPGA is. TI has some introductory info here it looks like: http://focus.ti.com/dsp/docs/dspsupporto.tsp?sectionId=4&tabId=1443 Modern FPGAs have some of the basic building blocks (interger multiply units, etc.) that make it possible to do traditional DSP processing, but you're still mostly building up a machine from scratch to do what you want rather than just writing a program to express an algorithm. I don't think it's always easy to answer the question of what should be done in hardware versus software. Often there are techniques to do it either way, and the background of the particular designer tends to tilt the decision more than anything else. FPGAs are incredibly cool. They're great when you need boatloads of exotic I/Os, extreme parallelism, and complete flexibility. They don't make great general purpose CPUs usually. From a software point of view they're again the most flexible but probably also the most complex. From a hardware point of view they're pretty much all cutting-edge technology and none of their design is there to make the life of a hobbyist easy, so building your own FPGA-based hardware designs is pretty complex. Fortunately there are lots of inexpensive boards you can buy to experiment with. If you pick up an FPGA board to play with and spend some time with it then I don't think you'll regret that learning experience at all. Whether at the end you decide that the FPGA route is your best one for implementing the things you want to do is something you'll only know once you get there. G.Article: 129062
Mike Silva wrote: > What I don't grasp is when an FPGA is the best choice. To get a better > feel for this, I'd like to hear some comments > on when an FPGA is the best fit, and also when an FPGA turned out to > be a poor choice. The general answer is that the FPGA is the best fit when the FPGA-based solution is less costly than the non-FPGA-based solution. However, one usually has to consider development and support costs, not just the BOM cost of the hardware. So how does one determine which will be less costly? The only way I've found is to do at least a rough block diagram and BOM for each. For my designs, I've found that the choice isn't usually between an FPGA and something else, but rather between an FPGA alone, or a microcontroller with a smaller FPGA.Article: 129063
everphilski@gmail.com wrote: > Rob, > > On Feb 13, 4:18 am, Rob <BertyBoos...@googlemail.com> wrote: > >>>Xilinx's FireBlaze processor simulation on a FPGA. >> >>Do you mean Xilinx's MicroBlaze processor? If so, note that this is a >>general purpose CPU with a fairly average MIPs spec. You'd easily be >>able to get comparable or better performance with an off the shelf >>microprocessor -and without all the headaches! > > > Yes, I meant MicroBlaze, thanks for catching the typo. This is good, > so you are saying you would prefer working with a discrete > microcontroller interfaced to a FPGA, instead of a FPGA with a > MicroBlaze (or other core) onboard? PFGA+MicroBlaze lacks code memory, so that's a significant cost. Generally, if you can find a single chip uC that will fit your task, you get the EMC & reliability benefits of on-chip memory, and also (probably) get to use a smaller/cheaper FPGA+LoaderPROM A good topical example of a companion processor for FPGA, would be the Atmel AT91SAM9XE series. 200+ MIPS, from 128 bit wide flash, and $7.30/10K, with 128/256/512K FLASH. Plus all this fruit: [USB 2.0 Full Speed Host and Device Ports, an Ethernet 10/100 Base-T MAC as well as a two-slot Multimedia Card Interface (SDCard/SDIO and MultiMediaCard Compliant), a Synchronous Serial Controller (SSC), four USARTs, two master/slave Serial Peripheral Interfaces (SPI), a debug UART and two Two Wire Interfaces (TWI).] If you need megabytes of code, then the balance tips back a little. -jgArticle: 129064
Jon Elson wrote: > DJ Delorie wrote: >> Jon Elson <elson@wustl.edu> writes: >> >>> Aughhh! Isn't there a better way to do the binary to BCD conversion? >>> Not that there'd be any difference in performance or area, just that >>> the brute-force enumeration of all possible states seems ugly. >> >> >> It was pointed out elsewhere that it can be done like this: >> >> 214 : bcd <= 10'h214 ; >> 215 : bcd <= 10'h215 ; >> > If you can do this, then you can write it in a loop in about 4 lines! > (Either Verilog or VHDL) Sounds interesting. Can you elaborate ?Article: 129065
Jon Elson <elson@wustl.edu> wrote: > Something I have made a LOT of are quadrature encoder counters, where > you don't want to miss transitions on the quadrature lines. I have the > counter clocked at 1 MHz, so I can implement some digital filtering on > the quadrature inputs. This allows the counter to count with absolutely > guaranteed reliability up to at least 300,000 counts/second. One FPGA > handles 4 channels like this with parallel logic. I'd challenge anyone > to make a traditional microcontroller do this without dedicated logic on > the CPU, just by sampling the input ports. I think you could do it on a slightly non-traditional microcontroller, i.e. the Parallax Propeller, which would let you dedicate one cpu core to each set of I/O lines. Clocked at 80Mhz you would get up to 20 instructions per microsecond to deal with your 1 MHz event stream. One of the primary design ideas of the Propeller seems to be that CPU cores are so cheap we don't need to support interrupts at all. You just dedicate a CPU to each external device and it basically operates synchronously with resepect to that device. It's an interesting idea, and when mainstream processors start having >16 cores, it will also be interesting to see when people start "throwing away" things like x86 cores in a similar fashion. G.Article: 129066
On Feb 13, 1:32=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Mike Silva wrote: > > I've been programming embedded micros for a long time, and have a > > decent understanding of hardware. =A0I finally ordered an FPGA > > development kit (still in the mail) because I find the whole FPGA > > concept fascinating. =A0What I don't grasp is when an FPGA is the best > > choice. =A0To get a better feel for this, I'd like to hear some comments= > > on when an FPGA is the best fit, and also when an FPGA turned out to > > be a poor choice. =A0Many thanks for any advice. > > When you cannot do the task with a Microcontroller alone. > It is very common to have both, so then the question is one > of task allocation, rather than "when an FPGA is the best choice". Sounds reasonable. Is the more usual case then to have both micro(s) and FPGA(s) together, as opposed to FPGA without micro? Is FPGA without attached (or internal) micro an uncommon situation? MikeArticle: 129067
Jon Elson wrote: > Something I have made a LOT of are quadrature encoder counters, where > you don't want to miss transitions on the quadrature lines. I have the > counter clocked at 1 MHz, so I can implement some digital filtering on > the quadrature inputs. This allows the counter to count with absolutely > guaranteed reliability up to at least 300,000 counts/second. One FPGA > handles 4 channels like this with parallel logic. I'd challenge anyone > to make a traditional microcontroller do this without dedicated logic on > the CPU, just by sampling the input ports. Surprisingly few uC have Quadrature inputs, given that the logic is not large in uC terms. Winbond have just released a group (W79E22x), with encoder to 1/4 FCPU per half period ( so max INC/DEC rate is fCPU/2 I think ) The old 89C52 added DIRN, which allows a coarse quadrature support, of one INC/DEC per whole cycle, but that's only one quarter of the possible resolution. A small PLD can pre-condition to give the higher resolution. > This is a trivial exercise on an FPGA. I also generate PWM signals with 100 ns resolution. > This could be done easily with counter/timer functions. Or a CPLD, where it will fit. A common weakness in uC, is that the Peripherals cannot clock faster than the core, so you can get situations where you need a fast CPU clock, just to run the peripherals (and get the power impact of that in the core)... Of course, most modern FPGAs are not helping the power budgets at all... :( -jgArticle: 129068
GMM50 wrote: > Hi All: > > This may indeed be a problem but how does debug make it all work. > > george In my experience the most common scenario is a lack of "volatile" keyword. Debug version turns optimization off and release version optimizes a read of a hardware register out, 'cause it doesn't know it is hardware and nothing in the code changes it's value. The second possibility is a race condition. Dubug version may execute more slowly. -Alex.Article: 129069
If you want to get a feel for what you can do with Virtex-5, click on http://www.pldesignline.com/howto/206503253;jsessionid=S30OVRH051RUYQSNDLPCKH0CJUNN2JVN This was a labor of love. Something like it should have been written ten years ago, but: "Better late than never". Hope you like it, and can draw some benefit from it. Please don't hesitate to post or send me comments of any kind. Anything good can always be improved! (BTW, I have 30 patents, not 4. And the picture is 15 years old. Residual vanity...) Peter Alfke, XilinxArticle: 129070
Hi, 1) Does a microprocessor in debug mode run on a slower clock? I din know that 2) under what circumstances should what variables be volatile? Chris On Feb 14, 5:58=A0am, Alex Freed <al...@mirrow.com> wrote: > GMM50 wrote: > > Hi All: > > > This may indeed be a problem but how does debug make it all work. > > > george > > In my experience the most common scenario is a lack of "volatile" > keyword. Debug version turns optimization off and release version > optimizes a read of a hardware register out, 'cause it doesn't know it > is hardware and nothing in the code changes it's value. > > The second possibility is a race condition. Dubug version may execute > more slowly. > > -Alex.Article: 129071
On Feb 14, 6:59 am, "Grumps" <grumpsnoth...@hotmail.com> wrote: > "RCIngham" <robert.ing...@gmail.com> wrote in message > > news:O9mdnTt96ZdbsC7aRVn_vwA@giganews.com... > > > > > > > >[I posted this to comp.lang.vhdl, but maybe you FPGA experts know the > >>answer.] > > >>Hi > >>I'm not a VHDL expert, just learning, so please don't shout. > > >>I'm using Xilinx ISE9.2sp4 and have the following code as part of a > > state > >>machine: > >>CP_IN_OUTPUT_DECODE: process (state_cp_in) > >> begin > >> if state_cp_in =3D sta_idle then > >> RDY <=3D 'Z'; > >> BUSY <=3D '0'; > >> end if; > > >> if state_cp_in =3D sta_1 then > >> RDY <=3D '0'; > >> BUSY <=3D '0'; > >> end if; > > >> if state_cp_in =3D sta_2 then > >> RDY <=3D '1'; > >> BUSY <=3D '1'; > >> end if; > >>... > >>...etc > > >>The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.= > >>RDY is a pin on the device. > >>During operation, I can see RDY go low in sta_1, but not high in sta_2. > > I > >>know it gets to sta_2 as I can observe BUSY. I don't think RDY is > > tri-stated > >>in sta_2 as there is an external pull-up; it just stays low. Gray > > encoding > >>is used. > > >>If I change the RDY to rdyi (signal) and then have: > >>RDY <=3D 'Z' when state_cp_in =3D sta_idle else rdyi; > >>outside of the decode process then it all behaves itself. > > >>Apart from lack of experience, what mistake(s) have I made? > >>Thanks. > > > Check that RDY is not being assigned from another process or concurrent > > assignment. > > RDY isn't assigned in another process. > > > Check that RDY is not being assigned later in the CP_IN_OUTPUT_DECODE > > process. That will take precedence. > > The state machine has 9 states. RDY is assigned in each state, and only > tri-stated in sta_idle. Is this wrong? > It seems to be the tri-state assignment that throws it. > > > What happens in simulation? > > Ah yes, simulation. As this was supposed to be a simple design, I went > straight to hardware and a scope. > Thanks.- Hide quoted text - > > - Show quoted text - I'm saying that only because you said you were a beginner, not because of you code =83=BA. Anyway look at a state machine, it's usually a mishmash of flipflops and logic gates. A tristate is usually a buffer on a bus. In hardware that's 2 different jobs. So do something like this 1st describe a tri-state buffer something like signal MY_BUFFER_OUT, MY_BUFFER_IN, MY_BUFFER_CONTROL : std_logic; MY_BUFFER_OUT <=3D MY_BUFFER_IN when MY_BUFFER_CONTROL =3D '1' else 'Z'; Assign MY_BUFFER_CONTROL from your state machine, only assign 1 and 0 to RDY, connect MY_BUFFER_OUT to your port and MY_BUFFER_IN to the equivalent of RDY. This looks exactly the same if you think of it in software terms but it's a different beast altogether if you take a hardware view. I'd just like to add, I'm glad to see your using ISE, unlike the more expensive tools it wont accept nonsense, my advice is stick with ISE until your competent, then don't lose those good coding habbits. Let me know how it goes BobsterthelobsterArticle: 129072
Sorry only half the post went :-) here it is again Hi Grumps, You say you=A1=A6re a beginner, so please allow me to offer the one piece of advice that you should never waver from. You are designing hardware, its not software, if you ignore that point you=A1=A6ll join the ranks of people that are giving the industry a bad name with their unstable designs. Always try to imagine the circuit you=A1=A6re describing, and you won=A1=A6t= go far wrong. I=A1=A6m saying that only because you said you were a beginner, not because of you code =83=BA. Anyway look at a state machine, it=A1=A6s usually a mishmash of flipflops and logic gates. A tristate is usually a buffer on a bus. In hardware that=A1=A6s 2 different jobs. So do something like this 1st describe a tri-state buffer something like signal MY_BUFFER_OUT, MY_BUFFER_IN, MY_BUFFER_CONTROL : std_logic; MY_BUFFER_OUT <=3D MY_BUFFER_IN when MY_BUFFER_CONTROL =3D =A1=A51=A1=A6 els= e =A1=A5Z=A1=A6; Assign MY_BUFFER_CONTROL from your state machine, only assign 1 and 0 to RDY, connect MY_BUFFER_OUT to your port and MY_BUFFER_IN to the equivalent of RDY. This looks exactly the same if you think of it in software terms but it=A1=A6s a different beast altogether if you take a hardware view. I=A1=A6d just like to add, I=A1=A6m glad to see your using ISE, unlike the m= ore expensive tools it wont accept nonsense, my advice is stick with ISE until your competent, then don=A1=A6t lose those good coding habbits. Let me know how it goes BobsterthelobsterArticle: 129073
Thanks Peter Its an almost effortless, easy read, but still informative, a translation from xilinx to English, LOL,, well done that man Well I for one intend to keep a copy of it.Article: 129074
Hi Peter, "The array size is between 8 Mb and 79 Mb (1 to 10 MB)," When your photo was taken, 15 years ago*, was when I started work on a new design using brand new XC4000 series parts. My PC's hard disk was 10MB! That's a nice article, one that I planning on linking to! Cheers, Syms. * Also, I had to get up in the morning at ten o'clock at night half an hour before I went to bed, drink a cup of sulphuric acid, work twenty-nine hours a day down mill, and pay mill owner for permission to come to work, and when we got home, our Dad and our mother would kill us and dance about on our graves singing Hallelujah.
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