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
In article <381de3c0.1684135@news.freeserve.net>, martin@the-thompsons.freeserve.co.uk wrote: > On 1 Nov 1999 01:01:54 GMT, murray@pa.dec.com (Hal Murray) wrote: > > > > >[snip bit-serial suggestions] > > > >> My point was that smaller/cheaper is not the issue for me at the > >> moment, once smaller/cheaper becomes important, we'll be in ASIC > >> territory anyway. > > > >Won't the same techniques help you get a smaller/cheaper ASIC? > > In general, if your design meets timing in programmable logic, you are WAY ahead in ASIC technology. This is one of the problems with taking a programmable logic design directly to ASIC. Where on the FPGA you tend to make highly pipelined architectures since there F/F's are there anyway, in ASIC you can often get away with way less pipelining because the interconnect delay is so fast (and availability of wide fan-in cells). A direct conversion would be overkill(larger) to build all those F/Fs in the ASIC. Josh > > Martin > > >-- > >These are my opinions, not necessarily my employers. > > Martin Thompson > martin@the-thompsons.freeserve.co.uk > http://www.the-thompsons.freeserve.co.uk/ > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18676
In article <3822E2B1.2EFFCB82@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: > project wrote: > > > > Where can I find an address with FPGA prices? Or what is > > aproximately the prize of an FPGA? > > Thanks > > > > * Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful > > You can get pricing from several distributor's web sites, but it won't > be very accurate. They then to list the highest prices they charge. I > have found that FPGA prices are a bit like car prices. If you take the > first price you are given, you paid too much. It is best to call and get > a quote based on your quantity, even if that quantity is small. As long > as you do some volume with that disti, they will discount FPGA prices. > I agree with you that the price is a bit like buying a car. When designing in parts for any volume production you want to avoid sole source parts like the plague. Prices tend to be effected more by competition than by the cost it took to make the part in question. A good way to go if you have to use programable logic is design a dual footprint PCB or select parts and layouts that permit you to populate 1 of 2 competing parts such as Altera 7K and Xilinx 9k. You will find a dramatic price difference in your quotes when it is evident that you could go either way and can do so at any point in your production cycle. And to answer the original question very roughly speaking small FPGA's <$10 in qty and CPLDs<$5 in qty. Josh Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18677
> If folks want to always use two synchronizing flip-flops in series, > that's fine with me, because it's infinitely superior to doing > nothing, and it works. But if there's sufficient time for a single > synchronizing flip-flop to settle (sufficient = acceptably high MTBF), > a second rank isn't necessarily mandatory. It isn't foolproof though. The key idea is excess setup time. You can build a system with 2 flip-flops that doesn't do much good if you put them on opposite sides of the chip and burn up the whole cycle of setup time with routing. Similarly, if you have a heavily pipelined system and your clock rate is high enough that you already have very restricted routing, your MTBF may not be very high even with minimal routing. Putting both FFs in the same CLB helps a lot, but that sort of hint depends upon the technology you are using. Keep beating on the vendors. Maybe they will get the message one of these days. -- These are my opinions, not necessarily my employers.Article: 18678
> There is much in the literature in that regard already. Many try to include > multipliers and such. Problem is, as you get more complicated blocks, the > harder it is to generalize to get the ideal block and the harder it is to fit > your algorithm to the block. If you take that to the extreme, you wind up with > a DSP microprocessor. When you have bigger blocks, you will have less of them > for a given silicon area, and if they are function specific, then you run into a > limited resource problem. There is another problem with specialized/complicated blocks. It reduces the volume of the parts you want which raises the cost. It also means they won't be as close to the leading edge of the technology curve. That also raises the cost. -- These are my opinions, not necessarily my employers.Article: 18679
I deal in hardware. I recently purchased a few lots of CPUs. Among these lots were a quantity of FPGA chips. They were accompanied by an RMA slip which gave as a reason for return: "fine pitch contacts off line - do not line up with machine". I did NOT get these chips from Xilinx, so I can only assume the RMA (which is dated 6/98) was never implemented for some reason. Specifically, these are XC4020E-4HQ240C chips, and I have 48 of them (2 trays). About a dozen chips in one of the trays have varying degrees of bent pins ranging from mild to severe, but the rest appear to be perfect. So here's my problem: I would like to sell them, but I'm not sure where I should direct my efforts. Because these are SMD devices I don't know whether I should even bother directing them towards hobbyists. But because I only have 48 (and less due to damage), I doubt that a manufacturer would get real excited over them. Any tips or opinions are welcome. Thank you. MikeArticle: 18680
Dear Guys, I am dealing with hardware interfacing between a FPGA (maybe from Xilinx) and a DAC (digiatal to analog converter). The DAC, I can found, can be of ECL or TTL. Does FPGA support these two interfacing voltage levels? Thanks. ChildArticle: 18681
Dear Guys, I know that some FPGAs are of ROM architecture while some of them are of SRAM. If I would like a speed of 155Mbps, is there any ROM type FPGA available in the market? Thanks. ChildArticle: 18682
Hal Murray wrote: > > There is much in the literature in that regard already. Many try to include > > multipliers and such. Problem is, as you get more complicated blocks, the > > harder it is to generalize to get the ideal block and the harder it is to fit > > your algorithm to the block. If you take that to the extreme, you wind up with > > a DSP microprocessor. When you have bigger blocks, you will have less of them > > for a given silicon area, and if they are function specific, then you run into a > > limited resource problem. > > There is another problem with specialized/complicated blocks. It > reduces the volume of the parts you want which raises the cost. > > It also means they won't be as close to the leading edge of the > technology curve. That also raises the cost. it perhaps is an interesting race to see if a "simple and regular" architecture moving with short development times and staying on the edge of process technology beats in performance the more "complex with specialized features" architecture with longer design times and slower to take advantage of new processes. this was interesting to watch in the cpu world. it also makes it harder for the software support - getting the vhdl synthesizers to deal with it - and there's the push to get things moved into vhdl (or verilog or now the push is to c/c++, etc.). rkArticle: 18683
Hal Murray wrote: > > If folks want to always use two synchronizing flip-flops in series, > > that's fine with me, because it's infinitely superior to doing > > nothing, and it works. But if there's sufficient time for a single > > synchronizing flip-flop to settle (sufficient = acceptably high MTBF), > > a second rank isn't necessarily mandatory. > > It isn't foolproof though. The key idea is excess setup time. > > You can build a system with 2 flip-flops that doesn't do much good > if you put them on opposite sides of the chip and burn up the whole > cycle of setup time with routing. > > Similarly, if you have a heavily pipelined system and your clock rate > is high enough that you already have very restricted routing, your > MTBF may not be very high even with minimal routing. Putting both > FFs in the same CLB helps a lot, but that sort of hint depends > upon the technology you are using. > > Keep beating on the vendors. Maybe they will get the message > one of these days. some vendors are very good at publishing numbers (which should be either worst-case or guaranteed over different operating conditions in a table). others produce nothing, even for those devices targeted at high-reliability and/or military applications. another beating done. who's next? :-) rkArticle: 18684
There are non-volatile RAMs on the market which can handle clock rates of 155Mbps. However, I can't think of any that have carry chains so if your design requires arithmetic or fast counters you will have to resort to other (larger) structures for fast carry generation. The bottom line is that the suitability of a particular device depends on the application. Look at Actel and Quicklogic. Child K.L. Sun wrote: > Dear Guys, > > I know that some FPGAs are of ROM architecture while > some of them are of SRAM. If I would like a speed of 155Mbps, > is there any ROM type FPGA available in the market? > > Thanks. > > Child -- -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: 18685
just to add on a bit ... for the actelians, look at the new sx-a (0.25um) 2.5V devices they recently announced. i haven't had a chance to look at them yet with some sample designs (need software update) although some prototype devices were quite fast. what sort of logic do you need to run at 155 Mbps? for q-logic, i haven't seen anything below their 0.35 um, 3.3V process, although for high-speed stuff they've been putting hardwired functions on chip, taking a different path (i.e., memories, pci controllers). lastly, perhaps a nit (and i'm struggling to come up with good defintions for these terms, perhaps a later post), the classification of storage technologies can be divided up a bit more. for non-volatile, i would also include flash technologies (such as gatefield) and sonos cell (developed by westinghouse aka northrop-grumman) which was being used in the mission research corp. fpga). i would also classify these two technologies into the re-programmable class, from which most actel and all q-logic products would be excluded. so, for the original poster, is there a requirement for otp or just non-volatility? rk =================== Ray Andraka wrote: > There are non-volatile RAMs on the market which can handle clock rates > of 155Mbps. However, I can't think of any that have carry chains so if > your design requires arithmetic or fast counters you will have to resort > to other (larger) structures for fast carry generation. The bottom line > is that the suitability of a particular device depends on the > application. Look at Actel and Quicklogic. > > Child K.L. Sun wrote: > > > Dear Guys, > > > > I know that some FPGAs are of ROM architecture while > > some of them are of SRAM. If I would like a speed of 155Mbps, > > is there any ROM type FPGA available in the market? > > > > Thanks. > > > > ChildArticle: 18686
On 7 Nov 1999 04:27:47 GMT, murray@pa.dec.com (Hal Murray) wrote: > >> If folks want to always use two synchronizing flip-flops in series, >> that's fine with me, because it's infinitely superior to doing >> nothing, and it works. But if there's sufficient time for a single >> synchronizing flip-flop to settle (sufficient = acceptably high MTBF), >> a second rank isn't necessarily mandatory. > >It isn't foolproof though. The key idea is excess setup time. > >You can build a system with 2 flip-flops that doesn't do much good >if you put them on opposite sides of the chip and burn up the whole >cycle of setup time with routing. > >Similarly, if you have a heavily pipelined system and your clock rate >is high enough that you already have very restricted routing, your >MTBF may not be very high even with minimal routing. Putting both >FFs in the same CLB helps a lot, but that sort of hint depends >upon the technology you are using. I think we're going in circles here. The purpose of my post was to amplify a point Rick Collins made, namely that excess setup time, and not necessarily the number of synchronizer stages, is the central issue. The first problem you mention, that of squandering the excess setup time in routing, can be addressed through placement, or by defining an additional timespec for each synchronizer rank that minimizes the delay between that FF and any FF it drives (me, I add the timespec). The second situation may require more synchronizer stages. In short, when I design synchronizers, I: 1) choose the number of synchronizer stages that best match the clock speed and the latency requirements. 2) maximize the amount of settling time at each synchronizer stage through the addition of a tight timespec for that stage. 3) calculate the resultant MTBF. I go for 1 million years minimum; a convincing argument can be made for higher targets, and I wouldn't argue against it. 4) Iterate on (1) - (3) until I get an MTBF I can live with. This is all fairly straightforward stuff that (I hope) people have been doing for years. Here are a couple of less obvious problems: 1) inadvertent flip-flop duplication. It's been mentioned in this newsgroup that either the synthesis tool or the place/route tool can inadvertently duplicate synchronizer flip-flops. The solution is vendor-dependent, but the bottom line is that synchronizing a signal in two flip-flops wired in parallel can be a disaster, and must be avoided. 2) anomalous FIFO full/empty flag behavior. Lots of folks, myself included, use FIFOs to transfer data between two mutually-asynchronous clock domains. The full and empty flags of the FIFO are sometimes used to control write and read state machines on either side of the FIFO. These flags are a function of both the write clock and the read clock; to be useful, the full flag must be synchronized to the write clock and the empty flag to the read clock. At the risk of making the biggest understatement in the thread so far, THIS IS TRICKY. What's more, you usually can't solve the problem merely by putting the flag through additional synchronization external to the FIFO. (Question: What happens if you put the full flag through a couple of stages of synchronization before presenting it to the FSM that controls FIFO writes? When the FIFO goes full, how long does it take for the FSM to stop writing? Answer: Uh-oh.) Some designers avoid the problem by ensuring that a given FIFO never goes empty or full, but this isn't always possible. Designers of FIFO ICs have been grappling with these flag problems for ages; the person who designed your TI or IDT or Cypress FIFO may have been designing FIFOs for 10 years. Whereas the person who designed your FIFO macrocell or FIFO IP may have been designing FIFOs since, say, last Tuesday. It behooves the FPGA designer to check the design of any FIFO he or she uses, particularly if the FIFO's full or empty flags are being used. If you want to get an idea of just how involved proper FIFO flag design can be, take a look at Peter Alfke's app notes on the Xilinx website, or at some writeups done by John Birkner and his colleagues on the Quicklogic website. Take care, Bob Perlman ----------------------------------------------------- Bob Perlman Cambrian Design Works Digital Design, Signal Integrity http://www.best.com/~bobperl/cdw.htm Send e-mail replies to best<dot>com, username bobperl -----------------------------------------------------Article: 18687
This is a multi-part message in MIME format. --------------C309E856364F06028EA638F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit U can check out this site ftp://ftp.xilinx.com/pub/documentation/xactstep6/xnfspec.pdf Cheers Anup YUN SONG HYUN wrote: > Hi there! > > I am about to make XNF Reader. > > If you have XNF grammar, could you email me? > > -- Yun song hyun -- --------------C309E856364F06028EA638F2 Content-Type: text/x-vcard; charset=us-ascii; name="anup.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for anup kumar raghavan Content-Disposition: attachment; filename="anup.vcf" begin:vcard n:Anup Kumar;Raghavan tel;home:0061-7-38761962 tel;work:0061-7-33658849 x-mozilla-html:FALSE url:www.csee.uq.edu.au org:University of Queensland;Computer Science and Electrical Engineering adr:;;;;;;Australia version:2.1 email;internet:anup@elec.uq.edu.au fn:Anup Kumar end:vcard --------------C309E856364F06028EA638F2--Article: 18688
Bob Perlman wrote: > This is all fairly straightforward stuff that (I hope) people have > been doing for years. Here are a couple of less obvious problems: > > 1) inadvertent flip-flop duplication. It's been mentioned in this > newsgroup that either the synthesis tool or the place/route tool can > inadvertently duplicate synchronizer flip-flops. The solution is > vendor-dependent, but the bottom line is that synchronizing a signal > in two flip-flops wired in parallel can be a disaster, and must be > avoided. > Easiest way to avoid it in synthesis it to instantiate the primitives directly. You can also RLOC the flipflops to the same CLB easily that way. > 2) anomalous FIFO full/empty flag behavior. Lots of folks, myself > included, use FIFOs to transfer data between two mutually-asynchronous > clock domains. The full and empty flags of the FIFO are sometimes > used to control write and read state machines on either side of the > FIFO. These flags are a function of both the write clock and the read > clock; to be useful, the full flag must be synchronized to the write > clock and the empty flag to the read clock. At the risk of making the > biggest understatement in the thread so far, THIS IS TRICKY. What's > more, you usually can't solve the problem merely by putting the flag > through additional synchronization external to the FIFO. (Question: > What happens if you put the full flag through a couple of stages of > synchronization before presenting it to the FSM that controls FIFO > writes? When the FIFO goes full, how long does it take for the FSM to > stop writing? Answer: Uh-oh.) Some designers avoid the problem by > ensuring that a given FIFO never goes empty or full, but this isn't > always possible. > > Designers of FIFO ICs have been grappling with these flag problems for > ages; the person who designed your TI or IDT or Cypress FIFO may have > been designing FIFOs for 10 years. Whereas the person who designed > your FIFO macrocell or FIFO IP may have been designing FIFOs since, > say, last Tuesday. It behooves the FPGA designer to check the design > of any FIFO he or she uses, particularly if the FIFO's full or empty > flags are being used. > > If you want to get an idea of just how involved proper FIFO flag > design can be, take a look at Peter Alfke's app notes on the Xilinx > website, or at some writeups done by John Birkner and his colleagues > on the Quicklogic website. Couldn't agree more. Be careful of the macros out there too, they are far from perfect. > Take care, > Bob Perlman > > ----------------------------------------------------- > Bob Perlman > Cambrian Design Works > Digital Design, Signal Integrity > http://www.best.com/~bobperl/cdw.htm > Send e-mail replies to best<dot>com, username bobperl > ----------------------------------------------------- -- -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: 18689
It appears that the new Xilinx tools don't allow me to just download a bit file. XChecker is apparently not shipped with the new tools, and the hardware debugger requires me to have the 'project' there.... What gives?Article: 18690
All the debugger needs in the 'project' is the bit file, and if you are planning on doing readbacks the .ll file. For just downloading, the bit file can be the .bit or a rom file in any of the formats (.exo, .mcs etc.). For readback, you must use the .bit file. Austin Franklin wrote: > It appears that the new Xilinx tools don't allow me to just download a bit > file. XChecker is apparently not shipped with the new tools, and the > hardware debugger requires me to have the 'project' there.... > > What gives? -- -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: 18691
>so, for the original poster, is there a requirement for otp or just >non-volatility? I am using FPGA for the lab purpose to implement some selectable demux and encoding. > +-------+ (2) +-------+ (10) > o--|1:2 S/P|=====|Encoder|======o > / +-------+ +-------+ \\ > / +-------+ (3) +-------+ (10) \\ >155Mbps------o o--|1:3 S/P|=====|Encoder|======o o=== Parallel Output > +-------+ +-------+ > +-------+ (4) +-------+ (10) > o--|1:2 S/P|=====|Encoder|======o > +-------+ +-------+ > ^ ^ > | | > | | > Selector Selector So, the highest speed "seen" by the encoding circuitry should be only 155Mbps/2. For the convenience of experiment, I would prefer ROM rather RAM type FPGA. Is there any? Thanks. ChildArticle: 18692
LATTICE SEMICONDUCTOR INTRODUCES THE PLD OF ANALOG CHIPS Truly Programmable Analog Products Bring Easy, Fast & Flexible Design to Analog Designers HILLSBORO, OR - NOVEMBER 8, 1999 -Lattice Semiconductor (NASDAQ: LSCC) today announced its entrance into the Programmable Analog market with its new family of Programmable Analog Circuit monolithic ICs, the ispPAC(tm) family. The first two devices in the family available today are the ispPAC10 and ispPAC20. Dubbed by Lattice as the "PLD of Analog Chips," the ispPAC family brings the easy, fast, and flexible design benefits associated with Programmable Logic to the world of Analog design for the first time. The ispPAC products integrate up to 60 active and passive analog components with hundreds of values onto a single chip. An engineer uses PC-based point-and-click software to set the characteristics of the analog components needed and to hook them together. The chip is programmed when the resulting design is downloaded into the chip's E2 configuration memory, and can be instantly reprogrammed when the user makes design changes. "The PLD sprang onto the scene 20 years ago and engineers creating digital logic seized on the PLD's great step forward in ease-of-design and time-to-market, growing a $2.3B market in the process," said Cyrus Tsui, Lattice's CEO. "Pioneering in PLDs was gratifying because it changed the world of digital design. I've wanted to bring the same benefits to analog designers for 10 years and am very pleased that our breakthrough engineering work allows us to do that today." Systems interface with the real world, and that creates a need to handle analog signals representing temperature, voltage, current, pressure, etc. Engineers typically design the desired analog circuits on paper or at a computer, then build a prototype board to prove it out. But it is very laborious and time-consuming to make the prototype work due to the variability of the multiple analog components used, combined with the extreme sensitivity analog circuits generally have to layout. Analog components exhibit slightly different characteristics from manufacturing lot to lot and from supplier to supplier, so once completed, the prototype board may be further delayed as it is modified to achieve manufacturability. The Initial ispPAC Products The first member of the PAC(tm) family is the ispPAC10. It includes four filter-summation PACblocks connected by an Analog Routing Pool. These can be configured to do summation and integration, and have programmable gain up to ±20x, delivering a large gain range of 0-160,000 in millions of steps. The PAC(tm) blocks also provide push-button, high precision, continuous time, second-, third-, and fourth-order low-pass filtering over a range of 10KHz-100kHz, with fine resolution selectable from thousands of useful combinations. The ispPAC20 has two PAC blocks similar to the ispPAC10's, and adds an 8-bit D-to-A converter and two differential comparators. The initial ispPAC devices both perform with high linearity (88dB THD @ 10kHz) over a large dynamic range (>100dB), through fully differential inputs and outputs, all using a single +5V power supply at industrial temperatures. And since the ispPAC family incorporates Lattice-innovated ISP(tm) (In-System Programmability), ispPAC products can be programmed and reprogrammed right on the circuit board, even after being soldered in place. ISP makes design changes remarkably fast and easy. The PAC-Designer software tool is an integrated analog design environment with an easy-to-use GUI. It quickly enables the user to obtain "what-you-see-is-what-you-get" design results. PAC-Designer software is available for Windows 95, Windows 98, and Windows NT. Applications The ispPAC family will be used in a diverse field of applications, just as are discrete and low-integration analog components. Some general usage themes will find ispPAC products near DSP functions preparing the analog signal for digitization, next to the 30 percent of microcontrollers estimated to be used in conjunction with analog signals, in front of the volume of 12-bit A-to-D converters consumed today, and next to Lattice/Vantis ispPLDs used in myriad applications, which include analog circuitry. Applications are expected to include a host of industrial sensing, test, and measurement designs as well as communication and computation systems. What You See Is What You Get Using the ispPAC Family's PAC-Designer(r) software at a PC, an engineer selects the right analog components, their characteristics, and their interconnections on-screen. A simulator shows the resulting signals immediately. Since the analog components, their characteristics, and their interconnect are all on-chip, the designer can now enjoy the incomparable "What You See Is What You Get" benefit of the ispPAC Family - the programmed chip delivers precisely the signal shown by the simulator. And each ispPAC device delivers the same high-precision results repeatably, so board manufacturability follows quickly and easily. Powerful Macros Continuous-time Biquad and Ladder Filters are very complex functions that have been burdensome and involved for analog designers. Now they are included as user-friendly macros in the PAC-Designer software's library. Although board-level designers have enjoyed filter-synthesis software for years, the frame-breaking difference we provide is that after completing the design on the computer screen, the user downloads the design into the ispPAC device and the job is instantly complete, with unprecedented precision. This ease-of-design has never before existed for analog circuitry. The Lattice programmable continuous-time technology that makes it possible is truly a major engineering advance. Reduced Cost of Ownership The integration of dozens of analog components in a single ispPAC product yields higher quality and reliability; lower purchasing, inventory, and assembly costs; and a board space savings. Further, each board can be calibrated while in use at the system level, exploiting the built-in autocalibration capability. This robust approach eliminates the need for costly trimming steps and components in the manufacturing process. Availability The ispPAC10 and ispPAC20 products and the PAC-Designer software are all available now. Pricing for the ispPAC10 or the ispPAC20 is under $7 in thousands. The PAC-Designer software can be downloaded from www.latticesemi.com and is complimentary during an introductory period. PACsystem10 and PACsystem20 Evaluation Kits can be ordered on the website for $149. The Kits include software, samples, download cables, evaluation boards, technical documentation, and application notes. The PACsystems are also available through our extensive distribution channels at a suggested retail price of $149. About Lattice Semiconductor and Vantis Oregon-based Lattice Semiconductor Corporation designs, develops and markets the broadest range of high-performance ISP programmable logic devices (PLDs) and offers total solutions for today's advanced logic designs. Lattice introduced in-system programmability to the logic industry in 1992. In June 1999, Lattice acquired Vantis, the corporation that invented the PAL(r) device and PLD switch matrix architecture, from AMD. With nearly double the R&D and sales resources, the resulting integrated company will focus on delivering logic products that satisfy the performance, density and ease-of-use requirements of its customers. Lattice/Vantis products are sold worldwide through an extensive network of independent sales representatives and distributors, primarily to OEM customers in the fields of communications, computing, computer peripherals, instrumentation, industrial controls and military systems. Company headquarters are located at 5555 NE Moore Court, Hillsboro, Oregon 97124 USA; Telephone 503-268-8000; FAX 503-268-8037. For more information on Lattice Semiconductor or Vantis Corporation, access our World Wide Web site at http://www.latticesemi.com. Statements in this news release looking forward in time are made pursuant to the safe harbor provisions of the Private Securities Litigation Reform Act of 1995. Investors are cautioned that forward-looking statements involve risks and uncertainties, including the effect of changing economic conditions, the effect of overall semiconductor market conditions, product demand and market acceptance risks, risks associated with dependencies on silicon wafer suppliers, the impact of competitive products and pricing, technological and product development risks and other risk factors detailed in the Company's Securities and Exchange Commission filings. Actual results may differ materially from forward-looking statements. # # #Article: 18693
Hello Alexander,
I would suggest that you consider once the
recently announced and introduced ispPAC10
and ispPAC20 family parts from Lattice Semiconductor corp.
Free CAD sw is also downloadable and designkits are available at 149 US $.
I believe LSC has well studied its competitors (Zetex) and learned from
another (Mot....a) analog crash.
www.latticesemi.com
I hope this helps ...
regards,
Michel
WMU - Belgium
Alexander Sherstuk <sherstuk@amsd.com> wrote in message
news:7vt13m$8su$1@bull.east.ru...
> Hi All,
>
> Has anybody experience with TRAC020 chip from
> http://www.fas.co.uk/silicon.htm?
> Their data sheet does not mention possibility of any programming for
> resistors
> and capacitors in the matrix. Is that just specification omission?
>
> Thanks,
> Alex Sherstuk
>
>
>
Article: 18694Child K.L. Sun wrote: > >so, for the original poster, is there a requirement for otp or just > >non-volatility? > > I am using FPGA for the lab purpose to implement some selectable > demux and encoding. > > > +-------+ (2) +-------+ (10) > > o--|1:2 S/P|=====|Encoder|======o > > / +-------+ +-------+ \\ > > / +-------+ (3) +-------+ (10) \\ > >155Mbps------o o--|1:3 S/P|=====|Encoder|======o o=== Parallel Output > > +-------+ +-------+ > > +-------+ (4) +-------+ (10) > > o--|1:2 S/P|=====|Encoder|======o > > +-------+ +-------+ > > ^ ^ > > | | > > | | > > Selector Selector > > So, the highest speed "seen" by the encoding circuitry should be only 155Mbps/2. > For the convenience of experiment, I would prefer ROM rather RAM type FPGA. > Is there any? the s/p blocks should be easy but the logic equations would need to be known as speed of these things is design depenedent. another parameter that may be needed is the amount of pipelining that the system can take, assuming that the encoding couldn't be done in a single cycle. i doesn't sound unreasonable. perhaps you can call in the local fae's and have them run your design for you, since there's not enough info here. rkArticle: 18695
>I did once evaluate StateCAD for a month. The tool seemed >well-written and the support was very good, but at the end of the >month I was left with the question, "Why am I doing this?" There may >be a good answer, but it wasn't apparent to me. Despite being a >schematic diehard, I'm pretty happy with Synplicity, but see no need >to pile other stuff on top of it. As I once told a vendor, I'm not >sure I can survive another productivity improvement. >Take care, >Bob Perlman Couldn't agree more. We got StateCad as part of our Synario toolkit and had great fun playing with it at the start. But we never could get it to produce the VHDL code exactly as we wanted it - and then the resulting code has to be somehow inserted into a higher level VHDL design entity - in the end we went back to writing the state machines by hand. Mark Harvey Sent via Deja.com http://www.deja.com/ Before you buy.Article: 18696
Rich, I'm pretty sure the current crop of xilinx and altera parts could handle this data rate with minimal pipelining. I've done an FIR filter in xilinx with 16 bit wide parallel arithmetic that runs at around 150 MHz in a Virtex -4 (slowest speed grade). I've also done 16 bit arithmetic designs in 4000XLA-07's that run in the high 140 MHz range. His input is 155Mb/s and it is paralleled down to a maximum data rate of 78 MHz. The encoder output is 10 bits, so a reasonable guess is any arithmetic inside is likely to be less than 10 bits. The maximum width into the encoder is 4 bits, so if it is combinatorial, the logic is one LUT deep in both Altera and Xilinx. Obviously, not knowing the details of the encoder blocks, we can't really tell how complicated they are, but based on the observations of the input and output widths a first guess indicates that it is possible. I haven't looked at the Actel selection lately, so I don't know what kinds of speed you can expect there. I do know there is no carry chain, so you have to be careful in the selection of the logic used in artihmetic. A possibility might be to use a CPLD for this. Most of the CPLDs are non-volatile, and many support in system reprogrammability. If the system is as simple as represented here, I see no reason it wouldn't fit into one of the many CPLDs out there. Again, the data rates are within the realm of possibility for the currently available devices with careful design. rk wrote: > Child K.L. Sun wrote: > > > >so, for the original poster, is there a requirement for otp or just > > >non-volatility? > > > > I am using FPGA for the lab purpose to implement some selectable > > demux and encoding. > > > > > +-------+ (2) +-------+ (10) > > > o--|1:2 S/P|=====|Encoder|======o > > > / +-------+ +-------+ \\ > > > / +-------+ (3) +-------+ (10) \\ > > >155Mbps------o o--|1:3 S/P|=====|Encoder|======o o=== Parallel Output > > > +-------+ +-------+ > > > +-------+ (4) +-------+ (10) > > > o--|1:2 S/P|=====|Encoder|======o > > > +-------+ +-------+ > > > ^ ^ > > > | | > > > | | > > > Selector Selector > > > > So, the highest speed "seen" by the encoding circuitry should be only 155Mbps/2. > > For the convenience of experiment, I would prefer ROM rather RAM type FPGA. > > Is there any? > > the s/p blocks should be easy but the logic equations would need to be known as > speed of these things is design depenedent. another parameter that may be needed is > the amount of pipelining that the system can take, assuming that the encoding > couldn't be done in a single cycle. i doesn't sound unreasonable. > > perhaps you can call in the local fae's and have them run your design for you, since > there's not enough info here. > > rk -- -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: 18697
Ray, thanks. So now I have to go setup every guy in the lab and the production floor, who used to be able to just use a little 486 notebook w/ a 20M disk and DOS, with some version of Windoze, a mouse, and a project directory...instead of just XChecker and a .bit file on a floppy... To me, this seems silly to have made it 'so' complicated when it used to be so easy. Also, is there a way of doing it from the command line, as opposed to having to bring up the GIU, select 'stuff' etc.? Austin Ray Andraka <randraka@ids.net> wrote in article <382656DF.78722B5F@ids.net>... > All the debugger needs in the 'project' is the bit file, and if you are > planning on doing readbacks the .ll file. For just downloading, the bit file > can be the .bit or a rom file in any of the formats (.exo, .mcs etc.). For > readback, you must use the .bit file. > > Austin Franklin wrote: > > > It appears that the new Xilinx tools don't allow me to just download a bit > > file. XChecker is apparently not shipped with the new tools, and the > > hardware debugger requires me to have the 'project' there.... > > > > What gives? > > > > -- > -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/~randraka > > >Article: 18698
Has anyone had any luck mapping functions to LUTs in an Orca3C chip? Leonardo seems to have access to an internal library component called ORCALUT4 which does this, but I can't figure out how to get explicit access to it from VHDL. Here's the code I'm trying to map into a single PFU. I think each line could be mapped into its own 4LUT or 5LUT, and all three luts can be put in the same half of a PFU. .... MH <= (D(15) and D(14) and D(13) and D(12)) or not (D(15) or D(14) or D(13) or D(12)); ML <= (D(11) and D(10) and D(9) and D(8)) or not (D(11) or D(10) or D(9) or D(8)); M <= ( (D(12) and D(11)) or not (D(12) or D(11)) ) and MH and (W or ML); .... Here's how I tried to use the OrcaLut components: .... attribute lut_function of Lut0 : label is "(A*B*C*D+!(A+B+C+D))"; attribute lut_function of Lut1 : label is "(A*B*C*D+!(A+B+C+D))"; attribute lut_function of Lut2 : label is "((A*D+!(A+D))*B*(C+E))"; begin Lut0: orcalut4 port map (D(15), D(14), D(13), D(12), MH); Lut1: orcalut4 port map (D(11), D(10), D(9), D(8), ML); Lut2: orcalut5 port map (D(11), MH, ML, D(12), W); .... -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 18699
[Lots of trimming.] > >> If folks want to always use two synchronizing flip-flops in series, > >> that's fine with me, because it's infinitely superior to doing > >> nothing, and it works. > I think we're going in circles here. The purpose of my post was to > amplify a point Rick Collins made, namely that excess setup time, and > not necessarily the number of synchronizer stages, is the central > issue. I should have been clearer. What I was focusing on was the "it works" part. The two FFs rule works so well that it is almost good enough. But if you don't understand what is going on, it is possible to follow that rule and build a buggy system. One easy way to botch things is by burning all the excess setup time by routing a signal across the chip. > 3) calculate the resultant MTBF. I go for 1 million years minimum; a > convincing argument can be made for higher targets, and I wouldn't > argue against it. Where do you get the data to compute the MTBF? Are you using worst case numbers? The only numbers I've seen published are typicals. Where do you get data for new chips? The only data I've seen is generally an app-note that doesn't get published until the chip has been out for a while. I like your checklist. Now all we have to do is convince the manufacturers to support it. > Designers of FIFO ICs have been grappling with these flag problems for > ages; the person who designed your TI or IDT or Cypress FIFO may have > been designing FIFOs for 10 years. Whereas the person who designed Thanks for the reminder about FIFO flags. Speaking of metastability data, I don't remember ever seeing any from FIFO manufacturers. Note that the section of the FIFO data sheet that says that writes are a no-op if the FIFO is full and reads when empty doesn't mention metastability. (That's not a problem if both sides use the same clock and you have enough setup/hold time.) Anybody want to take a guess at what happens to the internal state of a FIFO if you are unlucky? -- These are my opinions, not necessarily my employers.
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