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
Ray's post was excellent. Let me add my 2 cents...
1. I've used Xilinx 4K, Lucent Orca2C, and Altera 6K/10K extensively.
To a **First approximation**, the Xilinx and Orca technologies are
very similar. The Altera devices are very different.
2. Xilinx and Orca devices are large sandboxes. Reconfiguring output
pins (or locking them down) is pretty easy to do, within limits, and
that eases the worries about post-board-layout design additions.
3. Altera FPGAs are constructed as an array of smaller sandboxes.
If your design doesn't partition well amongst the subsections, you
run the risk of
a) not enough interconnect to route the design or
b) a quantum decrease in operating frequency, due to interconnect delays.
I agree with Ray's assessment, datapath intensive design (esp DSPs) will
tend to be happier with Xilinx and Orca devices. Random logic and smaller
datapaths will be happy in any of the devices. The inefficiencies in any of
these products can, in general (but not always), be overcome with bigger
or faster grade parts.
4. It's the tools, stupid! You can become proficient in Max+II (Altera)
**very** quickly. That is a very compelling attribute! If you are
designing a part that someone else will have to maintain (i.e. a client),
this is a very powerful weapon in the consultant's arsenal. Also, if
you don't use the tool often enough to become proficient and stay
proficient, consider a less demanding toolset, like Max+2.
5. Compile time. You *can* configure a Xilinx or Orca design to
eventually compile quickly, but this takes time, and major design
changes generally mean several hours of compile time. (do 28
compiles and keep the best 4 :=) ). On the other hand, Max+2
compiles (generally) in 5-10 minutes. Instant gratification,
fewer coffee breaks (and bathroom runs).
Summary: For video processing, I stay with Orca or Xilinx.
For interface logic design, and designs where I know the customer
will want to maintain it, I tend to use Altera, where I know I can
get useable results more quickly.
****************************************************************
Bob Elkind mailto:eteam@aracnet.com
7118 SW Lee Road part-time fax number:503.357.9001
Gaston, OR 97119 cell:503.709.1985 home:503.359.4903
****** Video processing, R&D, ASIC, FPGA design consulting *****
Article: 13701
I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to implemnt
into a XILINX 4000 series FPGA. I am using
VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade.
Is there anyone out there who can point me in the right direction for
this?
Thanks
--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Richard Schwarz, President
Associated Professional Systems Inc. (APS)
email: richard@associatedpro.com
web site: http://www.associatedpro.com
Phone: 410-569-5897
Fax: 410-661-2760
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/
Article: 13702Hi everybody! I have implemented an encryption algorithm in hardware using FPGAs.I am faced with a problem. After optimizing my design using the Synopsys FPGA compiler, you are suppose to get the report_fpga and report_timing reports by typing in those commands in the command window. I am getting the right report for the number of CLBs used, but for the timing report, it only gives me the delay associated with the sequential part of my design. The design actually is made up of both sequential as well as the combinational logic. Moreover, the design is a hierarchical one. I would really appreciate, if someone could help me in this respect!!!! Thanx, Mohsin Riaz Computers & Communications Security Lab, Faculty Of Engineering, Memorial University Of Newfoundland, Canada.Article: 13703
Bob Sefton wrote: > Is RESET a pad or an internal net? In Xilinx it has to be an > internal net that has come in through a normal input buffer. > > You also have to use RESET to asynchronously clear or set ALL > registers in the design or else GSR can't be used and won't be > hooked up at all. Again in Xilinx, it's got to be all registers or > none. I assume Orca is the same. > > Bob S. > > jerry english wrote: > > > > My tool set: FPGA Express 3.0, verilog, Orca Foundry 9.3.1. Target > > device 3T80. > > > > I do the component instantiation > > > > GSR gsr0 (.GSR(RESET)); > > > > Problem....GSR is not mapped. FPGA Express message indicates it is in > > > > the edif netlist and an inspection of the netlist shows the GSR > > component. When > > the Orca mapper runs the resource report shows 0 of 1 GSR used. What > > gives? I run the tutorial (they are always so simple) it uses the GSR > > just fine. > > > > Anybody else have this kind of problem and if so what was the solution? > > > > Thanks > > Jerry English Yes, RESET is an internal net. I use IRESET to an input buffer whose output is RESET. I didn't think one had to explicitly use GSR in the processes or always block for the function to be implemented, that the component instantiation of GSR was sufficient. regards JerryArticle: 13704
Richard Schwarz wrote: > I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to > implemnt > > into a XILINX 4000 series FPGA. I am using > VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade. > The design approach will be heavily influendced by the required speed. If both clocks are fully asynchronous and run at 80 MHz, it may be beyond the reach of VHDL, but the silicon can still do it. At low clock rates, the design can be quite simple. Peter Alfke, Xilinx ApplicationsArticle: 13705
We are looking to buy some of these Motorola FPGA's (160PQFP) . If you have surplus stock please contact Michal @ 212-2749191Article: 13706
> > Yes, RESET is an internal net. I use IRESET to an input buffer whose > output is RESET. I didn't think one had to explicitly use GSR in the > processes > or always block for the function to be implemented, that the component > instantiation > of GSR was sufficient. > You're right, with instantiation all you should have to do is hook it up.Article: 13707
Steve, I was thinking the same thing, I don't see why it wouldn't be practical.. Jamie Morken Steve wrote: > Would it be practical to implement an MP3 decoder in an FPGA? > > SteveArticle: 13708
> >I have two questions: > >1. I own Foundation 1.4, is there a way to upgrade it to 1.5 online? Nope. Or at least not that I know of. >2. Anyone had any experience using Aldec's Active-VHDL as a design-entry >tool and call (from within the software) to Metamor/M1 to >synthesize/implement his design? Yup. There are some example designs shipped with Active-V that document this process. It does work. Have FUN!!! Nick P.S. I am back and I work for Avnet now. > >Thanks > >Article: 13709
> "Joel Kolstad" <JKolstad@Electroglas.Com> wrote: >> Well, it's probably me... but damn it... I'm running Foundation 1.5 here, >> and getting the schematic capture portion of the package to talk to the >> simulator is nearly impossible. I'll tell it to simulate a macro, it'll >> open up the simulator, and then I'll start adding probe points. The >> simulator COMPLETELY IGNORES the probe points I'm clicking on, when it >> should be adding them to its own list. I'll click over on the simulator >and >> add some signals, and schematic captures completely ignores what's been >> added! Better still, sometimes schematic capture won't even let me add any >> probe points at all, just completely ignoring mouse clicks! >> >> You go ahead and step time in the simulator, and the signals listed do >> reasonable things, but schematic just sits there with its probe points >> displaying nothing at all. >> >> !@$!@#%^^#$ >> >> OK, this doesn't happen 100% of the time. On VERY RARE occasion it >actually >> works the way it should. I can't believe this happens to all you other >> people on a daily basis, or there'd be an angry mob outside of Xilinx HQ >> threatening to burn the place down. So what am I doing wrong? The concept >> seems really simple -- add a probe in schematic, and the simulator picks it >> up, add a signal in simulator, and schematic should pick it up... right? >> >> ---Joel Kolstad >> Wow. Never seen it. Use Foundation all the time. Cross probe alot, works fine. Of course it only works in functional mode. Are you doing timing? If so see below. One other shot in the dark question. Is your schematic part of the project? If not this could cause problems.> >Oh God! I am sitting here on a dreary Sunday afternoon, desparately looking >for information describing a fix for EXACTLY THIS PROBLEM! However, I believe >that I can add a little twist to the puzzle. In my case, however, the >simulator works in the functional mode and does NOT WORK in the timing mode. >What is more remarkable is the fact that the simulator does not even see the >instance(s) that I am trying to probe in the timing mode. What is MOST >remarkable is the fact that no schematic implementation, no vhdl macro >implementation, no nothing is either visible or simulatable (in the timing >mode) for this section of the design! Joel? did you ever get an answer? > Slight problem. Have you looked at the signals availible in the simulator after a place and route? If you do you will find that many of the signals in your schematic are no longer present. Why? Because during the mapping phase of place and route your logic is re-aranged to fit inside of the real world CLBs. During this process many signals disappear due to optimization. I know in a perfect world it would be possible to probe all signals that are part of your schematic in the timing simulation. But it is very hard to find a signal in a back annotated file that is no longer there. I only use the cross probing feature for functional simulation. For timing (when I do timing, there are many threads about the merits of timing simulation. I don't want to re-start them) I work only in the simulator and do not even bother with the cross probe feature.Article: 13710
> >Somone know where i can find this cable. > > In a Foundation BoxArticle: 13711
In article <367B07C6.FC35BCA4@xilinx.com>, Peter Alfke <peter@xilinx.com> writes >Richard Schwarz wrote: > >> I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to >> implemnt >> >> into a XILINX 4000 series FPGA. I am using >> VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade. >> > >The design approach will be heavily influendced by the required speed. >If both clocks are fully asynchronous and run at 80 MHz, it may be >beyond the reach of VHDL, >but the silicon can still do it. >At low clock rates, the design can be quite simple. > >Peter Alfke, Xilinx Applications > Why is this beyond the reach of VHDL ? And if it is, isn't a pity that Xilinx are going to abandon schematic entry ? Or do you mean the fifo should be designed in EPIC ? Please explain. -- Edward Moore Snell & Willcox LtdArticle: 13712
Hello, I am using a Xilinx Spartan XCS30 device and trying to implement an internal Tri-state bus (which the device supports, but ofcouse!) using VHDL. I tried to implement two bidirectional registers which share the same Data-Bus (without a multiplexer, just an internal TBUF) and seem to have problems with that, it seems the data won't flow into the device and out when I am using components which include inout ports, even when I instanciated TBUFs inside them and applied inhibit_buf attributes on the data-bus top-level. Ofcouse there are also IBUFs+BUFTs on the incoming data-bus and OBUFTs on the way out... Has anyone been more successful than I am at implementing internal 3-state bus in a xilinx device using VHDL? I would be very happy to see some fragments of code as this will help the most. I would be most thankful if you could EMail me as I do not read these newsgroup on a regular basis. Thank you very much in advance. -- Yours, -- Ido Kleinman. kleinn@REMOVETHIS.mail.biu.ac.il ** Please delete the "REMOVETHIS." substring to EMail me.Article: 13713
What kind of trouble? Which device? I've never had any trouble with any of Atmel's programmable logic; PALs or FPGAs. sam wrote: > Does anyone have trouble when use Atmel's PLD ? > I will never use Atmel's PLD . It's too bad . -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13714
Edward Moore wrote: > In article <367B07C6.FC35BCA4@xilinx.com>, Peter Alfke > <peter@xilinx.com> writes > >Richard Schwarz wrote: > > > >> I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to > >> implemnt > >> > >> into a XILINX 4000 series FPGA. I am using > >> VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade. > >> > > > >The design approach will be heavily influendced by the required speed. > >If both clocks are fully asynchronous and run at 80 MHz, it may be > >beyond the reach of VHDL, > >but the silicon can still do it. > >At low clock rates, the design can be quite simple. > > > >Peter Alfke, Xilinx Applications > > It is very difficult to get this kind of performance in a synthesized design (especially with the async clocks). In cases like this it is much faster and easier to just to do it in schematic the way you know it needs to be implemented and be done with it. > > > Why is this beyond the reach of VHDL ? > > And if it is, isn't a pity that Xilinx are going to abandon schematic entry ? > Touche! -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13715
Rickman wrote: > > Tim Forcer wrote: > > Broadening the issue a bit, most of my design work is on relatively > > small-scale designs. In these applications I find it extremely > > frustrating that, except for Phillips XPLA, there's been nothing really > > new in not-many-pins devices for a very long time. What I'd love to see > > is a 16 pin IC, with at least two pins carrying clocking signals, and > > ALL pins having versatile I/O macrocells. Sort of 14V14. Or maybe > > 28V14 if every macrocell included a buried register. A 20-pin version > > would be 18V18/36V18. But all developments these days are in Mega this > > that and the other. Certainly useful in a very wide range of > > applications, but is the small-footprint IC really a dead market for new > > programmable logic devices? > > > > -- > > Tim Forcer tmf@ecs.soton.ac.uk > > Tim, I remembered using a 22V10 type device with buried registers. I > found it at http://www.atmel.com The ATV750B has a 22V10 structure along > with an additional 10 buried registers. Comes in a 7.5 nS comm, 10 nS > indust speed grade and 24 pin SOIC packages. I haven't used it in years > (like maybe 10?) but they still seem to make it. It is not ISP, but > rather UV eraseable. The FLASH ATF750 is due for sampling Q199. This is the highest density 'small package' device, with multiple clocks, separate OE, Toggle FlipFlops, and 10 buried registers ( call it a 22V20 if you like ). Tim is correct, I believe there is a need for smaller pincount devices, the 150 mil SO16/DIP16 would seem a logical part, and resource to replace a large chunk of all TTL grade MSI. Also the 20 / 24 pin device with 22i/o lines is a candidate. With care, a single die could do all jobs, and I am sure the company offering this family, would get a lot of column inches. By providing libraries for all the TTL devices it can replace, design ramp-up would be rapid. SPLD have got price competitive with many application-specific parts, and even FAST TTL - they just need better resource mapping to sweep the field. - Jim Granville.Article: 13716
responses re-arranged for clarity: >> >Richard Schwarz wrote: >> > >> >> I am looking for a 32 by 1 Async Fifo with hf, ff, ef flags. to >> >> implemnt >> >> >> >> into a XILINX 4000 series FPGA. I am using >> >> VHDL. Synopsys FPGA Xpress, or Synplicity, Exemplar, Accolade. and peter@xilinx.com replied: >> >> >> > >> >The design approach will be heavily influendced by the required speed. >> >If both clocks are fully asynchronous and run at 80 MHz, it may be >> >beyond the reach of VHDL, >> >but the silicon can still do it. >> >At low clock rates, the design can be quite simple. >> > >> >Peter Alfke, Xilinx Applications >> > to which i stepped in and mischievously asked: >> Why is this beyond the reach of VHDL ? >> >> And if it is, isn't a pity that Xilinx are going to abandon schematic entry ? then Ray Andraka <randraka@ids.net> wrote: >It is very difficult to get this kind of performance in a synthesized design >(especially with the async clocks). In cases like this it is much faster and >easier to just to do it in schematic the way you know it needs to be implemented >and be done with it. IMO one of the reasons why the schematic entry vs. HDL debate keeps cropping up is statements like the above, which are originated by people who either: a) might have a vested interest in persuading people that they won't be able to use a HDL for their designs b) havn't tried using a HDL c) have tried a HDL, but didn't do it properly d) work for FPGA manufacurers and should perhaps know better. At it's heart, the 'cant do it in a HDL' arguement seems to stem from a confusion between inferred and instantiated HDL. No one is claiming that a synthesiser can infer a a complete async fifo. But using instantited components is a direct textual equivalant to schematic entry, so there is no design element that can be placed on a schematic that can't be included in a HDL design. Period. (as you Americans say). I believe that the mixed inferred/instantiated method is used by most experienced HDL designers. A designer might predominately infer logic, but a some point will say to themselves 'it will be easier to just instantiate this element and have done with it'. My suggestion is that the bi-partisan postings should cease, and that the gurus who reqularly offer excellent advice to people like Richard Schwarz should stick to describing the elements of a design and how they should be linked together, and take it for granted that some people will draw their designs, and some will type them in. For example, offer advice like, ..... you're gonna need a dual port ram element, may be RLOC some things together if you want it to go fast... etc, etc -- Edward Moore Snell & Willcox Ltd PS. any connection between some parts of this reply and current political events in a well-known super power is purely non-coincidental.Article: 13717
>Subject: Atmel's PLD >From: "sam" <cong_sp@willnet.co.jp> >Date: 12/13/98 8:31 PM Pacific Standard Time >Message-id: <75fqvd$2pq$1@hustler.asahi-net.or.jp> > >Does anyone have trouble when use Atmel's PLD ? >I will never use Atmel's PLD . It's too bad . > I've done dozens of designs with the ATV750 and ATV2500 parts. These parts work very predictably. They have uniform structures, and consistent logic delays. They do asychronous logic just fine, so you don't have to global clock everything, and the logic array seems near glitch free. They can even do neat things like registered feedback with combinatorial output. They are not noisy as a lot of plds I've used, and have reasonable levels of ground bounce.Article: 13718
Rolavine (rolavine@aol.com) wrote:
: >Subject: Atmel's PLD
: >From: "sam" <cong_sp@willnet.co.jp>
: >Date: 12/13/98 8:31 PM Pacific Standard Time
: >Message-id: <75fqvd$2pq$1@hustler.asahi-net.or.jp>
: >
: >Does anyone have trouble when use Atmel's PLD ?
: >I will never use Atmel's PLD . It's too bad .
: I've done dozens of designs with the ATV750 and ATV2500 parts. These parts work
: very predictably. They have uniform structures, and consistent logic delays.
: They do asychronous logic just fine, so you don't have to global clock
: everything, and the logic array seems near glitch free. They can even do neat
: things like registered feedback with combinatorial output. They are not noisy
: as a lot of plds I've used, and have reasonable levels of ground bounce.
I feel the same way. I've been working with the 2500 for the last while,
and it's a great part. The only limitation I've bumped into was the
single-product-term clock for each macrocell register, but that's not much
to complain about.
What don't you like?
Jonathan
--
jonathan@canuck.com
Canada Connect Corporation | Jonathan | Survival Research Laboratories
Calgary, AB | Levine | San Francisco, CA
403-705-2025, fax 2026 vox/fax 415-641-8065
Article: 13719> >It is very difficult to get this kind of performance in a synthesized design > >(especially with the async clocks). In cases like this it is much faster and > >easier to just to do it in schematic the way you know it needs to be implemented > >and be done with it. > > IMO one of the reasons why the schematic entry vs. HDL debate keeps > cropping up is statements like the above, which are originated by people > who either: > > a) might have a vested interest in persuading people that they won't be > able to use a HDL for their designs > > b) havn't tried using a HDL > > c) have tried a HDL, but didn't do it properly > > d) work for FPGA manufacurers and should perhaps know better. > > At it's heart, the 'cant do it in a HDL' arguement seems to stem from a > confusion between inferred and instantiated HDL. No one is claiming that > a synthesiser can infer a a complete async fifo. But using instantited > components is a direct textual equivalant to schematic entry, so there > is no design element that can be placed on a schematic that can't be > included in a HDL design. Period. (as you Americans say). > > I believe that the mixed inferred/instantiated method is used by most > experienced HDL designers. A designer might predominately infer logic, > but a some point will say to themselves 'it will be easier to just > instantiate this element and have done with it'. > > My suggestion is that the bi-partisan postings should cease, and that > the gurus who reqularly offer excellent advice to people like Richard > Schwarz should stick to describing the elements of a design and how they > should be linked together, and take it for granted that some people will > draw their designs, and some will type them in. For example, offer > advice like, > > ..... you're gonna need a dual port ram element, may be RLOC some things > together if you want it to go fast... etc, etc > I didn't say it couldn't be done. My point is that for something like this, it is not worth trying to synthesize the design. Structural HDL works quite well for this, but when you are at that level I find that the design is easier to enter and to understand as a schematic than as structural HDL, which might as well be a textual netlist of the schematic. Period. Right now, I can complete a high performance design faster and more reliably using my hierarchical schematic methodology than I can with an HDL. Between June 97 and June 98 I did 33 FPGA designs, most of which were XC4025/28 -2 DSP datapath designs running at data rates of 40+ MSPS, most were 70+% utilized and heavily floorplanned, and all but one were done with schematics. The HDL tools are improving rapidly, and have come a long way in the past year or two. I am looking forward to being able to achieve the same level of success with HDLs, as that can only help my business grow. With that in mind, I think I have a vested interest in seeing HDL tools become better at providing the fine level of control over a design without sacrificing design time to get there. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 13720
Greetings:
I'm making my toe-in-the-water, tentative investigations into moving
a prototyped design into an fpga, probably Xilinx. Can any of this
group's regulars tell me what the licensing terms and (ballpark) price
are for the third-party 16550 core that they supply?
It's Sunday, so please don't tell me to call a sales wonk.
Thanks much.
--
jonathan@canuck.com
Canada Connect Corporation | Jonathan | Survival Research Laboratories
Calgary, AB | Levine | San Francisco, CA
403-705-2025, fax 2026 vox/fax 415-641-8065
Article: 13721> Tim is correct, I believe there is a need for smaller pincount devices, > the 150 mil SO16/DIP16 would seem a logical part, and resource to > replace > a large chunk of all TTL grade MSI. > Also the 20 / 24 pin device with 22i/o lines is a candidate. I agree, except the package can be a problem. If you want to socket it, the SMT SO devices don't have very friendly (if at all) sockets. The PLCC28 is certainly the easiest to socket....and though is taller (so what for most applications) doesn't take up much more space than the SO24WB does.... Austin Franklin darkroom@ix.netcom.comArticle: 13722
<snip> > >It is very difficult to get this kind of performance in a synthesized design > >(especially with the async clocks). In cases like this it is much faster and > >easier to just to do it in schematic the way you know it needs to be implemented > >and be done with it. Easier is the keyword here, not that it can't be done, but it IS easier and faster to do in schematic, then to fight with the synthesis tools. You certainly can, structurally, create any design in VHDL that you can using a schematic, but basically you are writing a netlist, instead of doing an understandable design. Second, floorplanning/placement is tougher with HDLs than schematic. In order to achieve the highest performance, you must floorplan. > IMO one of the reasons why the schematic entry vs. HDL debate keeps > cropping up is statements like the above, which are originated by people > who either: > > a) might have a vested interest in persuading people that they won't be > able to use a HDL for their designs HDLs have their places. Not the reason. > b) havn't tried using a HDL Have done a lot of HDL, not the reason. > c) have tried a HDL, but didn't do it properly Not the reason again. Personally, I believe the problem is more with the compiler and the documentation, than 'doing it properly'. It can be a guessing game trying to figure out what HDL code generates what logic.... > d) work for FPGA manufacurers and should perhaps know better. Not that either... In fact, a good part of my living is made from tool and FPGA manufacturers convincing their clients to use HDLs to do designs. > At it's heart, the 'cant do it in a HDL' arguement seems to stem from a > confusion between inferred and instantiated HDL. No confusion here about that either.... <snip> > I believe that the mixed inferred/instantiated method is used by most > experienced HDL designers. A designer might predominately infer logic, > but a some point will say to themselves 'it will be easier to just > instantiate this element and have done with it'. Equally, it would have been easy to just do a schematic, and 'be done with it'. AND you can specify placement/floorplanning information very easily on the schematic, both relative and/or absolute. > My suggestion is that the bi-partisan postings should cease, and that > the gurus who reqularly offer excellent advice to people like Richard > Schwarz should stick to describing the elements of a design and how they > should be linked together, and take it for granted that some people will > draw their designs, and some will type them in. For example, offer > advice like, I guess you find it hard to believe that some people have learned through vast amounts of experience (and hundreds of FPGA designs with BOTH schematic and HDL), have come to the conclusion that using schematics for certain things is THE correct and best approach, currently? Austin Franklin darkroom@ix.netcom.comArticle: 13723
Always a problem with *SMT* programmable devices: one has to open the sealed package, program them, reseal the original package, place the programmed ones on the PCB & reflow (or place in another sealed package if subcontracting the pick/place). I wish there was a 22V10, zero-power (like Philips P3Z22V10) which was ISP, programmable in-circuit via 3 pins. Then one could use a TSOP-28 version, or some other tiny package. This is why I never liked the concept of *antifuse* FPGAs - the logistics of using them in a *subcontracted* pick/place situation (which is true for the vast majority of small firms) are very difficult. Too many easily bent pins. I use the PLCC28 22V10s too. It also does not need the special sealed packaging/handling, because of its substantial package thickness. >I agree, except the package can be a problem. If you want to socket it, >the SMT SO devices don't have very friendly (if at all) sockets. The >PLCC28 is certainly the easiest to socket....and though is taller (so what >for most applications) doesn't take up much more space than the SO24WB >does.... -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13724
Victor the Cleaner wrote: > > Greetings: > > I'm making my toe-in-the-water, tentative investigations into moving > a prototyped design into an fpga, probably Xilinx. Can any of this > group's regulars tell me what the licensing terms and (ballpark) price > are for the third-party 16550 core that they supply? > > It's Sunday, so please don't tell me to call a sales wonk. > > Thanks much. > > -- > jonathan@canuck.com > Canada Connect Corporation | Jonathan | Survival Research Laboratories > Calgary, AB | Levine | San Francisco, CA > 403-705-2025, fax 2026 vox/fax 415-641-8065 CAST (who supply a 16550 UART core as part of the Xilinx AllianceCORE offering) had prices on their web page at: http://www.cast-inc.com/info/pr/XilinxOct98.htm I'm not sure if that's still there, but the price quoted was $6250 for the core license. According to the data sheet it uses 493 CLBs. -- Alasdair Maclean, Senior Development Engineer, Marconi Electronic Systems, Electro Optics Systems Division, Building 1A, Room 1-11, 4 Ferry Road, Silverknowes, Edinburgh, Scotland EH4 4AD Tel: +44 (0)131 343 5711, Fax: +44 (0)131 343 5050 Email: replace "junk" with "alasdair.maclean" in the reply address.
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