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
Hi, Altera EPCS64 is a 64Mbit serial flash memory used for AS configuration in SOIC16 package. The SOIC package is too big (around 10x10mm) for my PCB design. I can't change the configuration system which is AS serial configuration device programmed using download cable. Do you know other serial flash memory which can be used with the ALTERA's programming software and which can be found in a small flat package ? I've asked at Altera and get some banal answers about looking in the datasheet, and changing the AS with other configuration methode (which is more PCB space consumer than AS). thx,Article: 111851
Hello! For a long time my lab purchased the lower-cost ISE Base-X kit,
which was recently discontinued and its functionality was rolled into
WebPack (which is available for free!) Base-X always seemed to contain
support for the two smallest of Xilinx's high-end devices. The latest
WebPack, however, does not contain support for the V5s. Is there a plan
to have V5 support in WebPack in the future?
I know the standard Xilinx line on this is "If you're doing high-end
development, ISE tools are not going to be a big part of your cost" but
in our environment where we have a bunch of students doing development
on prototype boards, the license costs can add up quickly.
Thanks,
...Eric
Article: 111852jonas@mit.edu wrote: > I know the standard Xilinx line on this is "If you're doing high-end > development, ISE tools are not going to be a big part of your cost" but > in our environment where we have a bunch of students doing development > on prototype boards, the license costs can add up quickly. Why not using Altera then? AFAIK the web edition of Quartus supports all Altera FPGAs. The only problem is when you use Linux: For Windows, Quartus is free, but for Linux you have to pay for it, which makes development for me a bit harder at work, because I'm using Linux for developing for an embedded system and in parallel I need a second computer for synthesizing for the FPGA on this system. Would be much better if Xilinx and Altera would provide all development software for free for both platforms, maybe then they would even sell more chips. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 111853
"Frank Buss" <fb@frank-buss.de> wrote in message news:yun4h7muz846.pwvoght3r698.dlg@40tude.net... > jonas@mit.edu wrote: > >> I know the standard Xilinx line on this is "If you're doing high-end >> development, ISE tools are not going to be a big part of your cost" but >> in our environment where we have a bunch of students doing development >> on prototype boards, the license costs can add up quickly. > > Why not using Altera then? AFAIK the web edition of Quartus supports all > Altera FPGAs. > Nope. The web edition only supports the smallest Stratix I & II parts. SlurpArticle: 111854
I use the GUI (NCLaunch) to compile and elaborate and here is what I do... 1) I put the 'glbl.v' file in my simulation directory (same directory that I point NCLaunch to as my 'design directory'). 2) I compile this file along with all my other Verilog files. 3) I select both the glbl and whatever testfixture I am using and elaborate those at the same time. 4) Then you can sim as normal. The above is doing the same as the command line options. I just find it easier and faster. I am lazy though. You could easily create scripts for this if you want to. If you don't use the GUI, then I guess this post doesn't help! But it took me a while to figure this out and I couldn't find the answer here, so maybe it will help others.Article: 111855
I was just wondering what others thought about the 'New 8.X' EDK. Three people in my group at work have used the EDK since 6.1 and we are all a little disappointed with the newest EDK's. It's functionality is the same, but the GUI and interfaces are all apparently totally different. There are things that we got used to using in the older versions that are different here (ex. core version pull-down menus for one). I know that part of the problem is that we are used to the old. But there are things that seem like the software to a step backwards. I feel that the intuitive-ness has gone down. I liked the flow of the old software. Creating the memory mapping was more intuitive in older releases. I liked the port and signal controls in the older as well. So what do other users think? We also ran into some problem with downloading the bit file into our FPGA via the EDK. For some reason, if we rebuild the project and try to download, it doesn't work. Our workaround that we discovered is that if we 'wiggle' the JTAG we can download all we want. And by 'wiggle' I mean using impact to either erase the PROM we have on board or program it (any .mcs file -- it doesn't matter). Keep in mind, we are only trying to DOWNLOAD the bit file into the FPGA. We aren't even messing with the PROM. This never occurred before EDK 8.2 and we have confirmed it's a problem on multiple computers/setups. We haven't tried on any other board except ours.Article: 111856
<ian.peikon@gmail.com> wrote in message news:1163181720.400625.238980@h48g2000cwc.googlegroups.com... > Hi, > > I've been working on an FPGA project for a month or so now and I have > finally finished the code. Before I began I calculated the amount of > BRAM and Distributed Ram that I had available and designed the code > accordingly. However after compilation I get the following results: > Number of Slices: 43734 out of 1200 3644% (*) > Number of Slice Flip Flops: 19047 out of 2400 793% (*) > Number of 4 input LUTs: 27654 out of 2400 1152% (*) > Number of IOs: 58 > Number of bonded IOBs: 53 out of 96 55% > Number of BRAMs: 528 out of 10 5280% (*) > Number of GCLKs: 2 out of 4 50% > I'm curious which Xilinx device and package you're targeting. I didn't do an exhasutive search, but I didn't see any Virtex-II, or Spartan (2, 3, 3E) parts with the resources listed above. RobArticle: 111857
"Slurp" <slip@slap.slop> schrieb im Newsbeitrag news:4555fdd2$0$8737$ed2619ec@ptn-nntp-reader02.plus.net... > > "Frank Buss" <fb@frank-buss.de> wrote in message > news:yun4h7muz846.pwvoght3r698.dlg@40tude.net... >> jonas@mit.edu wrote: >> >>> I know the standard Xilinx line on this is "If you're doing high-end >>> development, ISE tools are not going to be a big part of your cost" but >>> in our environment where we have a bunch of students doing development >>> on prototype boards, the license costs can add up quickly. >> >> Why not using Altera then? AFAIK the web edition of Quartus supports all >> Altera FPGAs. >> > Nope. The web edition only supports the smallest Stratix I & II parts. > > Slurp well altera webedition *DOES* support at least one part of each high end family WebPack does *NOT* support V-5 at all AnttiArticle: 111858
> The only problem is when you use Linux: For Windows, Quartus is free, but
> for Linux you have to pay for it, which makes development for me a bit
> harder at work, because I'm using Linux for developing for an embedded
> system and in parallel I need a second computer for synthesizing for the
> FPGA on this system. Would be much better if Xilinx and Altera would
> provide all development software for free for both platforms, maybe then
> they would even sell more chips.
Yea, I'm in the same boat -- my uClinux dev tools all run under linux,
and right now all the xilinx tools run really well on the same machine.
Plus, we've invested a lot of time and energy working with the xilinx
toolchain and hardware -- the thought of switching is somewhat scary!
...Eric
Article: 111859Paul Leventis wrote: > Hi Frank, > > There's not much in the CAD tool that could be easily sped up on an > FPGA. CAD tools have huge working sets (active memory) and spend a lot > of their time jumping around through that memory. Many key algorithms > are manipulating graphs and this sort of stuff isn't easy to Thats pretty much what I have been saying all along but into the wind though. > parallelize. Spliting it into multiple threads for a CPU is tough > enough -- going massively parallel in an FPGA (or heck, a GPU -- anyone > read up on the G8800?) is much tougher. > Better to solve the Memory Wall problem first before going to multi cores and compounding the problem. > Plus think of the maintenance nightmare... each new alogrithm or tweak > becomes a hardware change! > > - Paul PCs are only blistering fast when given trivial problems such as video coding where lots of grunt work gets done on small data blocks mostly in some raster or linear order. You can see that when you traverse a graph or tree or even a simple linked list by randomly walking an array who's size is plotted from small ranges to huge ranges what happens to the caches. If the problem fits in L1 cache, memory access times are close enough to 1ns that a tiny loop can probably scan memory in a few ns/entry and do some useful work, all the caches work together to make the Memory Wall just vanish. Increase the range from L1 to L2 and the loop time sturts to increase noticeably when little work is done. I bet that for most graph traversals relatively little work is done per hop. Further increases beyond L2 and it falls apart completely, 1ns can become 100ns plus for every access if all nodes are fully randomly allocated over a memory range of 100MB or so. On an older Athlon XP it even reaches 400ns and a newer D805 reaches 130ns, that suggests the OS gets called to fix up the TLB every accesss. (if anybody with a CoreDuo wants to run the test for me let me know). I don't think the OS makes much difference, same thing needs to happen to change the TLBs. Now if the working set were bigger than the DRAM, you could factor in VM page misses too and 1ns becomes a few ms. I have proposed a solution to the Memory Wall but it requires taking a hit elsewhere ie a Thread Wall and it requires multithreading both the processor AND the MMU + Memory system. That allows both processors and memory latency to be pretty well hidden and it requires using RLDRAM with a high issue rate and much reduced latency as a total cache replacement. All of its 8 banks can be used concurrently when used by 40 or so threads. The MMU hashes object references and indexes over the address space and reorders bank access so that they get used in the right order as they complete previous requests. The idea here is that processor elements are cheap and memory access is the real limit and that RLDRAM has about 20x more throughput than regular DRAM. When you consider that the hashing MMU replaces TLBs so that 1.5 RLDRAM cycles gives 1 useful random memory access while a true random DRAM access will involve the OS fixing up TLBs with several hidden DRAM cycles per application access. In the real world I think most apps appear to hide the problem by mixing up linear and random accesses so the drop in performance is far less spectacular, but full time random graph traversal on huge working sets reveals the nasty side of things. So while you can't fix up your PC to effectively get low Memory Wall you could bypass this by moving parts of FPGA/EDA apps into highly threaded code on FPGA cpu cluster designed around such a RLDRAM system. Around 10 Processor Elements running at same clock as RLDRAM clock sharing memory accesses through a common shared MMU can reach upto 1500 integer register Mips and probably sustain half that with usual load, store, branch rates with even access across the whole RLDRAM array. In effect random access is even better now than linear access as it forces all 8 banks to have even access loads. The hit is that the full utilization needs 4 threads per PE so 40 threads sharing the MMU. 800Mips may not seem impressive but I bet a typical PC randomly walking memory performs far worse. Now if this sort of processor design were pushed into full custom ASIC, 300MHz FPGA clocks can become atleast 5x faster and the RLDRAM model can also run 5x faster by adding a smaller upfront SRAM equivalent model. Here the SRAM also relies on n way banking to cover slower cycle times so 8 parallel 2ns cycles look equivalent to 0.25ns cycles with effective 0.33ns average access times due to hash collisions. Each usefull access supports about 5-10 opcodes so the overall throughput scales with frequency again since the interleaving allows many memories to run much slower than the processor MMU clock. Conventional single threaded cpu designs demands all the parts run as fast as possible, clearly an impossible goal for large memory useage. Both Raza and Sun have effectively done this with 1.5GHz threaded processors but I haven't seen the memory side go the same way yet. Ironically all the talk about future 80 way Intel cores coming down the pike is going to make the current Memory Wall problem far worse and it will give you 80 threads to keep busy too. The nice thing about putting some EDA code into FPGA cpus designed for random walk throughput is that the individual PEs can also have special opcodes added to help the EDA app. If you think in terms of conventional MicroBlaze or Nios designs as being used for running FPGA code, then you are just replicating conventional Memory Wall designs at much slower clocks although full cache misses on very fast or very slow cpus to same sort of primary DRAM will have same final limit. I also suspect that if the Memory Wall is finally tackled as suggested, Moore's Law would then allow the EDA host cpu to better track the EDA problem, bigger chip designs can still be handled by processors that actually did scale with frequency but the EDA tool must use atleast 20 threads to get the Memory Wall to level down. Those of us from the ASIC world used to deal with floor planning and P/R times in the week time frame so minutes or hours is still better. While an FPGA hardwired version of EDA is probably not attractive, perhaps just building a database engine to store and search the entire working set useing FPGA to drive RLDRAM banks to guarantee fast probes.might work, perhaps useing the HT bus with an Opteron. regards John Jakson Anyway the paper is still at wotug, google for r16 fpga transputer.Article: 111860
A Serializer/Deserializer (SerDes) can be implemented as a hard silicon block with (relatively) clean PLL-based VCO or it can be implemented in general FPGA log, taking parallel data in to produce serial data (Ser) or taking in serial data and making it parallel (Des). By using the inexpensive FPGAs capable of high LVDS I/O rates, you can get most of what you need pretty readily without resorting to the hard SerDes block which - while capable at the slow 622 Mb/s rate (in the SerDes realm it's slow) they are more geared toward STM-16 style rates. You confuse me with the 933.12 MHz clock need since you're dealing with STM-4 rates as the basis. If you have full STM data plus 50% overhead then I'd suggest having two channels plus clock rather than one channel plus clock would be prudent. You are correct in that this scheme - fabric-based SerDes functionality - would require a separate clock for each independent timing source. Some hard SerDes blocks in the more expensive (higher functionality) FPGAs can do clock recovery but many of those require 8b/10b encoding which is *fine* if you're dealing with FPGA based distribution where you have complete control over both ends. I still can't stress enough how any timing that passes through the FPGAs can be used for timing the data to the internal logic but *cannot* be used as a raw, clean timebase for the STM transmitters. You might find a Xilinx App Note of interest, though the implementation is not well suited to the inexperienced FPGA designer. Dealing with high speed chip-to-chip data transfer, the following App Note can deliver many parallel channels of STM-4 class speed. http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf You might even find how to get around the one clock per connection requirement. I haven't read through the app note thoroughly but I found it after I was mostly done with my own high speed deserializer. The techniques in the app note may provide all the performance you need. Arash wrote: > Hello and thanks for your cooperation. > Sorry, since I copied this script from another place, during the copy, > the last question was not pasted correctly. Anyhow, my two questions > were as follows: > > 1- As I have seen in different vendors pages, most of the SERDES > devices are placed after a protocol device. For transmitting SDH > telecombus data is it necessary to implement a protocol on it or not. > (Why protocol specification is required?). > 2- Has anyone seen any SERDES chip which supports the mentioned rates > (19.44 > MHz and 77.76MHz) on its parallel side or not? > > John_H wrote: >> Since STM4 is only 622 Mb/s and you're posting on the FPGA board, you can >> apply a SerDes from just about any FPGA to get to your rate Many families >> will also support 622 Mb/s in the standard I/Os. The STM-4 rate is a target >> for most FPGA vendors so they'll shoot at this as an achievable maximum on >> standard I/O and a minimum on the SerDes as well. >> > First of all, SERDES is not available in any FPGA, and for example in > Xilinx FPGA's, it is available in VIRTEX-II pro and the VIRTEX-4 and > VIRTEX-5 familes. do you know any low price small FPGA which supports > the SERDES feature as we want. (In our current design the telecombuses > from the tributary cards are directly connected from the tributary > cards to the FPGA on the OIU card). > Meanwhile, if we don't want to have SERDES, and just use the ordinary > I/O's for communication, we would need a (233.28MHz=19.44Mhz*12) 233.28 > MHz clock in each of the E1 tributary cards and a 933.12 MHz clock on > the data card to transmit the 12-bit telecombuses serially. Meanwhile > we should also transmit the 233.28 MHz and 933.12MHz clock on the > backplane. Am I right? have you any other idea about this? > >> The SerDes are often used after the protocol layer but isn't needed in an >> application with protocol. The FPGAs have this functionality as a more >> generic function than you might perceive. >> >> Two cautions for your application: >> >> First, the clocks must be supplies separately for your links; the FPGA logic >> doesn't deal well with plesiochronous signals alone though some SerDes >> blocks might support some form of clock recovery. If you have the local >> clock available and can communicate that clock with the 622 Mb/s data, you >> should be in good shape. >> >> Second, these signals can *not* be used for timing. The jitter requirements >> for the SDH signals are sincerely more strict that what you should expect >> from the FPGAs. As with most SDH designs, you should only introduce signals >> onto the line that are within the ITU-T jitter limits. >> > They won't surely be used for timing. >> As long as all your data shuffling is internal to your system and you're >> retimed for all your transmitters with the appropriate low-jitter circuitry, >> today's FPGAs can really carry you well. >> > But we should be sure that neither of theses 12 bits are shuffled. > Because the SDH chip needs these 12 signals in its correct timing > position. >> Oh - and did you have two questions? >> >> - John_H >> >> >> "Arash" <arash.majd@gmail.com> wrote in message >> news:1163175421.380944.121850@h48g2000cwc.googlegroups.com... >>> Hello >>> I have got a problem in SERDES chip selection that I would be grateful >>> if someone helps me in this regard. First, I explain the system that we >>> have. We want to design an STM-4 SDH system which has 5 tributary >>> cards and 1 optical STM-4 line card.The tributary cards are of two >>> types : E1 card and data card. The E1 tributary card which contains an >>> SDH E1 mapper, has a 12-pin telecombus in 19.44 MHz rate in each of >>> its transmit and receive directions (each card has 24 pins in >>> backplane). but the Data tributary card which contains an EoS device on >>> itself, has a 12-pin telecombus in 77.76MHz rate in each of the >>> transmit and receive directions.The pslot of the optical line card is >>> fixed but each of the tributary cards can sit in any position of the 5 >>> tributary slots. to reduce the number of the pins on the backplane we >>> want to serialize the telecombuses between the optical line card and >>> the tributary cards. Since we do not know which of the tributary cards >>> is inserted in in each slot we should select a SERDES which can >>> serialize the data from both of the rates of 19.44 and 77.76 MHz (But >>> during my searches in different vendors I haven't been able to find >>> such a chip). I have got 2 questions. >>> 1- As I have seen in different vendors pages, most of the SERDES >>> devices are placed after a protocol device. for transmitting SDH >>> >Article: 111861
jonas@mit.edu wrote: > Hello! For a long time my lab purchased the lower-cost ISE Base-X kit, > which was recently discontinued and its functionality was rolled into > WebPack (which is available for free!) Base-X always seemed to contain > support for the two smallest of Xilinx's high-end devices. The latest > WebPack, however, does not contain support for the V5s. Is there a plan > to have V5 support in WebPack in the future? > > I know the standard Xilinx line on this is "If you're doing high-end > development, ISE tools are not going to be a big part of your cost" but > in our environment where we have a bunch of students doing development > on prototype boards, the license costs can add up quickly. > > Thanks, > ...Eric If you're a university environment, contact Xilinx about their University Program. While you might not get hotline support, you can get significantly greater tool access without paying full commercial license costs. The FPGA vendors *are* interested in getting new FPGA designers into the field with solid tool experience. Preferably their tools.Article: 111862
Chipscope is great, but is it really non-intrusive? In my experience, not completely. Just sayin. Great tool! I used to pull debug signals out to test pins. Now that is EXTREMELY intrusive and things can fall apart quickly. But I was also a lot dumber back then. Now I am just sort of dumb. Haven't tried the bus analysis cores.Article: 111863
Thanks for your answer. I am just reading the Application note to find out if it can help me or not. John_H wrote: > A Serializer/Deserializer (SerDes) can be implemented as a hard silicon > block with (relatively) clean PLL-based VCO or it can be implemented in > general FPGA log, taking parallel data in to produce serial data (Ser) > or taking in serial data and making it parallel (Des). By using the > inexpensive FPGAs capable of high LVDS I/O rates, you can get most of > what you need pretty readily without resorting to the hard SerDes block > which - while capable at the slow 622 Mb/s rate (in the SerDes realm > it's slow) they are more geared toward STM-16 style rates. > > You confuse me with the 933.12 MHz clock need since you're dealing with > STM-4 rates as the basis. If you have full STM data plus 50% overhead > then I'd suggest having two channels plus clock rather than one channel > plus clock would be prudent. > In every parallel SDH telecombus, there are at least 4 other signals apart from the 8 data bits which accompany the data signals to show the different specific byte places in the frame. (Like the J1 pulse). For example in an STM-4 system, there is a 77.76 MHz data bus accompanied with one parity , one pin Clock,one C1J1V1 pin and one SPE pin and hence the telecombus would be a 12 pin bus. > You are correct in that this scheme - fabric-based SerDes functionality > - would require a separate clock for each independent timing source. > Some hard SerDes blocks in the more expensive (higher functionality) > FPGAs can do clock recovery but many of those require 8b/10b encoding > which is *fine* if you're dealing with FPGA based distribution where you > have complete control over both ends. > > I still can't stress enough how any timing that passes through the FPGAs > can be used for timing the data to the internal logic but *cannot* be > used as a raw, clean timebase for the STM transmitters. > > You might find a Xilinx App Note of interest, though the implementation > is not well suited to the inexperienced FPGA designer. Dealing with > high speed chip-to-chip data transfer, the following App Note can > deliver many parallel channels of STM-4 class speed. > > http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf > > You might even find how to get around the one clock per connection > requirement. I haven't read through the app note thoroughly but I found > it after I was mostly done with my own high speed deserializer. The > techniques in the app note may provide all the performance you need. > > Arash wrote: > > Hello and thanks for your cooperation. > > Sorry, since I copied this script from another place, during the copy, > > the last question was not pasted correctly. Anyhow, my two questions > > were as follows: > > > > 1- As I have seen in different vendors pages, most of the SERDES > > devices are placed after a protocol device. For transmitting SDH > > telecombus data is it necessary to implement a protocol on it or not. > > (Why protocol specification is required?). > > 2- Has anyone seen any SERDES chip which supports the mentioned rates > > (19.44 > > MHz and 77.76MHz) on its parallel side or not? > > > > John_H wrote: > >> Since STM4 is only 622 Mb/s and you're posting on the FPGA board, you can > >> apply a SerDes from just about any FPGA to get to your rate Many families > >> will also support 622 Mb/s in the standard I/Os. The STM-4 rate is a target > >> for most FPGA vendors so they'll shoot at this as an achievable maximum on > >> standard I/O and a minimum on the SerDes as well. > >> > > First of all, SERDES is not available in any FPGA, and for example in > > Xilinx FPGA's, it is available in VIRTEX-II pro and the VIRTEX-4 and > > VIRTEX-5 familes. do you know any low price small FPGA which supports > > the SERDES feature as we want. (In our current design the telecombuses > > from the tributary cards are directly connected from the tributary > > cards to the FPGA on the OIU card). > > Meanwhile, if we don't want to have SERDES, and just use the ordinary > > I/O's for communication, we would need a (233.28MHz=19.44Mhz*12) 233.28 > > MHz clock in each of the E1 tributary cards and a 933.12 MHz clock on > > the data card to transmit the 12-bit telecombuses serially. Meanwhile > > we should also transmit the 233.28 MHz and 933.12MHz clock on the > > backplane. Am I right? have you any other idea about this? > > > >> The SerDes are often used after the protocol layer but isn't needed in an > >> application with protocol. The FPGAs have this functionality as a more > >> generic function than you might perceive. > >> > >> Two cautions for your application: > >> > >> First, the clocks must be supplies separately for your links; the FPGA logic > >> doesn't deal well with plesiochronous signals alone though some SerDes > >> blocks might support some form of clock recovery. If you have the local > >> clock available and can communicate that clock with the 622 Mb/s data, you > >> should be in good shape. > >> > >> Second, these signals can *not* be used for timing. The jitter requirements > >> for the SDH signals are sincerely more strict that what you should expect > >> from the FPGAs. As with most SDH designs, you should only introduce signals > >> onto the line that are within the ITU-T jitter limits. > >> > > They won't surely be used for timing. > >> As long as all your data shuffling is internal to your system and you're > >> retimed for all your transmitters with the appropriate low-jitter circuitry, > >> today's FPGAs can really carry you well. > >> > > But we should be sure that neither of theses 12 bits are shuffled. > > Because the SDH chip needs these 12 signals in its correct timing > > position. > >> Oh - and did you have two questions? > >> > >> - John_H > >> > >> > >> "Arash" <arash.majd@gmail.com> wrote in message > >> news:1163175421.380944.121850@h48g2000cwc.googlegroups.com... > >>> Hello > >>> I have got a problem in SERDES chip selection that I would be grateful > >>> if someone helps me in this regard. First, I explain the system that we > >>> have. We want to design an STM-4 SDH system which has 5 tributary > >>> cards and 1 optical STM-4 line card.The tributary cards are of two > >>> types : E1 card and data card. The E1 tributary card which contains an > >>> SDH E1 mapper, has a 12-pin telecombus in 19.44 MHz rate in each of > >>> its transmit and receive directions (each card has 24 pins in > >>> backplane). but the Data tributary card which contains an EoS device on > >>> itself, has a 12-pin telecombus in 77.76MHz rate in each of the > >>> transmit and receive directions.The pslot of the optical line card is > >>> fixed but each of the tributary cards can sit in any position of the 5 > >>> tributary slots. to reduce the number of the pins on the backplane we > >>> want to serialize the telecombuses between the optical line card and > >>> the tributary cards. Since we do not know which of the tributary cards > >>> is inserted in in each slot we should select a SERDES which can > >>> serialize the data from both of the rates of 19.44 and 77.76 MHz (But > >>> during my searches in different vendors I haven't been able to find > >>> such a chip). I have got 2 questions. > >>> 1- As I have seen in different vendors pages, most of the SERDES > >>> devices are placed after a protocol device. for transmitting SDH > >>> > >Article: 111864
unknown@aol.com wrote: > Personnaly, I'm also waiting for Cyclone III. Looks promising. > By the way, I've been told that MAX III is also on the way ... and that NIOS II will be > supported :o) Yes, but with how much left over ?! :) IIRC Xilinx have a MB Coolrunner demo, that surely no one has ever deployed in the field - but I did see it as a good tools-flow tester. -jgArticle: 111865
Jim Granville schrieb: > unknown@aol.com wrote: > > > Personnaly, I'm also waiting for Cyclone III. Looks promising. > > By the way, I've been told that MAX III is also on the way ... and that NIOS II will be > > supported :o) > > Yes, but with how much left over ?! :) > > IIRC Xilinx have a MB Coolrunner demo, that surely no one has ever > deployed in the field - but I did see it as a good tools-flow tester. > > -jg IIRC wrong. there is special PLD version of the PicoPlaze but MB never fits any xilinx PLD AnttiArticle: 111866
I'm using the Spartan 3. RobJ wrote: > <ian.peikon@gmail.com> wrote in message > news:1163181720.400625.238980@h48g2000cwc.googlegroups.com... > > Hi, > > > > I've been working on an FPGA project for a month or so now and I have > > finally finished the code. Before I began I calculated the amount of > > BRAM and Distributed Ram that I had available and designed the code > > accordingly. However after compilation I get the following results: > > Number of Slices: 43734 out of 1200 3644% (*) > > Number of Slice Flip Flops: 19047 out of 2400 793% (*) > > Number of 4 input LUTs: 27654 out of 2400 1152% (*) > > Number of IOs: 58 > > Number of bonded IOBs: 53 out of 96 55% > > Number of BRAMs: 528 out of 10 5280% (*) > > Number of GCLKs: 2 out of 4 50% > > > > I'm curious which Xilinx device and package you're targeting. I didn't do an > exhasutive search, but I didn't see any Virtex-II, or Spartan (2, 3, 3E) > parts with the resources listed above. > > RobArticle: 111867
Sorry, I assumed that you used the primitives to instantiate the BRAM or wrote it so the synthesis engine would infer it (how I like to do it). I was guessing that you had other heavy weight cores that weren't just instantiating built-in primitives. An example would be a FIFO. ---Matthew Hicks <ian.peikon@gmail.com> wrote in message news:1163231653.549534.187530@k70g2000cwa.googlegroups.com... > Yes, I am using IP cores to generate the blockrams, but I only > instantiate 5 of them at 8x16 (hardly the 520 that ISE claims). > Matthew Hicks wrote: >> To do much useful in 500 lines of code and have that resource utilization >> as >> the output, my guess is that you are using a few IP cores which take up >> those resources. >> >> >> ---Matthew Hicks >> >> >> <ian.peikon@gmail.com> wrote in message >> news:1163181720.400625.238980@h48g2000cwc.googlegroups.com... >> > Hi, >> > >> > I've been working on an FPGA project for a month or so now and I have >> > finally finished the code. Before I began I calculated the amount of >> > BRAM and Distributed Ram that I had available and designed the code >> > accordingly. However after compilation I get the following results: >> > Number of Slices: 43734 out of 1200 3644% (*) >> > Number of Slice Flip Flops: 19047 out of 2400 793% (*) >> > Number of 4 input LUTs: 27654 out of 2400 1152% (*) >> > Number of IOs: 58 >> > Number of bonded IOBs: 53 out of 96 55% >> > Number of BRAMs: 528 out of 10 5280% (*) >> > Number of GCLKs: 2 out of 4 50% >> > >> > I don't really see how any of this is possible. I instantiated 5 >> > BRAM's. Where does it come up with 528? Additionally where do the >> > flipflops, slices, and LUT's come from? My code is only ~500 lines, I >> > don't even know how I coded for this much logic?!!! >> > >> > PLEASE HELP!! >> > >Article: 111868
Hi, I am new on FPGA. I am planning to buy a spartan3e starter kit. But I don't have idea if it has enough resource for my application. My application may need a lot of memory. The on board memory of spartan3e such as distributed RAM and block RAM may not be enough. So my question is can I use DDR SDRAM as an additional memory to save the coefficients when block RAM is not enough? If not, then what can it be used for? What is the difference between DDR SDRAM and block RAM? Is DDR SDRAM much slower than block RAM?Article: 111869
I am trying to write code for a SPI circuit (in VHDL) for the Altera Cyclone II FPGA. I think I understand the implementation of essentially what amounts to a shift register. However, what is a good way to deal with the serial clock. The FPGA will act as a master interfacing with a slave A/D converter that supports SPI interface. Thus, the FPGA will need to generate the SPI clock. The FPGA will contain a simple processor implementation. I think the processor clock can be used to derive the SPI clock, but would it better to provide an independent clock for the SPI? If so, what is a good way to do this? I am not much experienced in FPGA design, so any help or references/links would be greatly appreciated. Thanks!Article: 111870
Hi, After installing EDK 8.1i and update to SP 2, I meet this error when run the EDK: error: general error in xps-sdk launch. could not set cygwin path Could anyone tell me what is this error and how to fix it? Thank you so much, Thang NguyenArticle: 111871
fath wrote: > So my question is can I use DDR SDRAM as an additional memory to save > the coefficients when block RAM is not enough? If not, then what can it > be used for? What is the difference between DDR SDRAM and block RAM? Is > DDR SDRAM much slower than block RAM? The Spartan3E starter kit has 512 Mbit (64 Mbyte) DDR SDRAM. You use the reference implementation for accessing it: http://www.xilinx.com/support/software/memory/protected/index.htm (you need to register first for the memory section of the Xilinx site, it's free, then you can download "Spartan-3E DDR Reference Design for the Spartan 3E Starter Kit"). The only drawback is, that this reference design needs an external 133 MHz oscillator. I've tried to generate the clock from the 50 MHz on-board oscillator with a DCM, but the RAM access was unreliable with the DCM clock, I don't know why. So you have this nice 64 Mbyte RAM, but looks like currently there is no free implementation for accessing it out of the box, without buying and building extra parts. Block RAM is integrated on the FPGA and is faster: You can clock it with 230 MHz with speed grade -4 devices, which is on the starter kit. And you don't need complicated I/O controller for using it, like with the DDR SDRAM, which is an external chip. For the starter kit FPGA version you have 20 block RAMs, each with 18,432 bits, so you'll have about 46 Kbyte. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 111872
firebird =EB=FA=E1: > I am trying to write code for a SPI circuit (in VHDL) for the Altera > Cyclone II FPGA. I think I understand the implementation of > essentially what amounts to a shift register. However, what is a good > way to deal with the serial clock. The FPGA will act as a master > interfacing with a slave A/D converter that supports SPI interface. > Thus, the FPGA will need to generate the SPI clock. The FPGA will > contain a simple processor implementation. I think the processor clock > can be used to derive the SPI clock, but would it better to provide an > independent clock for the SPI? If so, what is a good way to do this? > I am not much experienced in FPGA design, so any help or > references/links would be greatly appreciated. > You can easily generate the SPI clock by deriving it from your main CPU clock, there's no problem with this. Note, however, that you won't be able to have a SPI clock faster than Fclk / 2 where Fclk is your CPU clock. This shouldn't be a problem, as in 99% of the cases SPI communication is slower than processor speed.Article: 111873
Is there a dedicated power-on reset function in Verilog? What I want to achieve is that my own reset functionality will be executed when the FPGA (Xilinx Spartan3/400) undergoes power-on reset. Maybe power-on reset is available as a Xilix core, but I haven't been able to find anything like that. I was hoping to avoid external POR circuitry. Thanks, Borge P.S. Cross-posted to comp.lang.verilogArticle: 111874
John, I did that, but I can't set partitions on the lower-level edf because ISE do not show it in the process window. Why I wanted to do this is because MAP takes 3 hours, and I want to use partitions to speed up the implementation time. According to Xilinx this is the new flow, as compared to the old -gf guide file. It seems that this flow only works for top-level hdl, not edf. John_H wrote: > Try specifying only the top level edif file and include a macro search > path for the translate stage to allow the tool to find the other edifs. > This is how the .ngo files are included for some Xilinx cores; perhaps > it's identical with the edif-only flow.
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