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
I don't know of anyone that makes a combination device with an HC11 and CPLD or FPGA. However, Triscend (www.triscend.com) makes a combination device called the E5 family that contains: * a high-performance 8051/52 compatible, similar to the Dallas 80C320 * between 2K to 40K gates of on-chip, SRAM-based programmable logic * between 8K bytes to 64K bytes of on-chip 15 ns memory * an on-chip 40 MHz system bus, supporting wait-states and single-cycle DMA transfers. The associated FastChip development system supports standard FPGA-style design if you want to create your own functions. The software ships with pre-designed functions that you can drag-and-drop onto the device. The library consists of standard microcontroller peripherals such as UARTs, SPI channels, two-wire serial, etc. There is an on-line tutorial at http://www.triscend.com/learning/IndexSelfPaced.html. ---- Steven K. Knapp Director, Online Support and Services Triscend Corporation -- The Configurable System-on-Chip Company 301 N. Whisman Rd. Mountain View, CA 94043 USA Tel: 650-968-8668 x166, FAX: 650-934-9393 sknapp@triscend.com, Web: www.triscend.com "myself" <nojunk@nojunk.com> wrote in message news:387c8739.145980691@news.magma.ca... > Hi I have a system that uses a motorola hc11 micro > Does enyone have a cpld or fpga built around a hc11 micro? > > cost? > >Article: 19926
Just how good a result is this guy going to get using his HC11 code on the processor you recommend? He did ask for HC11, didn't he? Dick On Tue, 18 Jan 2000 07:09:58 -0800, "Steven K. Knapp" <sknapp@triscend.com> wrote: >I don't know of anyone that makes a combination device with an HC11 and CPLD >or FPGA. > >However, Triscend (www.triscend.com) makes a combination device called the >E5 family that contains: > >* a high-performance 8051/52 compatible, similar to the Dallas 80C320 >* between 2K to 40K gates of on-chip, SRAM-based programmable logic >* between 8K bytes to 64K bytes of on-chip 15 ns memory >* an on-chip 40 MHz system bus, supporting wait-states and single-cycle > DMA transfers. > >The associated FastChip development system supports standard FPGA-style >design if you want to create your own functions. The software ships with >pre-designed functions that you can drag-and-drop onto the device. The >library consists of standard microcontroller peripherals such as UARTs, SPI >channels, two-wire serial, etc. > >There is an on-line tutorial at >http://www.triscend.com/learning/IndexSelfPaced.html. > > >---- > >Steven K. Knapp >Director, Online Support and Services >Triscend Corporation -- The Configurable System-on-Chip Company >301 N. Whisman Rd. >Mountain View, CA 94043 USA >Tel: 650-968-8668 x166, FAX: 650-934-9393 >sknapp@triscend.com, Web: www.triscend.com > > >"myself" <nojunk@nojunk.com> wrote in message >news:387c8739.145980691@news.magma.ca... >> Hi I have a system that uses a motorola hc11 micro >> Does enyone have a cpld or fpga built around a hc11 micro? >> >> cost? >> >> > >Article: 19927
mehmeto@my-deja.com wrote: > I have searched the net for a viterbi decoder implementation ( vhdl > source for FPGAs). I could not found any resources for free. VHDL codes > for K=7 R=1/2 are sold for > $20000.Decoders for K=9 are even much > expensive. So, why is this staff so expensive? I mean viterbi decoders > are widely used and someone can easily find a cheap decoder IC. Can > somebody explain the reason? > Is it too complex to build a VHDL model for K=7 R=1/2 ? Or is the > incoming data rate (kbits/s or Mbit/s)the main factor. > I have found many C codes for viterbi decoders. How can I use them to > translate to VHDL or Verilog for FPGAs? > > Thanks a lot > > Sent via Deja.com http://www.deja.com/ > Before you buy. Sounds like a good project for the IP public open core effort over on the verilog board.Article: 19928
On Tue, 18 Jan 2000 14:33:29 GMT, Ray Andraka <randraka@ids.net> wrote: >One of the things I considered was looking at the phase of the internal >oscillator compared to an external clock, which would be random even with >the same conditions, and would have a pretty much uniform distribution. To >do this, you need a fairly slow external clock (or divided clock), and >after the FPGA is configured count the number of cycles of the internal >oscillator until a specific transition of the external clock. The slower >the external clock with respect to the oscillator, the better the >resolution. Of course, for a slow clock, you want that independent of the >time you start configuration or the variance will again be small. > >In any of these methods, the value obtained should be used as an initial >seed to a digital PN sequence generator so that the distribution of your RN >is controllable, even if the seed is not nicely distributed. > >Dave Decker wrote: > >> Don't forget the built in OSC that has a very poor tempco. You could >> possibly substitute the internal OSC for the RC discussed below. >> >> Dave Decker Ray, Dave how about stirring the internal RC osc signal into the innards of a pseudorandom shift register, say by xor'ing the RC signal into some midpoint of a register clocked by something else. You now have a pseudorandom sequence that is executing essentially random state jumps. Faster is better here, I think. JohnArticle: 19929
Well said Sir! It never ceases to amaze me how many engineers (and their managers) fail to value their time, and associated on-costs to a given project. On Mon, 17 Jan 2000 14:02:17 GMT, Ray Andraka <randraka@ids.net> wrote: >Engineering time to develop, verify and support a core is not >insignificant. Consider what the cost would be for you to roll you own and >use that as a measure of the core's real cost. I think with that in mind, 99% of Engineers always think their cost to develop the same thing will be considerably less than the cost of the core. Probably 95% of them are wrong, but they'll never know until it's too late (if they ever know at all) >even at the prices you cite, the cores are a bargain. That is assuming >they are fully verified on the target architecture, and that they come with >some semblance of support. The FPGA cores business is a tough business to >make money in, for some reason people expect the cores to cost next to >nothing, and yet perform better than anythng they could develop in house. Prediction: Because of the mindset in the FPGA community business of FPGA "cores" will (within three years) have separated into three main areas 1 - Vendor I.P. This is just the silicon vendors doing what ASIC vendors have been doing in order to fill up the die/win orders/lock people in. The cores will be "free" or "subsidised", but you'll be locked in. It will be a means to an end, and a cost of doing business for the FPGA Vendors. We already see a ramp in this activity today. 2 - Highly Complex I.P. Stuff that everyone looks at and says "There's no way we could develop that, but by $DEITY we need it". Things that fall into this class are processors such as from the like of ARM, ARC, Lexra, MIPS, VAutomation, etc. (It's the tool-chain and system level stuff that is the hard part of developing a solution here) Other things that are particularly esoteric or large and complex will be in this camp. They will cost A LOT, because demand will be limited to a small number of select organisations. 3 - Freeware/shareware/no-support. Some of this will be good, some will be bad, but at least it'll be free, or practically free, right? Businesses will not (IMHO) make money selling low-end "noddy" cores such as UARTs, Peripheral controllers, CRC's etc. It may be possible for a "guru fred-in-the-shed" to make money through selling small HDL source at very low cost on the web, but charging for support and modifications. >What you are buying with a core is time to market, and possibly design >expertise you don't have in house. Bottom line is you gets what you pays >for. Peanuts = Monkeys Amen. Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 19930
You might want to check out WISHBONE at http://www.silicore.net/wishbone.htm / Jonas On Tue, 18 Jan 2000 11:28:50 +0200, Jamil Khaib <Khatib@ieee.org> wrote: >In the new world of SOC and design reuse the IP cores should be able to >interface to each other easily. Some companies are trying to define >their own cores interfaces and sometimes do not publish it. > >So we need to have a free open standard for cores interfaces that may be >become more powerfull and usable for all designers > >Do you have any comments how to start defining these interfaces? > >all what I know that there are two types Bus style or point-to-point >style but I do not know the advantages of each type. > >If you are intrested in defining this kind of interfaces please join us >at openipcore project > > > >Thanks >Jamil Khatib >OpenIP Organization http://www.openip.org >OpenIPCore Project http://www.openip.org/oc >OpenCores Project http://www.opencores.org > >Article: 19931
> how about stirring the internal RC osc signal into the innards of a > pseudorandom shift register, say by xor'ing the RC signal into some midpoint > of a register clocked by something else. You now have a pseudorandom > sequence that is executing essentially random state jumps. Faster is better > here, I think. I get suspicious when I see suggestions like that. If you are interested in random numbers, I suggest reading Knuth's book. Yes, it's mostly software, but the introduction is a great eye-opener. It describes a complicated algorithim that you can't possibly predict. It should make total garbage. But it doesn't! I think you will be better off using techniques that you can understand. Then you will know how good they are and/or where the limits are. You also have to understand how your random numbers will be used. Again, it helps to be able to analyze your random number generator to see if it fits into your application. If you are thinking of using something like an external clock to make your randomness more random, be sure you aren't just making things harder to understand. "random state jumps" aren't random if they happen at predictable times. All that does is change the output sequence from one pseudo-random pattern to a different one. I think the key parameter is the bandwidth of the noise you can get. If the second clock comes from a crystal you probably won't get much noise from it. On the other hand, it may be a simple and inexpensive to merge in a little more randomness. -- These are my opinions, not necessarily my employers.Article: 19932
On Tue, 11 Jan 2000 08:12:36 GMT, allan.herriman.hates.spam@fujitsu.com.au (Allan Herriman) wrote: >On Mon, 10 Jan 2000 10:40:47 -0500, Matt Billenstein ><mbillens@one.net> wrote: > >>Virtex Temperature Sensing diode pins DXP, DXN >>Has anyone used these or even know how they work? > >Matt, > >Look at the datasheet for the LM84 (NS) or MAX1617 (etc) (Maxim) or >ADM1021 (Analog Devices). Other manufacturers have them, but I can't >remember the part numbers off hand. These parts are designed to >measure processor temperature for commodity motherboards, so they have >an SMB (like I2C) interface. > >http://www.national.com/pf/LM/LM84.html >http://dbserv.maxim-ic.com/pl_list.cfm?filter=ts >http://products.analog.com/products/info.asp?product=ADM1021 Just found another one, the FMS2701 from Fairchild http://www.fairchildsemi.com/pf/FM/FMS2701.html It includes a fan speed control output. Regards, Allan.Article: 19933
As i mentioned in an earlier post, Any of these suggestions should be used only for a random seed for a more conventional and predictable generator. My caution is to be sure that the seed generator is random enough and has enough of a distribution that you won't be getting repeatable seeds if that is what your application calls for. That said, if there is a real-time clock somewhere in the system, it is a time-proven source of unique seeds. You will probably also want to consider a mechanism for manually setting the seed so you can get a repeatable sequence during debug. Hal Murray wrote: > > how about stirring the internal RC osc signal into the innards of a > > pseudorandom shift register, say by xor'ing the RC signal into some midpoint > > of a register clocked by something else. You now have a pseudorandom > > sequence that is executing essentially random state jumps. Faster is better > > here, I think. > > I get suspicious when I see suggestions like that. > > If you are interested in random numbers, I suggest reading > Knuth's book. Yes, it's mostly software, but the introduction > is a great eye-opener. It describes a complicated algorithim that > you can't possibly predict. It should make total garbage. But it > doesn't! > > I think you will be better off using techniques that you can > understand. Then you will know how good they are and/or where > the limits are. > > You also have to understand how your random numbers will be > used. Again, it helps to be able to analyze your random number > generator to see if it fits into your application. > > If you are thinking of using something like an external clock > to make your randomness more random, be sure you aren't just > making things harder to understand. "random state jumps" > aren't random if they happen at predictable times. All that does > is change the output sequence from one pseudo-random pattern to > a different one. > > I think the key parameter is the bandwidth of the noise you can > get. If the second clock comes from a crystal you probably won't > get much noise from it. On the other hand, it may be a simple and > inexpensive to merge in a little more randomness. > > -- > These are my opinions, not necessarily my employers. -- -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: 19934
In a contract FPGA position. Location is Melbourne FL. Need some for a 4-6
month contract. 5 yrs. experience......40-45 hr. If interested and
qualified, please email resume to klyons@tsrc.net.
Thanks
Kevin Lyons
Article: 19935All, I've not seen (or cannot find) an appropriate appnote or reference design for laying down these fine pitch BGA parts (say FG256 for example) There doesn't seem to be a lot of room between BGA solder pads (0.400 millimeters nominal) to route out or drop vias of any substantial size... I can route out two rows around the whole part with very little trouble, but I think I have to dogbone anything further inside the part. How are you folks here doing it? thx m Matt Billenstein http://w3.one.net/~mbillens/ REMOVEmbillens@one.netArticle: 19936
hi, I have problem running a design at the max frequency recommended in the Timing analyse report. the s/w is foundation series 2.1, target is Virtex -4 bg560, the function of the design is image processing The report give a min period of 29.222ns , but when i downed the design into the virtex and clock it at 33.33ns , 30 mhz some of the output image is wrong, ( white dot/pixel can be seen at the resultant image). When i reduce the frequency to.. say 400K hz , the resultant image is Ok. So i deduce that it must be because of timing violation. just like to know, how to you'll solve this ? at 30 mhz, it is already ~10% slower than the reported worst case. but it still didn't work. is this normal, or i should have clock it at ~20% slower then reported, which is 36ns,27.7mhz? next, when the design have timing violation at run time, is there any way to know which path is causing the problem by probing or some measure. or is it alway the path/paths reported by the timing analyzer.? thanks Sheau Pyng Project Officer Center for High Performance Embedded System Nanyang Technological University, School Of Applied Science N4-B3b-06, Nanyang Avenue Singapore 639798 Tel : (65)-790 6967 Fax : (65)-7926559Article: 19937
Are you sure you got all the paths covered with the timing constraints? Run the timing analyzer and confirm you results there. Also, make sure you are meeting timing with the external interfaces. A common place to have problems is in an FPGA to memory interface. The i/o timing isn't covered by a period constraint. Oh Sheau Pyng wrote: > hi, > I have problem running a design at the max frequency recommended in > the Timing analyse report. > the s/w is foundation series 2.1, target is Virtex -4 bg560, the > function of the design is image processing > > The report give a min period of 29.222ns , but when i downed the > design into the virtex and clock it at 33.33ns , 30 mhz > some of the output image is wrong, ( white dot/pixel can be seen at > the resultant image). > > When i reduce the frequency to.. say 400K hz , the resultant image is > Ok. > > So i deduce that it must be because of timing violation. > > just like to know, how to you'll solve this ? > at 30 mhz, it is already ~10% slower than the reported worst case. but > it still didn't work. > is this normal, or i should have clock it at ~20% slower then > reported, which is 36ns,27.7mhz? > > next, when the design have timing violation at run time, is there any > way to know which path is causing the problem by probing or some > measure. or is it alway the path/paths reported by the timing analyzer.? > > thanks > Sheau Pyng > > Project Officer > > Center for High Performance Embedded System > Nanyang Technological University, > School Of Applied Science > N4-B3b-06, Nanyang Avenue > Singapore 639798 > > Tel : (65)-790 6967 > Fax : (65)-7926559 -- -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: 19938
On request of S M E, we have designed a configurable 8-16 bits processor IP, called ProMic, to be best fitted in FPGA. It can be implemented in ACTEL (ProAsic), ALTERA (Flex 1OK and APEX) or XILINX (VIRTEX). ProMic is a fast CPU (more than 30 Millions instructions/s with the today available FPGA). It can be easily programmed in assembly or in C language You can download an evaluation version of the development software tools at this web site: http://www.design-reuse.com/TOOL/tool_demo.html and see how you can easily determine the best configuration of ProMic for your application. Pierre VERNEL CRITT MICROLOR 2 avenue de la foret de Haye F 54516 VANDOEUVRE les NANCY Tel : +33 (0)3 83 59 55 70 Fax: +33 (0)3 83 59 55 73 Email:vernel@ensem.u-nancy.frArticle: 19939
It is obvious that if company A makes a UART chip say, and company B has
a patent on the generic features of a UART, then Company A is liable to
have to pay a licence and/or royalty to company B.
Does anyone know of any case history or legal advice concerning company
C who sells an FPGA containing said UART function? No one in Company B
can point to circuitry in the FPGA that embodies the patented
intellectual property. It is possible, I suppose, that if the patent
includes method claims, then it might be possible to use these against a
soft emulation of the patented invention.
I can see a number of possible outcomes:
1: every company who owns an FPGA that is downloaded with a "UART"
program is liable to pay a licence
2: every company that sells design IP of a "UART" is liable to pay a
licence
3: if an FPGA vendor pays a licence, then any customer can use that
vendor's chips to implement the "UART" function
4: no licence is payable at all.
Any ideas which of these might apply?
Paul
--
Paul Walker Chair of the 1355 Association
www.1355.org
4Links:
Boards, chips, IP and consultancy ... for links
phone/fax
paul@4Links.co.uk P O Box 816, Two Mile Ash +44 1908
http://www.4Links.co.uk Milton Keynes MK8 8NS, UK 566253
Article: 19940I'm sure a major ASIC house such as LSI would be able to help, depending on your Order Value etc. On a (perhaps more sensible level?) I think AMI also may have something similar that would meet your needs: http://www.amis.com/trans/xilinx.html Cheers Stuart On Tue, 18 Jan 2000 11:58:25 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: >Does anybody know which ASIC vendors - if any - have dual-port >independently clocked RAM macros that match the Virtex's Block RAMs ? For Email remove "NOSPAM" from the addressArticle: 19941
On 19 Jan 2000 00:16:14 GMT, murray@pa.dec.com (Hal Murray) wrote: > >> how about stirring the internal RC osc signal into the innards of a >> pseudorandom shift register, say by xor'ing the RC signal into some midpoint >> of a register clocked by something else. You now have a pseudorandom >> sequence that is executing essentially random state jumps. Faster is better >> here, I think. > >I get suspicious when I see suggestions like that. > >If you are interested in random numbers, I suggest reading >Knuth's book. Yes, it's mostly software, but the introduction >is a great eye-opener. It describes a complicated algorithim that >you can't possibly predict. It should make total garbage. But it >doesn't! > >I think you will be better off using techniques that you can >understand. Then you will know how good they are and/or where >the limits are. > >You also have to understand how your random numbers will be >used. Again, it helps to be able to analyze your random number >generator to see if it fits into your application. > >If you are thinking of using something like an external clock >to make your randomness more random, be sure you aren't just >making things harder to understand. "random state jumps" >aren't random if they happen at predictable times. All that does >is change the output sequence from one pseudo-random pattern to >a different one. > >I think the key parameter is the bandwidth of the noise you can >get. If the second clock comes from a crystal you probably won't >get much noise from it. On the other hand, it may be a simple and >inexpensive to merge in a little more randomness. Hal, agreed, a random number generator certainly isn't cryptographically, or even statistically, secure simply because it's confusing to the designer. People have lost wars making that assumption. But as a source of truly random addresses for, say, networking applications, something like this is useful without the hassle of zener noise-diode things and such. Stirring an async clock into a pseudorandom shift register can be a nice way to 'spread out' the available randomness, and viewed as random state jumps in the PRN sequence, is not totally idiotic. JohnArticle: 19942
> It is obvious that if company A makes a UART chip say, and company B has > a patent on the generic features of a UART, then Company A is liable to > have to pay a licence and/or royalty to company B. You can't patent a 'feature' you can only patent a 'method' and possibly 'apparatus' for implementing that 'feature'. Concepts are not patentable. > Does anyone know of any case history or legal advice concerning company > C who sells an FPGA containing said UART function? No one in Company B > can point to circuitry in the FPGA that embodies the patented > intellectual property. Company B would bring suit against company C, and during the 'disclosure' phase of litigation, company C would have to produce the design documents to the expert witness chosen by company B to examine them. Company C would never see the documents. > It is possible, I suppose, that if the patent > includes method claims, then it might be possible to use these against a > soft emulation of the patented invention. Patents HAVE to include method claims, that's what a patent is. Soft emulation (such as software that does the same thing as hardware) more than likely won't infringe, because the 'method' is completely different, as well as the implementation. There is a big todo about the importance of the QCOM and IDC patents for CDMA, since DSPs are so much more powerful, there is no need to do CDMA in dedicated hardware (which is what the patents are), so one can completely get around their patents by using a cheap DSP and some software... > I can see a number of possible outcomes: > > 1: every company who owns an FPGA that is downloaded with a "UART" > program is liable to pay a licence > > 2: every company that sells design IP of a "UART" is liable to pay a > licence > > 3: if an FPGA vendor pays a licence, then any customer can use that > vendor's chips to implement the "UART" function > > 4: no licence is payable at all. > > Any ideas which of these might apply? > Any of those can apply, depending on what the agreement is. No one is the 'rule'. If there is no patent infringement, there is no 'royalty' due. Royalties must be negotiated, and they may not be given by the patent holder. If we're talking about a UART here, I really doubt any patent would be violated, since most everything to do with a UART will have prior art, which would negate the possible patent claims. Realize, just because a patent is issued does not mean it is valid. The only time a patent is valid, is when it is upheld in court, period. The patent examiners (with all due respect) aren't the brightest bulbs on the tree for computer hardware/software. For fishing lure patents, they are the best in the world! Where else could you get paid $60k to talk about fishing lures day in and day out....so, if your patent involves fishing lures, you can be sure, they got it right. Now, for electronics, they patent office isn't going to attract the best there is for $60k, these guys are going to be working for some electronics company drawing 2x the salary the patent office will pay them... Just something to keep in mind about computer hardware/software patents... It's not really clear what you are trying to find out here. If you could tell me a bit more about what it is your concern is, I could possibly try to help... Be aware that copyright is entirely different than patent. If you find a copy of my schematic, and decide to re-enter it, and use it, with no or 'little' change, you are violating my copyright (assume the original was properly marked as such).Article: 19943
I know this isn't REALLY an FPGA question, but there are a LOT of bright people here..so I figured I'd ask. I am looking for an 8k x 32 FIFO (minimum) that I can load up with data of arbitrary length, then free-run it so it just keeps outputting data, looping on the data that is in it, without having to re-load it. Any ideas?Article: 19944
If you are looking for a FIFO device to do that, use the retransmit feature that is present on many FIFOs. You do have to do a reset of the FIFO before you load your data so that the retransmit starts at the right place. If this is to go with an FPGA, then it would be cheaper and easier to use an SRAM with the FPGA and have the FPGA take care of loading then 'looping' on the data in it. Austin Franklin wrote: > I know this isn't REALLY an FPGA question, but there are a LOT of bright > people here..so I figured I'd ask. > > I am looking for an 8k x 32 FIFO (minimum) that I can load up with data of > arbitrary length, then free-run it so it just keeps outputting data, > looping on the data that is in it, without having to re-load it. > > Any ideas? -- -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: 19945
It's almost four days that I'm having some devastating experiences using Quartus 99.10 SP2. It happens that sometimes the fitter goes into an endless loop (showing the same fitting percentage for hours and hours). Sometimes the fitting is completed but the Delay Annotation causes an internal error. I fear I'm only wasting my time: this Quartus release seems to be full of bugs and I'm planning to abandon Altera in favour of Xilinx Virtex. But what about Xilinx place and route tools? Are they so buggy ? Should I expect the same neverending fitting loops using Xilinx tools (Alliance or Foundation) ? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19946
On 19 Jan 2000 22:29:18 GMT, "Austin Franklin" <austin@da33rkroom.com> wrote: >I know this isn't REALLY an FPGA question, but there are a LOT of bright >people here..so I figured I'd ask. > >I am looking for an 8k x 32 FIFO (minimum) that I can load up with data of >arbitrary length, then free-run it so it just keeps outputting data, >looping on the data that is in it, without having to re-load it. > >Any ideas? You might like to try some of the newer dual port ram devices from Cypress or IDT. They have synchronous parts with burst counters. The burst counters can be made to free run over the entire size of the ram. The burst counters can be reset (there's a dedicated pin per port for this), or preset (using another dedicated pin, which causes the counter to be loaded from the address input for that port). You can load the data using the other port (with random access from a microprocessor, for example). They're not cheap though, particularly for the fastest or largest ones (up to 133MHz, 64k x 36, IIRC). They eat power, too. Sounds like an arbitrary waveform or pattern generator? http://www.cypress.com/dualport/index.html http://www.idt.com/products/pages/Multi-Port.html Regards, Allan.Article: 19947
Thanks Ray. I looked at that re-transmit feature, but it isn't really explained well (on the spec I have)...it eludes that it is only the 'current' 'word' that is re-transmitted, not the entire FIFO...but, if you say it works, I'll check into it further... Problem with using SRAM, is I am pinbound at this point...8k is another 14 pins...don't think I can do it...but that would be my first choice....if I had the pins... Ray Andraka <randraka@ids.net> wrote in article <3886400E.FD27C2B9@ids.net>... > If you are looking for a FIFO device to do that, use the retransmit feature > that is present on many FIFOs. You do have to do a reset of the FIFO before > you load your data so that the retransmit starts at the right place. > > If this is to go with an FPGA, then it would be cheaper and easier to use an > SRAM with the FPGA and have the FPGA take care of loading then 'looping' on > the data in it. > > Austin Franklin wrote: > > > I know this isn't REALLY an FPGA question, but there are a LOT of bright > > people here..so I figured I'd ask. > > > > I am looking for an 8k x 32 FIFO (minimum) that I can load up with data of > > arbitrary length, then free-run it so it just keeps outputting data, > > looping on the data that is in it, without having to re-load it. > > > > Any ideas? > > -- > -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: 19948
Thanks for the idea...I'll look into it. > Sounds like an arbitrary waveform or pattern generator? You are right, sir! It is for a pattern generator...Article: 19949
In article <01bf62f0$415d2640$207079c0@drt1>, "Austin Franklin" <austin@darkroom88.com> writes: > Thanks Ray. I looked at that re-transmit feature, but it isn't really > explained well (on the spec I have)...it eludes that it is only the > 'current' 'word' that is re-transmitted, not the entire FIFO...but, if you > say it works, I'll check into it further... I've never used that feature on a FIFO, but the data sheet seems as though it was describing what you would want if you were going to "retransmit" a packet after an Ethernet collision. [A comment about the "current" word may be telling you something about a pipeline stage that you have to flush.] -- 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