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

Custom Search

On 01/06/12 08:53, aleksazr@gmail.com wrote: > I'm learning the diff between variables and signals, > and I've found this site: > http://esd.cs.ucr.edu/labs/tutorial/sig_var.vhd > with a corresponding picture here: > http://esd.cs.ucr.edu/labs/tutorial/sig_var.jpg > > I've changed the source file to this > > library ieee; > use ieee.std_logic_1164.all; > > entity sig_var is port ( > d1, d2, d3 : in std_logic; > res1, res2, res3 : out std_logic); > end sig_var; > > architecture behv of sig_var is > signal sig_s1: std_logic; > signal sig_s2: std_logic; > > begin > > proc1: process(d1,d2,d3) > variable var_s1: std_logic; > > begin > var_s1 := d1 and d2; > res1 <= var_s1 xor d3; > end process; > > proc2: process (d1,d2,d3) > begin > sig_s1 <= d1 and d2; > res2 <= sig_s1 xor d3; > end process; > > sig_s2 <= d1 and d2; > res3 <= sig_s2 xor d3; > > end behv; > > > and this are the simulation results: > http://img521.imageshack.us/img521/346/simulations.gif > > As you can see, behavioral and post-route don't match. > Is there something wrong with the VHD source, > or I just don't get the idea behind behavioral simulation? There's an error in your proc2 - sig_s1 should be in the sensitivity list, regards Alan > > Post route works as I have expected. > > (I've started this thread as a variable/signal issue, > but it turned into behavioral/post-route simulation.) -- Alan Fitch

On Friday, June 1, 2012 11:07:44 AM UTC+2, Alan Fitch wrote: > On 01/06/12 08:53, aleksazr@gmail.com wrote: > > I'm learning the diff between variables and signals, > > and I've found this site: > > http://esd.cs.ucr.edu/labs/tutorial/sig_var.vhd > > with a corresponding picture here: > > http://esd.cs.ucr.edu/labs/tutorial/sig_var.jpg > > > > I've changed the source file to this > > > > library ieee; > > use ieee.std_logic_1164.all; > > > > entity sig_var is port ( > > d1, d2, d3 : in std_logic; > > res1, res2, res3 : out std_logic); > > end sig_var; > > > > architecture behv of sig_var is > > signal sig_s1: std_logic; > > signal sig_s2: std_logic; > > > > begin > > > > proc1: process(d1,d2,d3) > > variable var_s1: std_logic; > > > > begin > > var_s1 := d1 and d2; > > res1 <= var_s1 xor d3; > > end process; > > > > proc2: process (d1,d2,d3) > > begin > > sig_s1 <= d1 and d2; > > res2 <= sig_s1 xor d3; > > end process; > > > > sig_s2 <= d1 and d2; > > res3 <= sig_s2 xor d3; > > > > end behv; > > > > > > and this are the simulation results: > > http://img521.imageshack.us/img521/346/simulations.gif > > > > As you can see, behavioral and post-route don't match. > > Is there something wrong with the VHD source, > > or I just don't get the idea behind behavioral simulation? > > There's an error in your proc2 - sig_s1 should be in the sensitivity list, > > regards > Alan > > > > > Post route works as I have expected. > > > > (I've started this thread as a variable/signal issue, > > but it turned into behavioral/post-route simulation.) > > > -- > Alan Fitch Yes, that fixed it. Now both simulations show the same. Too bad ISE doesn't support the ALL keyword. (sig_s1 is missing in the original file as well, and ISE didn't warn me about it) Thanks

On 01/06/12 15:02, aleksazr@gmail.com wrote: > On Friday, June 1, 2012 11:07:44 AM UTC+2, Alan Fitch wrote: >> On 01/06/12 08:53, aleksazr@gmail.com wrote: >>> I'm learning the diff between variables and signals, >>> and I've found this site: >>> http://esd.cs.ucr.edu/labs/tutorial/sig_var.vhd >>> with a corresponding picture here: >>> http://esd.cs.ucr.edu/labs/tutorial/sig_var.jpg >>> >>> I've changed the source file to this <snip> >>> >>> As you can see, behavioral and post-route don't match. >>> Is there something wrong with the VHD source, >>> or I just don't get the idea behind behavioral simulation? >> >> There's an error in your proc2 - sig_s1 should be in the sensitivity list, >> >> regards >> Alan >> >>> >>> Post route works as I have expected. >>> >>> (I've started this thread as a variable/signal issue, >>> but it turned into behavioral/post-route simulation.) >> >> >> -- >> Alan Fitch > > Yes, that fixed it. Now both simulations show the same. > Too bad ISE doesn't support the ALL keyword. > (sig_s1 is missing in the original file as well, > and ISE didn't warn me about it) > > Thanks Yes, it's interesting that Isim (the Xilinx Simulator) seems to have some VHDL 2008 support. It'll be interesting to see what the language support for synthesis is like in Vivado, Alan -- Alan Fitch

I need a multi-bit PRNG which generates a sequence of 10-bit pseudo random numbers. Can I use a LFSR of sufficient length (31 bit, for example), and get a new random number on each clock by using the 10 least significant bits, or do I have to use 10 independent LFSR's of different length, one for each bit? Thanks, Thomas

In article <a2s3v7Fv1fU1@mid.individual.net>, Thomas Heller <theller@ctypes.org> wrote: >I need a multi-bit PRNG which generates a sequence of 10-bit pseudo >random numbers. > >Can I use a LFSR of sufficient length (31 bit, for example), and get >a new random number on each clock by using the 10 least significant >bits, or do I have to use 10 independent LFSR's of different length, one >for each bit? How important is it that the numbers are uncorrelated? The 10 LSBs of an LFSR at time t+1 will be nine of the bits from time t and one new one, so if you saw 100 at time t you know it's either 200 or 201 next go. If that's OK, use the end of one LFSR; if not, use several. But if it's actually important that the random numbers are unpredictable, don't use LFSRs: given 3n bits from a length-n LFSR you can pretty much write down the rest of the sequence. Tom

On Jun 1, 11:04=A0am, Thomas Heller <thel...@ctypes.org> wrote: > I need a multi-bit PRNG which generates a sequence of 10-bit pseudo > random numbers. > > Can I use a LFSR of sufficient length (31 bit, for example), and get > a new random number on each clock by using the 10 least significant > bits, or do I have to use 10 independent LFSR's of different length, one > for each bit? > > Thanks, > Thomas LFSRs are typically specified as one bit at a time arrangements. As to the LFSR to use, you don't need a 31 bit LFSR to get a 10 bit result. Even if you use a 31 bit LFSR you need to turn the crank 10 times to get 10 unique bits, otherwise adjacent numbers will have strong correlations. There is no reason that an LFSR has to generate one bit at a time. If you do the math you can produce the next 10 bits in one clock cycle which is what I believe you are thinking of doing. Doing the math is just a matter of iterating on the calculations 10 times. Some of the bits get a bit long winded, but it is nothing you can't do without too much trouble. The hard part is to not make an error, so I suggest that you verify the results between simulations of a single bit approach and a multiple bit approach. Rick

On Jun 1, 12:02=A0pm, Thomas Womack <twom...@chiark.greenend.org.uk> wrote: > In article <a2s3v7Fv1...@mid.individual.net>, > Thomas Heller =A0<thel...@ctypes.org> wrote: > > >I need a multi-bit PRNG which generates a sequence of 10-bit pseudo > >random numbers. > > >Can I use a LFSR of sufficient length (31 bit, for example), and get > >a new random number on each clock by using the 10 least significant > >bits, or do I have to use 10 independent LFSR's of different length, one > >for each bit? > > How important is it that the numbers are uncorrelated? =A0The 10 LSBs of > an LFSR at time t+1 will be nine of the bits from time t and one new > one, so if you saw 100 at time t you know it's either 200 or 201 next > go. =A0If that's OK, use the end of one LFSR; if not, use several. > > But if it's actually important that the random numbers are > unpredictable, don't use LFSRs: given 3n bits from a length-n LFSR you > can pretty much write down the rest of the sequence. > > Tom How would you know which length-n to use? I believe that every maximal-length sequence must include all sequences of lesser length. So how exactly do you determine that you have seen enough data that can identify which length-n you are working with? Don't you have to continue monitoring until the sequence repeats? Rick

In article <c6ec76d4-f2fc-4ebd-96b8-ae8e5aca3ee5@3g2000vbx.googlegroups.com>, rickman <gnuarm@gmail.com> wrote: >How would you know which length-n to use? Pick a large K and a smaller L, write out the KxL matrix with row N being bits N through N+K, and ask your favourite linear-algebra-over-GF(2) package whether it has a non-trivial kernel; if it doesn't, increase L or K and try again. If it does, check whether the relation implied by the kernel works for all the rest of the bits. This will work whenever L is greater than n and K greater than 2n (I think) > I believe that every >maximal-length sequence must include all sequences of lesser length. No; consider the sequence x_3 = x_0 + x_2 (which goes 0011101 repeating) and the sequence x_4 = x+0 + x_3 (which goes 000111101011001 repeating) ; the former sequence isn't a subsequence of the latter. Any maximal-length sequence (that is, of length 2^n - 1) will contain all 2^n - 1 sets of n bits not all zero as subsequences, but that's not the statement you were making. Tom

On Fri, 01 Jun 2012 09:15:19 -0700, rickman wrote: > On Jun 1, 11:04Â am, Thomas Heller <thel...@ctypes.org> wrote: >> I need a multi-bit PRNG which generates a sequence of 10-bit pseudo >> random numbers. >> >> Can I use a LFSR of sufficient length (31 bit, for example), and get a >> new random number on each clock by using the 10 least significant bits, >> or do I have to use 10 independent LFSR's of different length, one for >> each bit? >> >> Thanks, >> Thomas > > LFSRs are typically specified as one bit at a time arrangements. As to > the LFSR to use, you don't need a 31 bit LFSR to get a 10 bit result. > Even if you use a 31 bit LFSR you need to turn the crank 10 times to get > 10 unique bits, otherwise adjacent numbers will have strong > correlations. > > There is no reason that an LFSR has to generate one bit at a time. If > you do the math you can produce the next 10 bits in one clock cycle > which is what I believe you are thinking of doing. > > Doing the math is just a matter of iterating on the calculations 10 > times. Some of the bits get a bit long winded, but it is nothing you > can't do without too much trouble. The hard part is to not make an > error, so I suggest that you verify the results between simulations of a > single bit approach and a multiple bit approach. It's probably more challenging than you make it sound, because there's a lot of XORing going on -- but it can probably be done, and it may even be amenable to pipelining. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com

On Fri, 01 Jun 2012 17:02:10 +0100, Thomas Womack wrote: > In article <a2s3v7Fv1fU1@mid.individual.net>, Thomas Heller > <theller@ctypes.org> wrote: >>I need a multi-bit PRNG which generates a sequence of 10-bit pseudo >>random numbers. >> >>Can I use a LFSR of sufficient length (31 bit, for example), and get a >>new random number on each clock by using the 10 least significant bits, >>or do I have to use 10 independent LFSR's of different length, one for >>each bit? > > How important is it that the numbers are uncorrelated? The 10 LSBs of > an LFSR at time t+1 will be nine of the bits from time t and one new > one, so if you saw 100 at time t you know it's either 200 or 201 next > go. If that's OK, use the end of one LFSR; if not, use several. > > But if it's actually important that the random numbers are > unpredictable, don't use LFSRs: given 3n bits from a length-n LFSR you > can pretty much write down the rest of the sequence. I've only scratched the surface of cryptographicaly secure random number generation -- are there any schemes that are amenable to working on an FPGA? Most of the ones that I've seen have a divide in there someplace, and divides are expensive... -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com

In article <gISdner7drm2aVXSnZ2dnUVZ_oSdnZ2d@web-ster.com>, Tim Wescott <tim@seemywebsite.com> wrote: >On Fri, 01 Jun 2012 09:15:19 -0700, rickman wrote: >> Doing the math is just a matter of iterating on the calculations 10 >> times. Some of the bits get a bit long winded, but it is nothing you >> can't do without too much trouble. The hard part is to not make an >> error, so I suggest that you verify the results between simulations of a >> single bit approach and a multiple bit approach. > >It's probably more challenging than you make it sound, because there's a >lot of XORing going on But the lovely thing about XORing is that it's linear; I would hope that any optimiser worth the name could take the for-loop version and convert it to the correct pile of XOR gates. Certainly you shouldn't be doing that sort of Boolean algebra by hand in order to feed it to an optimising Boolean algebra tool! I'd be surprised if you needed to pipeline very much, though I guess a full 32-input XOR is three layers of 4-LUT (eleven LUTs) or two of 6-LUT (seven LUTs) deep. Bit of a routing nightmare but it feels like the sort of thing that P&R software designers use as a test-case. Tom

On 06/01/2012 06:56 PM, Tim Wescott wrote: > On Fri, 01 Jun 2012 09:15:19 -0700, rickman wrote: > >> On Jun 1, 11:04 am, Thomas Heller<thel...@ctypes.org> wrote: >>> I need a multi-bit PRNG which generates a sequence of 10-bit pseudo >>> random numbers. >>> >>> Can I use a LFSR of sufficient length (31 bit, for example), and get a >>> new random number on each clock by using the 10 least significant bits, >>> or do I have to use 10 independent LFSR's of different length, one for >>> each bit? >>> >>> Thanks, >>> Thomas >> >> LFSRs are typically specified as one bit at a time arrangements. As to >> the LFSR to use, you don't need a 31 bit LFSR to get a 10 bit result. >> Even if you use a 31 bit LFSR you need to turn the crank 10 times to get >> 10 unique bits, otherwise adjacent numbers will have strong >> correlations. >> >> There is no reason that an LFSR has to generate one bit at a time. If >> you do the math you can produce the next 10 bits in one clock cycle >> which is what I believe you are thinking of doing. >> >> Doing the math is just a matter of iterating on the calculations 10 >> times. Some of the bits get a bit long winded, but it is nothing you >> can't do without too much trouble. The hard part is to not make an >> error, so I suggest that you verify the results between simulations of a >> single bit approach and a multiple bit approach. > > It's probably more challenging than you make it sound, because there's a > lot of XORing going on -- but it can probably be done, and it may even be > amenable to pipelining. Come on guys, this problem has been solved a long time ago. Either put a for-loop around the bit-serial implementation and use synthesis, or use the Easics tool for a pre-digested version: http://www.easics.com/webtools/crctool -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com

Thomas Heller <theller@ctypes.org> wrote: > I need a multi-bit PRNG which generates a sequence of 10-bit pseudo > random numbers. > Can I use a LFSR of sufficient length (31 bit, for example), and get > a new random number on each clock by using the 10 least significant > bits, or do I have to use 10 independent LFSR's of different length, > one for each bit? First, there are two different ways to implement LFSRs. The way commonly implemented in sofware is to take the shifted output and XOR it with some of the bits of the register. That can conveniently be done N bits at a time with a 2**N entry lookup table. That can also be done in hardware. A more common hardware implementation is to feed a shift register input with the XOR of some of the register bits. The two can be shown to be equivalent, though the actual register contents at any point are not the same. As to the OP, in the latter implementation the low bits at each clock are just a shifted version of those from the previous clock cycle, so not so random. In the former one, though, depending on where the taps are, the bits won't be exactly shifted, but will still have some correlations. Note, though, that you don't need to take the low 10 bits, but other combinations of 10 bits (such as every 3rd bit) could also be used. Or even the XOR of some combinations of bits. The outputs of ten 32 bit LFSRs is more closely related to ten bits of a 320 bit LFSR, though. Taking the appropriate combination of bits from a sufficiently long generator should be random enough. You need to figure out how many bits long, and which bits to take. (That is, it will be the result of a slightly less than maximal 320 bit LFSR.) As you note, for the most randomness use ten LFSRs of ten different lengths. Again, equivalent to an appropriate LFSR of the total number of bits. -- glen

Am 01.06.2012 18:57, schrieb Tim Wescott: > On Fri, 01 Jun 2012 17:02:10 +0100, Thomas Womack wrote: > >> In article<a2s3v7Fv1fU1@mid.individual.net>, Thomas Heller >> <theller@ctypes.org> wrote: >>> I need a multi-bit PRNG which generates a sequence of 10-bit pseudo >>> random numbers. >>> >>> Can I use a LFSR of sufficient length (31 bit, for example), and get a >>> new random number on each clock by using the 10 least significant bits, >>> or do I have to use 10 independent LFSR's of different length, one for >>> each bit? >> >> How important is it that the numbers are uncorrelated? The 10 LSBs of >> an LFSR at time t+1 will be nine of the bits from time t and one new >> one, so if you saw 100 at time t you know it's either 200 or 201 next >> go. If that's OK, use the end of one LFSR; if not, use several. >> >> But if it's actually important that the random numbers are >> unpredictable, don't use LFSRs: given 3n bits from a length-n LFSR you >> can pretty much write down the rest of the sequence. > > I've only scratched the surface of cryptographicaly secure random number > generation -- are there any schemes that are amenable to working on an > FPGA? FYI: I found interesting papers about true (and pseudo) random number generation in FPGAs. They are using ff metastability or PLL jitter for this: http://people.csail.mit.edu/devadas/pubs/ches-fpga-random.pdf http://www.cse.cuhk.edu.hk/~phwl/mt/public/archives/papers/tprng_fccm03.pdf Thomas

Am 01.06.2012 18:02, schrieb Thomas Womack: > In article<a2s3v7Fv1fU1@mid.individual.net>, > Thomas Heller<theller@ctypes.org> wrote: >> I need a multi-bit PRNG which generates a sequence of 10-bit pseudo >> random numbers. >> >> Can I use a LFSR of sufficient length (31 bit, for example), and get >> a new random number on each clock by using the 10 least significant >> bits, or do I have to use 10 independent LFSR's of different length, one >> for each bit? > > How important is it that the numbers are uncorrelated? The 10 LSBs of > an LFSR at time t+1 will be nine of the bits from time t and one new > one, so if you saw 100 at time t you know it's either 200 or 201 next > go. If that's OK, use the end of one LFSR; if not, use several. My requirements are (I guess) pretty weak. The use case is difficult to explain; I'll try with this model: I will collect the numbers into a histogram; the counts in the histogram bins should increase 'statistically', without any visible pattern. Thanks for all the suggestions; will give me some interesting thoughts over the weekend. Thomas

Thomas Heller wrote: > I need a multi-bit PRNG which generates a sequence of 10-bit pseudo > random numbers. > > Can I use a LFSR of sufficient length (31 bit, for example), and get > a new random number on each clock by using the 10 least significant > bits, or do I have to use 10 independent LFSR's of different length, one > for each bit? Well, obviously, if your use one LFSR, at each clock, you only get ONE new bit, all the others are old, just moved to another position. That's not too random. Jon

In article <jqb17h$mj3$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >The outputs of ten 32 bit LFSRs is more closely related >to ten bits of a 320 bit LFSR, though. Not really; in particular the period is 2^32 rather than 2^320. Of course period 2^32 is good enough for many applications, and the original poster's task doesn't require cryptographic quality. >As you note, for the most randomness use ten LFSRs of >ten different lengths. Again, equivalent to an appropriate >LFSR of the total number of bits. Not quite if the lengths aren't coprime (a 4-bit period-15 and 6-bit period-63 LFSR produce a cycle length of 315, which you can't do with an LFSR of ten bits no matter what polynomial you choose. (or is the EE definition of LFSR different from the mathematical one? I reckon that an LFSR is anything defined by f(t) as a XOR together of the values of f(t-a_i) for some fixed set of a_i) Tom

Thomas Heller wrote: > > My requirements are (I guess) pretty weak. The use case is difficult > to explain; I'll try with this model: > > I will collect the numbers into a histogram; the counts in the > histogram bins should increase 'statistically', without any visible > pattern. Are you familiar with the Mersenne Twister? I used some GPL VHDL code in a project a long time ago. http://www.ht-lab.com/freecores/mt32/mersenne.html Pete

Thomas Womack <twomack@chiark.greenend.org.uk> wrote: > In article <jqb17h$mj3$1@speranza.aioe.org>, (snip, I wrote) >>The outputs of ten 32 bit LFSRs is more closely related >>to ten bits of a 320 bit LFSR, though. > Not really; in particular the period is 2^32 rather than 2^320. Of > course period 2^32 is good enough for many applications, and the > original poster's task doesn't require cryptographic quality. Yes. If you need enough random numbers, or even just enough randomness, to notice the period of 2**32. Using the low bits off a 32 bit LFSR gives short term correlations, where ten 32 bit LFSR's, started appropriately, doesn't. >>As you note, for the most randomness use ten LFSRs of >>ten different lengths. Again, equivalent to an appropriate >>LFSR of the total number of bits. > Not quite if the lengths aren't coprime (a 4-bit period-15 and 6-bit > period-63 LFSR produce a cycle length of 315, which you can't do with > an LFSR of ten bits no matter what polynomial you choose. Yes, I should have put more "sort of" in there. Actually, I am not so sure I know how it works if you choose a non-primitive polynomial. It is usual to discuss only the maximal length cycle, but the hardware doesn't require that. > (or is the EE definition of LFSR different from the mathematical one? > I reckon that an LFSR is anything defined by f(t) as a XOR together of > the values of f(t-a_i) for some fixed set of a_i) Well, LFSR pretty much describes a physical system, not a logical (mathematical) one. It might be that the EE definition includes any combination of XOR gates and shift registers. The math is usually done in terms of factoring polynomials modulo 2, which is more restrictive. -- glen

There are too many FPGAa and CPLDs. I can see that LCMXO2280-B-EVN has 8 40-pin connectors, which is important to me. But what else is there and what I am missing. And then there is Xilinx too. By the way, what is CPLD, a fancy name for a FPGA? Does Altera store sell to individual or only business?

LM wrote: > There are too many FPGAa and CPLDs. I can see that LCMXO2280-B-EVN has 8 > 40-pin connectors, which is important to me. But what else is there and > what I am missing. And then there is Xilinx too. > > By the way, what is CPLD, a fancy name for a FPGA? > Years ago, there used to be PALs, very small programmable devices, maybe a dozen wide gates, maybe with 8 FFs, too. Somebody decided to make a "super" PAL, and put 4 or 8 of the standard 22V10 on one chip. Xilinx bought out this line, and still sell it as the 9500 series. So, a CPLD is in some sense a mini-FPGA, although the roots date back to the PLA/PLD heritage. This means that it is composed of a small number of VERY wide gates, such as 18-input. For decoding wide addresses, these can actually be an advantage, as in circuits that detect addresses on a bus. An FPGA is much "finer grained" and so a wide decoder would need to be built out of many LUT elements. > Does Altera store sell to individual or only business? It is probably easiest to buy these parts from distributors like Digi-Key. Jon

On Tuesday, June 5, 2012 8:00:54 AM UTC+12, LM wrote: > There are too many FPGAa and CPLDs. I can see that LCMXO2280-B-EVN has 8 40-pin connectors, which is important to me. But what else is there and what I am missing. From the Lattice stable, you could also look at the newer LCMXO2-1200ZE-B-EVN ? > By the way, what is CPLD, a fancy name for a FPGA? CPLD is Complex Programmable Logic Device, spawned from SPLD (Simple Programmable Logic Device), which were the original PAL/PLD/GAL/FPLS (etc). CPLD's used to keep the wide-and aspect of SPLDs but recently more FPGA-like fabric & tool flows has moved into the larger CPLDs..

tiistai, 5. kes=E4kuuta 2012 6.39.59 UTC+3 (tuntematon) kirjoitti: > On Tuesday, June 5, 2012 8:00:54 AM UTC+12, LM wrote: > > There are too many FPGAa and CPLDs. I can see that LCMXO2280-B-EVN has = 8 40-pin connectors, which is important to me. But what else is there and w= hat I am missing.=20 >=20 > From the Lattice stable, you could also look at the newer LCMXO2-1200ZE-B= -EVN ? > =20 > > By the way, what is CPLD, a fancy name for a FPGA?=20 >=20 > CPLD is Complex Programmable Logic Device, spawned from SPLD (Simple Pro= grammable Logic Device), which were the original PAL/PLD/GAL/FPLS (etc). >=20 > CPLD's used to keep the wide-and aspect of SPLDs but recently more FPGA-= like fabric & tool flows has moved into the larger CPLDs.. Good to know.=20 Here you have some more questions and comments. These chips and kits are relatively cheap. And my sw is simple too. I am go= ing to put a led driver in every output the ic has. So it looks like I am n= ot going loose something with either chip. Or with the 1200ZE. I only hope = they have enough logic to drive every pin individually. I tried Digi-key, but they would have charged quite a lot extra. But there = is some kind a local (.fi) Digi-key, I will check that. I believe you when you say that LCMXO2-1200ZE-B-EVN is newer, but LCMXO2280= -B-EVN kit has more outputs on this kit. Are there some other important dif= ferences I should know of. Leif

LM wrote: > tiistai, 5. kesäkuuta 2012 6.39.59 UTC+3 (tuntematon) kirjoitti: >> On Tuesday, June 5, 2012 8:00:54 AM UTC+12, LM wrote: >>> There are too many FPGAa and CPLDs. I can see that LCMXO2280-B-EVN has 8 40-pin connectors, which is important to me. But what else is there and what I am missing. >> From the Lattice stable, you could also look at the newer LCMXO2-1200ZE-B-EVN ? >> >>> By the way, what is CPLD, a fancy name for a FPGA? >> CPLD is Complex Programmable Logic Device, spawned from SPLD (Simple Programmable Logic Device), which were the original PAL/PLD/GAL/FPLS (etc). >> >> CPLD's used to keep the wide-and aspect of SPLDs but recently more FPGA-like fabric & tool flows has moved into the larger CPLDs.. > > Good to know. > > Here you have some more questions and comments. > > These chips and kits are relatively cheap. And my sw is simple too. I am going to put a led driver in every output the ic has. So it looks like I am not going loose something with either chip. Or with the 1200ZE. I only hope they have enough logic to drive every pin individually. > > I tried Digi-key, but they would have charged quite a lot extra. But there is some kind a local (.fi) Digi-key, I will check that. > > I believe you when you say that LCMXO2-1200ZE-B-EVN is newer, but LCMXO2280-B-EVN kit has more outputs on this kit. Are there some other important differences I should know of. > > Leif It's probably worth looking through the features at the top of each family data sheet. MachXO2 has some new features that make high-speed I/O easier, for example. Neither of these families is a traditional "CPLD." They are both small FPGA's by architecture. Another thing to note is that Lattice has very aggressive pricing on kits when they first come out - often as low as $29.99, so sometimes you can get a lot more bang for the buck if you keep an eye out for new releases and introductory offers. -- Gabor

tiistai, 5. kes=E4kuuta 2012 16.17.03 UTC+3 Gabor kirjoitti: > LM wrote: > > tiistai, 5. kes=EF=BF=BDkuuta 2012 6.39.59 UTC+3 (tuntematon) kirjoitti= : > >> On Tuesday, June 5, 2012 8:00:54 AM UTC+12, LM wrote: > >>> There are too many FPGAa and CPLDs. I can see that LCMXO2280-B-EVN ha= s 8 40-pin connectors, which is important to me. But what else is there and= what I am missing.=20 > >> From the Lattice stable, you could also look at the newer LCMXO2-1200Z= E-B-EVN ? > >> =20 > >>> By the way, what is CPLD, a fancy name for a FPGA?=20 > >> CPLD is Complex Programmable Logic Device, spawned from SPLD (Simple = Programmable Logic Device), which were the original PAL/PLD/GAL/FPLS (etc). > >> > >> CPLD's used to keep the wide-and aspect of SPLDs but recently more FP= GA-like fabric & tool flows has moved into the larger CPLDs.. > >=20 > > Good to know.=20 > >=20 > > Here you have some more questions and comments. > >=20 > > These chips and kits are relatively cheap. And my sw is simple too. I a= m going to put a led driver in every output the ic has. So it looks like I = am not going loose something with either chip. Or with the 1200ZE. I only h= ope they have enough logic to drive every pin individually. > >=20 > > I tried Digi-key, but they would have charged quite a lot extra. But th= ere is some kind a local (.fi) Digi-key, I will check that. > >=20 > > I believe you when you say that LCMXO2-1200ZE-B-EVN is newer, but LCMXO= 2280-B-EVN kit has more outputs on this kit. Are there some other important= differences I should know of. > >=20 > > Leif >=20 > It's probably worth looking through the features at the top of each > family data sheet. MachXO2 has some new features that make high-speed > I/O easier, for example. Neither of these families is a traditional > "CPLD." They are both small FPGA's by architecture. >=20 > Another thing to note is that Lattice has very aggressive pricing > on kits when they first come out - often as low as $29.99, so > sometimes you can get a lot more bang for the buck if you keep > an eye out for new releases and introductory offers. >=20 > -- Gabor OK That is good to know. Lets see how long I can wait Leif

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

Custom Search