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
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:p2t%b.28542$ws.3212062@news02.tsnz.net... > When you use the slew model, you can appreciate any pulse transformer ( > with its slow slew rates ) will likely have a big effect on jitter. > > Why is the transformer there, and do you work on both sides of it > - ie is the RX side your design ? Some care will be needed there, > to both keep Tsu/Th ok, and to minimise clock path degrade. > > >I've googled for HC1G79 but to no avail so far. > > http://www.philipslogic.com/products/picogate/flipflops/ > > -jg Thank you for the link Jim. I do see what you mean about the slew rate of the transformer and its effect on jitter. We are using a pulse transformer in the transmit side only. This is to achieve galvanic isolation and is recommend for SPDIF output circuits in the datasheets and documents we have, e.g.: http://www.cirrus.com/en/pubs/proDatasheet/CS8405A-f.pdf (800KB) page 34 - consumer output circuit http://www.cirrus.com/en/pubs/appNote/AN134-4.pdf (70KB) http://www.epanorama.net/documents/audio/spdif.html (a collection of SPDIF circuits from various sources) The transformer is a Pulse Engineering PE-65812 and is recommended by Cirrus Logic for SPDIF transmission. Hopefully this means jitter from the transformer is kept as low as possible. Since the SPDIF outputs of all consumer devices are meant to have a transformer in them (AFAIK), then they must all have this problem? On the other hand, I have also seen that many DIY audio geeks prefer a direct connection with no transformer, I guess for exactly the reasons you have suggested. However, since our product is for sale to the general public, I like the idea of galvanic isolation to cover us in case of incorrect connections by users and also failure within the unit itself that could possibly damage their expensive equipment. JimArticle: 66801
Austin, Our data contradicts the performance claims you are making, but this is not the right forum to argue back and forth about it. Let's let the engineers and the market decide which claims to be leary of. Best Regards, Mike austin <austin@xilinx.com> wrote in message news:<c1jt6i$72u1@cliff.xsj.xilinx.com>... > Michael, > > Thank you very much. I have read all of the publicly available > materials, and am still puzzled by the claims. > > Any claims of remarkable efficiency, you may understand, I am quite > leary of. For example, if the claim of a St2 50% speed improvement is > really true, then our demonstrated 40% speed improvement on average in > the i6.2 release makes St2 only 10% faster than our 2 year old V2 > Pro.....lowest speed grade. So leaving marketing to those who enjoy it, > I will forego any claims of performance, and just ask about architecture. > > I was unclear on just how a ALM is any different from drawing the box > differently around the components. I am still puzzled, but the block > diagrams appears to have 3, 4, 5 and 6 LUTS with muxes, and maybe if it > was actually designed this way then that is simply what it is. A true 6 > LUT has 64 memory cells and the associated logic, and two of these seems > a bit excessive and would not require any other logic or muxes at all. > Combining existing 4 LUTs to deliver some of the possible terms of a 6 > LUT is a completely different matter. > > Regardless, it is enjoyable to hear about any radical or innovative new > architecture, as there are so many that now dot the landscape as dead > skeletons of past FPGAs. > > AustinArticle: 66803
> I do see what you mean about the slew rate of the transformer and its effect > on jitter. We are using a pulse transformer in the transmit side only. This > is to achieve galvanic isolation and is recommend for SPDIF output circuits > in the datasheets and documents we have, e.g.: > http://www.cirrus.com/en/pubs/proDatasheet/CS8405A-f.pdf (800KB) page 34 - > consumer output circuit > http://www.cirrus.com/en/pubs/appNote/AN134-4.pdf (70KB) > http://www.epanorama.net/documents/audio/spdif.html (a collection of SPDIF > circuits from various sources) > > The transformer is a Pulse Engineering PE-65812 and is recommended by Cirrus > Logic for SPDIF transmission. Hopefully this means jitter from the > transformer is kept as low as possible. Since the SPDIF outputs of all > consumer devices are meant to have a transformer in them (AFAIK), then they > must all have this problem? > > On the other hand, I have also seen that many DIY audio geeks prefer a > direct connection with no transformer, I guess for exactly the reasons you > have suggested. However, since our product is for sale to the general > public, I like the idea of galvanic isolation to cover us in case of > incorrect connections by users and also failure within the unit itself that > could possibly damage their expensive equipment. This mentions Biphase modulation, and that requires clock recovery on the RX side. Thus you should choose low jitter Xtal source, (and a high accuracy one could also help, if a digital PLL is used in the RX ) but the jitter introduced by the cpld will likely be insignifcant. I see the cirrus device specs MAX of 1ns jitter, which may or may not include the transformer :) The RX clock recovery will lock into the centres of the data bi-phase bits, so final clock jitter will be determined mainly by their lock scheme. Of course, poor jitter, or frequency skew, on the data edges makes the clock lock job harder... -jgArticle: 66804
Kevin Brace wrote: > Hi Chris, > > It's off topic, and it is probably none of my business to suggest (I > almost used the word "criticize," but I instead used "suggest," so that > you won't feel offended.), but why instantiate a vendor specific library > primitive and Verilog gate primitives when you don't have to? > These are the two examples I am talking about. > ______________________________________________________________________ > FDC FF1 ( .Q(Out), .C(Trig_in), .CLR(CompMatchOut), .D(h) ); > > ______________________________________________________________________ > > > Why instantiate an FDC? > You should be able to replace it with the following code (Assuming that > what I am doing is correct), and the synthesis tool should infer you an > FDC. > > ______________________________________________________________________ > reg Out; > > always @ (posedge Trig_in or posedge CompMatchOut) begin > > if (CompMatchOut == 1'b1) begin > Out <= 1'b0; > > end > else begin > Out <= h; > > end > end > ______________________________________________________________________ > Yes, of course. I appreciate your suggestions and if you want to constructively criticize my posts in the future, that is welcome too. I have noticed you are a very experienced poster here, so I will listen. The only reason I am doing these silly things is twofold: 1. I am just learning the language, and am on the chapters of "gate level modeling" and "structural" modeling in my Verilog text. So rather than do the boring exercises in the book, especially when I have a real design that needs implementing, I decided to get comfortable with structural modeling by implementing my first Verilog project in mainly this way. I also am trying to delve a little deeper into knowing how to work with WebPack. I had only done schematics in the past, with a single source module. This time I have multiple Verilog source modules. I have also just begun learning about the libraries. So it appears you are hinting that it is wiser to code generically rather than invoke vendor libraries? I suppose this might make sense in the broader sense, for portability, huh? Something I hadn't really thought about until you prodded me. So even if I were determined to model in the structural style, might you suggest that I instead build the generic FDC using the code you have shown, and which I can understand enough. Put it in a module called FDC, then instantiate that? > > ______________________________________________________________________ > module Compare8(Q, A, B); > output wire Q; > input wire [7:0] A; > input wire [7:0] B; > > wire X7, X6, X5, X4, X3, X2, X1, X0; > > xnor > XNOR7 (X7, A[7], B[7]), > XNOR6 (X6, A[6], B[6]), > XNOR5 (X5, A[5], B[5]), > XNOR4 (X4, A[4], B[4]), > XNOR3 (X3, A[3], B[3]), > XNOR2 (X2, A[2], B[2]), > XNOR1 (X1, A[1], B[1]), > XNOR0 (X0, A[0], B[0]); > > and (Q, X7, X6, X5, X4, X3, X2, X1, X0); > > endmodule > ______________________________________________________________________ > > Also, why instantiate Verilog gate primitives when you should be > able to do the same thing for less code? Well, it was kinda fun ;-) I am also learning digital logic design by gradual experience, having never taking a formal course in it. So I asked myself "how does one determine the equality of two binary words?" I proceeded to twiddle with bits and bytes and truth tables on paper, and came up with the above blob of gates. I proceeded to implement it structurally, again just to cement my comfortability with this inefficient coding style. Then I discovered on further perusing the Xilinx library that they had the same thing available to me already. In the interest of learning I also experimented with the following way in dataflow style: assign Q = & ( A ~^ B ); which seemed to work fine. I also wondered if it was possible to write the operation in the way you show here: > ______________________________________________________________________ > module Compare8(Q, A, B); > output Q; > input[7:0] A; > input[7:0] B; > > assign Q = (A[7:0] == B[7:0]); > > endmodule > ______________________________________________________________________ But actually, I wonder if you can do this: assign Q = (A == B); // ??? Ok, thanks for the reply. Good day! -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.govArticle: 66805
Michael, True. All I pointed out is that the ALM architecture is a clear improvement (for Altera) and (if) it also has speed benefits, then that is even better. A clear case of agreement. I also mentioned that I don't believe your claims, and even if I did, we now claim a 40% improvement. You don't believe my claim, so we are even again. Scarey if we agree too much.... So, here is the challenge: anyone who can actually do a design in both, and then let us know how well it behaves? Of course, no one is likely to believe just one design (as Peter notes), so the more who submit, the merrier (and the more believable it would be). I would only leave as a last note that this is a comparison of the Virtex II Pro (two years old 0.13u) with the St2 (90 nm which isn't even sampling yet). AustinArticle: 66806
Hi Philip! Philip Freidin <philip@fliptronics.com> wrote: > On Wed, 25 Feb 2004 13:06:30 -0000, "Jim" <jim@nospam.com> wrote: >> >>Is there a way of determining the maximum jitter of the output from the >>CPLD? It's for digital audio so this info would be very useful. >> >>Many thanks, >> >>Jim > > Jitter can be attenuated by using a PLL on the clock, but it has to be > a PLL designed specifically for jitter attenuation. Shouldnt it be possible to use a LC band pass filter (or even a crystal filter) to remove spectral components far from the clock frequency? This should improve at least the peak/rms ratio. I am not sure if my idea is not too stupid. PLL design has also some difficulties. > > If your goal was to have sub 200ps final jitter, I would suggest > researching a structure such as: > > Take the output of the CPLD and run it through a single FF outside the > CPLD, such as a NL17SZ74US . > For analogue filter a limiter amplifier or so is also necessary to convert the filtered signal back to the "digital domain". > Use extraordinary efforts for isolation from noise, such as sepparate > local low noise LDO regulator with local bypassing for its power supply > and appropriate issolation from ground noise of the rest of the system. > This is always a good idea, for analogue and digital circuits as well. In my experinence the influence of the power supply is often underestimated. Especially when there some lack of time.... > Take your clock and pass it through a jitter attenuation PLL, with > similar care with power supply and grounds. Use this (improved) clock > for this external retiming flip flop. > Best regards, Christoph > > Good luck, > > Philip > > > Philip Freidin > FliptronicsArticle: 66807
Hi, Folks, I am using a DPRAM with data bus width of 32 bits on both sides of the RAM. However, the input data at A side is 16 bits. So in order to send 32 bits of data to fill one address of the RAM, I need to use a mux and introduce a clock cycle of latency into the writing process at A side. The problems is that mux logic is not scan insertable and the extra clock cycle latency is not welcome either. So my question is: is there any nice and dirty tricks in VHDL that can avoid those problems without changing the RAM? Thanks in advance. IanArticle: 66808
google_guy wrote: > > Yes, and some of those are in a unmarked grave out behind your > facility, no? What was that company name... was it Plus Logic? How > about NeoCAD? What are the others... ? I don't like the nasty tone by that anonymous coward "google_guy" . But regarding the graves that Austin referred to, they are from: Intel, Motorola, Texas Instrument, AMD, Lucent, National Semi, and lots of lesser players. Let's stop the bickering and concentrate on the fascinating technical possibilities offered by the new crops of FPGAs. Leave the mudslinging to the marketing folks. They are better trained in it, and they can tell the wildest stories with a straight face, without blushing. Let us be engineers. :-) Peter AlfkeArticle: 66809
rickman <spamgoeshere4@yahoo.com> wrote in message news:<403E4817.2E1B127A@yahoo.com>... > jmdrake wrote: > > Mops can generate PowerPC code. As for embedded PowerPC I was surprised > > that I didn't see a SwiftX or VFX implementation on their websites > > although both supported ColdFire. > > I believe that is because both companies are reactive rather than > proactive. They port to a new platform when they are paid to do it. > They don't speculate on their own dime. > > -- > > Rick "rickman" Collins Right. I guess I'm surprised that there (apparantly) hasn't been a request for PowerPC. Although I suppose it makes sense. Perhaps ColdFire is a better fit for embedded systems price/performance wise then PowerPC? Anyway Forth Inc does have a PSC1000 port and Patriot Scientific does have a PSC1000 core for use in FPGAs. Regards, John M. DrakeArticle: 66810
I'm seeing a problem configuring a V2Pro-7 part when I add HSTL_II_DCI pads to my design. The bit stream downloads, but I don't get a 'done' signal. If I change the pads to be HSTL_II, the bitstream downloads OK. I'm also using some HSTL_I_DCI pads, but these don't seem to cause a problem. Anyone else seen and/or worked-around this problem? Thanks! John P.Article: 66811
The easiest trick would be to use the Xilinx BlockRAM, where that whole problem is solved for you. Sorry for the commercial, but you gave no restrictions in RAM size.... Peter Alfke ian wrote: > > hi, Folks, > I have a dual port RAM with the same width at both side, which is > 32bit. However, the data in at A side is only 16 bit wide. So in order > to pass the data in and fill the RAM entry, i need to use some wrapper > logic (mux?) to pass data in to fill the upper and lower 16 bits in > one address of the DRAM in two consequtive clock cycles. Therefore as > issue of testablity arises, since the mux logic is not insertable in > terms of scan flops. also I have to introduce a clock cycle latency > into the A side to fill up the 32 bit entry. Are there any nice > tricks to avoid both of the problems? (of course without changing the > DPRAM.) > Thanks in advance > > IanArticle: 66812
On Thu, 26 Feb 2004 14:25:11 -0500, rickman <spamgoeshere4@yahoo.com> wrote: >> Mops can generate PowerPC code. As for embedded PowerPC I was surprised >> that I didn't see a SwiftX or VFX implementation on their websites >> although both supported ColdFire. > >I believe that is because both companies are reactive rather than >proactive. They port to a new platform when they are paid to do it. Sorry Rick, but it isn't always true. We certainly port when paid to do so, but we also do it when we like the CPU. The ARM and Coldfire VFX ports were done on our own dime. There are several CPUs we've done cross compilers for that I wish we hadn't wasted time on. We just don't have the budget to do every CPU on the market. In retrospect I consider the decision to support ARM rather than PPC a good one. >They don't speculate on their own dime. Oh yes we do. The VFX code generator was a speculative venture. Yes, we do it with commercial (and sometimes cautious) interest, but MPE at least has a long track record in speculative R&D ventures, including what eventually became the basis of the Europay OTA system. Stephen -- Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeltd.demon.co.uk - free VFX Forth downloadsArticle: 66813
Peter writes >But regarding the graves that Austin referred to, they are from: >.............. AMD, Lucent,.......... Quote from Mark Twain follows: "Rumors of my untimely demise have been greatly exaggerated." might not be exact, but you get what I mean. This is a terrific newsgroup. I know I have learned a fair amount about the topic while perusing the posts. But let's remember, AMD's PLD business isn't dead, nor is Lucent's - although they BOTH now say LATTICE on the package. ;-) Michael Thomas LSC SFAE New York/New Jersey 631-874-4968 fax 631-874-4977 michael.thomas@latticesemi.com for the latest info on Lattice products - http://www.latticesemi.com LATTICE - BRINGING THE BEST TOGETHERArticle: 66814
What device family? If you can live with last generation, then check ebay. If
it is for the latest and greatest, check the comp.arch.fpga FAQ for a pretty up
to date list of boards. (Philip works his butt off keeping that site going, and
doesn't get nearly enough credit) --good job Philip.
Invisible One wrote:
> I am looking for a good, reasonably priced FPGA evaluation board for general
> development. Any good suggestions?
>
> My preference is to Xilinx.
>
> J.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 66815Austin Lesea <austin@xilinx.com> wrote in message news:<c1ligf$7oc2@cliff.xsj.xilinx.com>... > google_guy wrote: > > austin <austin@xilinx.com> wrote in message news:<c1jt6i$72u1@cliff.xsj.xilinx.com>... > > > >>Michael, > >> > >>Thank you very much. I have read all of the publicly available > >>materials, and am still puzzled by the claims. > >> > >>Any claims of remarkable efficiency, you may understand, I am quite > >>leary of. > > > > > > I can understand why. The way that Xilinx twists facts in their data > > sheets would certainly lead them to expect that of everyone. Just how > > many LCs *do* your parts have??? > Easy, just look at how many LUTs there are in the data sheet. You can > inflate the naw numbers any way you like, as opposed to using our "rules." How about Xilinx actually publishes the *real* numbers? If you inflate the numbers, of course you would expect your competition to inflate their numbers. > >>For example, if the claim of a St2 50% speed improvement is > >>really true, then our demonstrated 40% speed improvement on average in > >>the i6.2 release makes St2 only 10% faster than our 2 year old V2 > >>Pro.....lowest speed grade. So leaving marketing to those who enjoy it, > >>I will forego any claims of performance, and just ask about architecture. > > > > > > What kind of gobbledygook is that? Correct me if I am wrong, but your > > V2 is the newest and fastest parts you have, right? Certanly you > > can't tout the Spartan 3 since not many people have even seen them and > > they are much slower than most people would have expected given a 90 > > nm process. > V2Pro is the latest production avaliable offering in 130 nm. So what would you have Altera compare their products to, your V3 chips that you won't have out next year? > > And exactly how do you get a 40% speed advantage over anything with > > your software? > By being more clever than we were one year ago. > Do you have benchmarks to back that up? > Yes. Contyact your FAE and they will be delighted to show you the > benchmarks of over 200 large actual customer designs that we have in our > tool test suite. So your chips are not any faster, you have just figured out how to get the speed out of your chips. If you want to compare software do that, but we are talking about the chips, aren't we? > >>I was unclear on just how a ALM is any different from drawing the box > >>differently around the components. I am still puzzled, but the block > >>diagrams appears to have 3, 4, 5 and 6 LUTS with muxes, and maybe if it > >>was actually designed this way then that is simply what it is. A true 6 > >>LUT has 64 memory cells and the associated logic, and two of these seems > >>a bit excessive and would not require any other logic or muxes at all. > >> Combining existing 4 LUTs to deliver some of the possible terms of a 6 > >>LUT is a completely different matter. > > > > > > I don't follow this. Are you saying their approach is good or bad? > Neither. It just looked at first glance that they had some muxes (just > like we do). That they have a more direct LUT/MUX/LUT path which is > faster may be true, and that would be good. So you don't understand what they are doing, but you had to open your mouth anyway. :) > > If you are saying it is good, then you are agreeing with them. > Hey, what is wrong with that? Yes, it is good. > If you > > are saying it is bad, aren't you also saying it is just like yours? I > > guess the patents will tell all. > > > > > > > >>Regardless, it is enjoyable to hear about any radical or innovative new > >>architecture, as there are so many that now dot the landscape as dead > >>skeletons of past FPGAs. > > > > > > Yes, and some of those are in a unmarked grave out behind your > > facility, no? > Yes. > What was that company name... was it Plus Logic? How > > about NeoCAD? What are the others... ? > I will let you tell us. Hey, it's your graveyard.Article: 66816
I could make either family come out miles ahead of the other for a particular
design. The fact is, if you design to the part you'll get the best performance
from that part, but it will likely not port well to a dissimilar part. In my
cursory look at the new Altera architecture, I see structure there to support
wider functions, which is great for the naive user. It makes the synthesis job
a little harder since there are now even more ways to skin the cat. For heavily
pipelined designs, it generally isn't going to matter a whole lot if you've
already done the designs with 4-LUTs in mind. I'm not sure yet what it does to
the arithmetic functions. Altera had previously been a little weaker than
xilinx for arithmetic just because of the structure of the LEs and LAB when used
in arithmetic mode, and in the families prior to stratix there were row routing
congestion problems if you put a lot of arithmetic in one row. For typical
designs, either will do fine. Select on the feel-good parameters instead:
things like best comfort with tools, best price, best relationship with vendor,
best give-aways at trade shows. If your application is pushing the
envelope,however, you'll want to carefully evaluate each architecture to
determine which is going to best fit your design, and then design to that
architecture.
Kenneth Land wrote:
> Hi Peter,
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 66818
If someone will pay for my time doing it (and be willing to fit in my
schedule), I'd be happy to do an app or two targeted to each of the
families, pulling out all the stops for each one to see which does better
for that app after all the tricks in my bag are applied. I'll guarantee the
internals of the two functionally equivalent designs would be rather
different. Of course that would only be a valid comparison for the pieces
of that application.
Austin Lesea wrote:
> Michael,
>
> True. All I pointed out is that the ALM architecture is a clear
> improvement (for Altera) and (if) it also has speed benefits, then that
> is even better.
>
> A clear case of agreement.
>
> I also mentioned that I don't believe your claims, and even if I did, we
> now claim a 40% improvement.
>
> You don't believe my claim, so we are even again. Scarey if we agree
> too much....
>
> So, here is the challenge: anyone who can actually do a design in both,
> and then let us know how well it behaves? Of course, no one is likely
> to believe just one design (as Peter notes), so the more who submit, the
> merrier (and the more believable it would be).
>
> I would only leave as a last note that this is a comparison of the
> Virtex II Pro (two years old 0.13u) with the St2 (90 nm which isn't even
> sampling yet).
>
> Austin
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 66819> How much skew do you tolerate with that design? > > My idea was to have two FFs that was clocked by the falling and rising > edge of the clk2x. > > > clk2x------------ > | ______ | ______ > |-o|> | |--|> | > | | | | > clk-----|D Q|-----|D Q|---- clk_ce > | | | | > ------ ------ > > If duty cycles are 50/50 this should tolerate quite som skew, right? > > Takes two slices. > > Hmm, if you use clk90 and ckl2x, you could sample on rising edge of > clk2x, and then you only need one FF. > > Objections anyone? > > Homann > -- > Magnus Homann, M.Sc. CS & E > d0asta@dtek.chalmers.se The diagram above might work, but it's a little less tolerant. If you are resyncing the 'T' flop in the 2x domain, you are more certain that you will meet setup and hold times because the output of the flop will change after the clock edge. With the diagram you have, the flops must tolerate zero hold times and you hope that differences in routing are not going to cause hold setup time violations. The clk90 method might be better. -KevinArticle: 66820
Hi Ray, As I said, (tried to say?) I'm sure many of the smart guys here like you could rig the results at will - big deal. But what if you didn't go to the trouble to make one or the other come out miles ahead? Would it not be interesting to see the results? I think its clear people don't really care because they've made up their minds which they prefer. Choosing A or X probably pales in comparison to pushing more of your design onto *any* state of the art FPGA. That's where I am - basking in the amazement that my hardware is configurable, my pins are assignable and I can add as much parallel logic as required to meet performance. Frankly, it would take a lot to steer me away from Altera and Nios because of the ease of use and the effort the company went to to get us going. Ken "Ray Andraka" <ray@andraka.com> wrote in message news:403E8F68.9BDD0118@andraka.com... > I could make either family come out miles ahead of the other for a particular > design. The fact is, if you design to the part you'll get the best performance > from that part, but it will likely not port well to a dissimilar part. In my > cursory look at the new Altera architecture, I see structure there to support > wider functions, which is great for the naive user. It makes the synthesis job > a little harder since there are now even more ways to skin the cat. For heavily > pipelined designs, it generally isn't going to matter a whole lot if you've > already done the designs with 4-LUTs in mind. I'm not sure yet what it does to > the arithmetic functions. Altera had previously been a little weaker than > xilinx for arithmetic just because of the structure of the LEs and LAB when used > in arithmetic mode, and in the families prior to stratix there were row routing > congestion problems if you put a lot of arithmetic in one row. For typical > designs, either will do fine. Select on the feel-good parameters instead: > things like best comfort with tools, best price, best relationship with vendor, > best give-aways at trade shows. If your application is pushing the > envelope,however, you'll want to carefully evaluate each architecture to > determine which is going to best fit your design, and then design to that > architecture. > > Kenneth Land wrote: > > > Hi Peter, > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 66821
On Thu, 26 Feb 2004 11:14:58 -0500, "Invisible One" <Invisible_1@sympatico.ca> wrote:
>I am looking for a good, reasonably priced FPGA evaluation board for general
>development. Any good suggestions?
>
>My preference is to Xilinx.
>
>J.
http://www.fpga-faq.com/FPGA_Boards.shtml
===================
Philip Freidin
philip@fliptronics.com
Host for WWW.FPGA-FAQ.COM
Article: 66822>I know you could trust my designs, because I don't know enough to tweak them >for X or A. I'll bet there are many others who don't tweak designs to that >level either. (probably for better reasons :) That cuts both ways. I'm willing to tweak my designs to take advantage of the hardware. That can make a big difference. Perhaps what we want is a nice clean reference design, and then see what happens if people try to tweak it to look better on a particular device. (That might make a good open cores project.) But that puts us back to discussing what makes a good reference design. See Peter's comments about PREP. But maybe the FPGA world has matured enough by now that we could build complete (interesting) designs rather than replicating simple counters. Would LUTs/MIPS for an x bit CPU be an interesting measure? Both vendors have mature CPU technology. I like Ray's offer. Maybe one of the trade rags will take him up on it. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 66823
>is it true that one-hot encoding for FSM's is used in FPGA's? If so, >why? is it due to the large amount of registers available i.e: enough >registers to store all states? what kind of encoding is using in ASIC's? It sure simplifies decoding states. I think the real answer is that overall, it fits well with the available hardware resources. At least for some/many problems. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 66824
Hi, I am looking for a DesignCon 2002 Paper: "Reuse of Algorithmic Specifications for Synthesis of FPGA and ASIC Designs" Thanks for your help in advance. Prabhat
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