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
> > If this is NOT recommended, then would 2 two bit counters (one with an > > inverted clock) and a 4 bit adder be the best solution? > > That's almost certainly not the 'best' solution. A better solution is to use > a DCM to double the frequency. At 10MHz input frequency, you'll need to use > its CLKFX output. > > > I'd like to keep my clock at 10MHz. > > No you wouldn't. You'd like to keep your logic clock _enabled_ at 10MHz, but > clocked by your newly DCMed 20MHz clock. > > HTH., Syms. > > p.s. Designing with schematics? How quaint! ;-) I will learn Verilog or VHDL soon! : ) I promise! I spent a few months pouring over the Homebrewcpu.com schematics and now find it easy to visualize what I want to do. : )Article: 132526
"austin" <austin@xilinx.com> wrote in message news:futloc$6jf3@cnn.xsj.xilinx.com... > Keyboard? Computer? Morse? > > Yup, hams have made it to the 21st century. Most hams use an ascii > keyboard to Morse code generator, so I can type as I am typing now, and > send the code (without mistakes). .... And to bring it back on topic, FPGA use in ham specific software defined radio (SDR) is gaining ground and momentum. There's already evidence of that here on this group. Mike. N9XIArticle: 132527
On May 7, 7:59 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Do you have a link to a Compilable File ? (or set of files)
Here's one way to hook up the processes:
http://mysite.verizon.net/miketreseler/shaft_encoder.vhd
http://mysite.verizon.net/miketreseler/shaft_encoder.pdf
-- Mike Treseler
Article: 132528MikeWhy wrote: > "austin" <austin@xilinx.com> wrote in message > news:futloc$6jf3@cnn.xsj.xilinx.com... > >> Keyboard? Computer? Morse? >> >> Yup, hams have made it to the 21st century. Most hams use an ascii >> keyboard to Morse code generator, so I can type as I am typing now, and >> send the code (without mistakes). > > > .... > > And to bring it back on topic, FPGA use in ham specific software defined > radio (SDR) is gaining ground and momentum. There's already evidence of > that here on this group. > > Mike. > N9XI > Well, does this http://www.andraka.com/shortwave.htm demo project count? I did it as a demo back in early 2003. It worked surprisingly well considering there is no analog front end.Article: 132529
"Grant Stockly" <grant@stockly.com> wrote in message news:9e47c9b5-5269-46ac-b640-1d85a53da66b@y22g2000prd.googlegroups.com... >> p.s. Designing with schematics? How quaint! ;-) > > I will learn Verilog or VHDL soon! : ) I promise! > > I spent a few months pouring over the Homebrewcpu.com schematics and > now find it easy to visualize what I want to do. : ) Hi Grant, :-) I tell you what, if more people adopted your learning approach, there would be fewer folks on comp.arch.fpga struggling to understand why their 'System C' code works in ModelSIM but doesn't work in their Spartan2e. Simulation aside, HDLs are merely great shortcuts for implementing the hardware that the designer has visualised. For sure, I still 'see' schematics in my head when I write my VHDL. Going back to your original post, I'd recommend to anyone starting out designing FPGAs to do more reading about FPGA clocking. If you can meet the timing, the rest is junior engineering! Cheers, Syms.Article: 132530
On May 29, 8:58 am, Peter Alfke <pe...@xilinx.com> wrote: > On May 29, 1:23 am, Grant Stockly <gr...@stockly.com> wrote: > > > I have a 10MHz clock but needed a 20MHz clock speed. I used two > > asynchronous clear flip flops with a series of buffers to add delay to > > the signal. > > > Is this a bad practice? Will it fail with time or temperature? It > > works fine on a PCB, but I am concerned! It does exactly what I want, > > increment the counter on both rising and falling edges. > > >http://www.stockly.com/images4/080529-Clock_Doubler.jpg > > > Above is a link to a picture the Xilinx schematic. > > > Thanks > > > Grant > > Grant, years ago I published a reliable clock doubler circuit, part of > the "six easy pieces" that seem to be lost. > In words: > Run your 10 MHz clock through a 2-input XOR. > Generate a toggling flip-flop by feeding Q back through an inverting > LUT to the D input. > Route the signal driving D also to the second XOR input. > Use the XOR output to clock the flip-flop, and also use it as your 20 > MHz clock. > > Disadvantage: If your 10 MHz doesn't have 50/50 duty cycle, your 20 > MHz will have frequency modulation. > And the High (or Low depending on XOR or XNOR) time of your 20 MHz > clock will be short but you can lengthen it by adding delay to the Q- > to-D path. Anyhow, it's self-adaptive to the device speed. Use this > trick only when no PLL or DLL is available. > Peter Alfke I found something... http://www.pldworld.com/_xilinx/html/tip/sixeasypieces.htm Firefox doesn't know what to do with an htm file, Internet Explorer wants to install language packs for the English document...but will at least show it to you in English! :) Save it before its gone! :) GrantArticle: 132531
"Eric Smith" <eric@brouhaha.com> wrote in message news:m3d4n5aqp0.fsf@donnybrook.brouhaha.com... > Peter Alfke wrote: >> Grant, years ago I published a reliable clock doubler circuit, part of >> the "six easy pieces" that seem to be lost. > > I repeat my request that the Xilinx marketing and/or web people put all > the old stuff that they unceremoniously removed back into an archive > section of the web or FTP site. > > The "six easy pieces" article is exactly the sort of thing that I was > worried would be lost. :-( > > Just because application notes and white papers are old does NOT mean > that they aren't of any use to Xilinx customers. > > Eric Hey Eric, Yeah, yeah, yeah. Sod that. We're still waiting for the FPGA 'Six Not So Easy Pieces'. Syms. :-)Article: 132532
"Grant Stockly" <grant@stockly.com> wrote in message news:0370016c-1f93-4cb5-ba0a-3ce58b804b3f@q27g2000prf.googlegroups.com... > > I found something... > > http://www.pldworld.com/_xilinx/html/tip/sixeasypieces.htm > No pictures for me. :-(Article: 132533
In article <3s4t34drli8a9a2lboekhle33k22vekchn@4ax.com>, brian_drummond@btconnect.com says... > On Wed, 28 May 2008 19:45:53 -0400, krw <krw@att.bizzzzzzzzzz> wrote: > > >In article <OqSdnacY_bKfqqHVnZ2dnUVZ_tvinZ2d@lmi.net>, > >rgaddi@technologyhighland.com says... > >> krw wrote: > >> > >> Any reason to not just infer the comparator? VHDL generics make this > >> sort of thing a breeze. > > > >Two things... First, I want to walk before running. I also need to > >manually instantiate BRAMs and it would be nice to ditch the GUI > >altogether. It would make managing mu libraries through various > >core releases much simpler. > > > >Perhaps it's no longer true, but I found that the LogicCore devices > >were better optimized than the ones that were inferred from HDL. > > IMO it is good practice to infer first, while bearing this statement in > mind. Then you have a portable design which may be largely good enough; > you only need to pay attention to instantiation where the inferred > design fails size or timing (which does still happen sometimes) Perhaps, but I never know what will be asked next (portability will not). I'd like to have as robust of a design as possible out of the box, since I won't be around to pick up the pieces. > Sounds as if the comparators are good enough now. The comparators are good enough and I think I know how to make them faster, if need be. This doesn't do the BRAMs any good though. They're still going to be a PITA. -- KeithArticle: 132534
"Ray Andraka" <ray@andraka.com> wrote in message news:3RG%j.77$pa2.9@newsfe21.lga... > MikeWhy wrote: >> "austin" <austin@xilinx.com> wrote in message >> news:futloc$6jf3@cnn.xsj.xilinx.com... >> >>> Keyboard? Computer? Morse? >>> >>> Yup, hams have made it to the 21st century. Most hams use an ascii >>> keyboard to Morse code generator, so I can type as I am typing now, and >>> send the code (without mistakes). >> >> >> .... >> >> And to bring it back on topic, FPGA use in ham specific software defined >> radio (SDR) is gaining ground and momentum. There's already evidence of >> that here on this group. >> >> Mike. >> N9XI >> > > Well, does this http://www.andraka.com/shortwave.htm demo project count? I > did it as a demo back in early 2003. It worked surprisingly well > considering there is no analog front end. Whoa. What's really impressive is there looks to be room left on that -100 device for a HT and PSK decoder. Or is that block RAM showing in the FloorPlanner?Article: 132535
Symon schrieb: > "Grant Stockly" <grant@stockly.com> wrote in message > news:0370016c-1f93-4cb5-ba0a-3ce58b804b3f@q27g2000prf.googlegroups.com... >> I found something... >> >> http://www.pldworld.com/_xilinx/html/tip/sixeasypieces.htm >> > No pictures for me. :-( > > Hi Simon, You need to download the pictures separately and store them in the same directory as the html code: http://www.pldworld.com/_xilinx/html/tip/6easy_0.gif http://www.pldworld.com/_xilinx/html/tip/6easy_1.gif http://www.pldworld.com/_xilinx/html/tip/6easy_2.gif http://www.pldworld.com/_xilinx/html/tip/6easy_3.gif http://www.pldworld.com/_xilinx/html/tip/6easy_4.gif http://www.pldworld.com/_xilinx/html/tip/6easy_5.gif Don't worry about the background and logo crap. Have a nice synthesis EilertArticle: 132536
Hi Vijayant, every "rule of thumb" you are trying to use will give you a misleading result. Even if you just want a maximum value. The only way to get a nearly accurate number is to synthesize your design with an asic synthesis tool using the desired technology library. You may use a default synthesis at first, to get an idea of the size and gate count. These results may vary depending on your design goals. If you want to increase speed your design may become larger. If speed is negotiable the design may become smaller with some area optimization constraints. However, the result of this synthesis will be an area value (most likely in square micro meters) because the used gates (and flipflops) heavily vary in size and transistor count. Unless you are using a sea of gates technology that has only nand2-elements. To give you an idea think about this: If you have a simple 4to1 mux, this may be synthesized with a single mux4 cell in some standard cell technologies. With a sea of gates technology you need a bunch of nand2's for this function, plus some routing resources. So, how would you express the number of gates in these two cases? The mux4 is just the solution with the minimum number of cells. depending on your constraints the result might be any correct combination of simpler gates. Also, the gate count, however calculated is not relevant for production. Only the area tells you how many chips can be fabricated on a single waver. And the area changes with the used technology of course. So 1000 gates in a 130nm technology yield less chips per waver than 2000 gates in a 45nm technology. (rough estimation, just to give you an idea) So forget gate counts if you want to compare technologies. Only use of gate counts is if you want to compare designs using the same technology. And I mean the very same technology! (Just take a look at some of the fruitless gate count discussions about Brand-A and Brand-X FPGAs) Have a nice synthesis Eilert vijayant.rutgers@gmail.com schrieb: > I have a design on FPGA that is ready. However, we need to have some > mapping from fpga design to asic. I know that this will not be > accurate. But accuracy is not our concern right now. We just need > upper bound. Also, we are also looking for some IP Core for ASIC so > that we can rough estimate. > > Regards, > Vijayant > > > > On May 24, 5:47 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> Mike Lewis wrote: >> >> (snip) >> >>>> The traditional method for ASIC is to divide the number >>>> of transistors by the number of transistors in a 2 input >>>> NAND gate. For CMOS, that is four. >> (snip) >> >>> What is your method for determining how many transistors are in the design? >>> My synthesis tools only give me area. >> Last I knew, they gave transistors, but that was some time ago. >> >> For FPGA it is much harder to give a reliable count, and >> you are asking in an FPGA newsgroup. >> >> If it gives gate counts different types of gates and with a >> little guessing on transistors/gate. Is this for standard >> cell, sea of gates, or something else? I thought I used to >> have pretty detailed information on the standard cell libraries, >> including transistors for each library element. >> >> -- glen >Article: 132537
Hi, In my transciever design I am using ramb16_s18_s36 blocks for both receiver and transmitter. In the synthesis report ISE says something about these rams that some pins are unconnected etc. but then it goes on as ramb16_s18_s36_1 and ramb16_s18_s36_2 for the receiver and the transmitter rams. When I pass to mapping an error comes out informing that ramb16_s18_s36_1 and ramb16_s18_s36_2 are unknown to virtex4. I didn't manage the problem so I changed one of the rams to s18_s18. Does anyone know what is the reason for this? I will appreciate for any help and advice. Regards, --enesArticle: 132538
Kolja Sulimma wrote: > On 29 Mai, 15:55, David Brown <da...@westcontrol.removethisbit.com> > wrote: >> Kolja Sulimma wrote: >>> On 29 Mai, 07:59, Jim Granville <no.s...@designtools.maps.co.nz> >>> wrote: >>>> rickman wrote: >>>> <snip> >>>>> So, are coarse grained architectures the way of FPGA... opps FPxA >>>>> devices in the near future? Will the lowly LUT and FF be pushed into >>>>> the dark corners of the die in coming years? I think it is not a >>>>> matter of if, just a matter of when and I think the when is soon! >>>> The main drive seems to be MHz, as hard IP is always faster than >>>> Soft Logic. >>> Special purpose hardware is allways faster than general purpose >>> hardware, except in the general case ;-) >>> Coarses granularity makes the implementation of what you are building >>> a lot more efficient, but at the same time it is less likely to match >>> the desires of the designer. >>> Take the DSP block as an example (lets forget the multiplier for now, >>> as this uses an additional advantage: The existence of very clever >>> hardware structures for multipliers) >>> The muxes and adders use a lot less configuration bits and low level >>> muxes as always 18 to 48 elements are configured to implement the same >>> functions, and the data lines always run in parallel, can't be >>> permuted as they could be in the FPGA fabric. This is a huge gain for >>> a 48+18 bit accumulator. >>> But, if you need 49 bits you lose a factor of two immediately. (The >>> fabric implementation grows only by a 2%, the DSP48 implementation by >>> 100%) >>> André DeHon analyzed this in in a chapter of his PhD thesis many years >>> ago: >>> http://www.seas.upenn.edu/~andre/abstracts/dehon_phd.html >>> There are graphs showing the efficiency as a function of application >>> word length and hardware granularity. >>> It should be noted that in FPGAs both delay and area are dominated by >>> the routing ressources. Therefore mainly the granularity of the >>> routing should be optimized. >>> No design has millions of gates of random logic. Large designs are >>> dominated by arithmetic function blocks. Therefore it is likely that >>> an FPGA with a granularity of 2 for example will have a much better >>> efficiency than current FPGAs. For random control logic half of the >>> LUTs would remain unused, but for datapathes the utilization would >>> approach 100% and the device coud save as much as 75% of the switches >>> and configuration bits. >>> This is old knowledge for FPGA architecure folks, but there are two >>> strong arguments against it: >>> 1.) >>> It is hard to quantify routing utilization, but the competitors >>> marketing will immediately target the lower LUT utilization as a >>> disadvantage. (But hey, if a LUT costs 75% less, who cares if I can >>> only use 80% of the LUTS? Especially if the clock frequency is >>> better?) >>> 2) >>> Granularity 1 FPGAs make use of the huge knowledge about ASIC EDA >>> algorithms. For higher granularities you need to redevelopemost of the >>> software toolflow from scratch. >>> There is a small FPGA vendor that has high speed global routing with >>> 10bit granularity. Maybe this is a start. The area savings are >>> marginal, as most of the switches are in local routing, but the speed >>> improvement for long connections is significant. >>> Kolja Sulimma >> Forgive my possible ignorance here (my fairly limited fpga experience is >> only with smaller Cyclones and PLDs, not big devices), but isn't >> "granularity 2" pretty much what the Stratix II, III (and IV, when it's >> available) have in their "adaptive logic module" ? And as far as I can >> see from the following recent white paper, this is exactly what Altera >> are saying - using the ALM they get much more into a Stratix with >> roughly the same number of logic elements / slices / LUTs / flip-flops >> than into a Virtex. Obviously all such marketing information must be >> taken with a large handful of salt. > > No. What I was saying is, that with granularity two, you get slightly > less logic into the same number of LUTs, at greatly reduced costs. > > Alteras (probably correct) claim is, that because they are more > flexible how the inputs to a LUT pair can be routed you can better > utilize the LUTs. This added flexibility probably increases the area > cost for the input routing significantly. > Granularity 2 would mean that a pair of elements (most importantly > routing switches) share a configuration. Each output of a LUT can only > reach half of the inputs that it could reach in a granularity 1 FPGA > (or must take a detour). Useful logic per LUT would go down (Because > soem LUTs can't be used), useful logic per chip area would go up > (Because each LUT with its associated routing ressources would get > less expensive). > > Altera is doing the opposite: Paying extra area for added flexibility. > It is achieving two goals by this: > a) It sounds better for marketing, because chip area is kept secret > anyway and sales prices are interpreted creatively. LUT count and > utilization OTOH are easily measured. > b) The device is easier to use because you can accurately estimate > whether your design will fit into the device. This is valueable and > might be worth the price. > I do not know much about Altera, but I know that starting with > Virtex-4 Xilinx decided to spent a lot extra area for routing to make > the delays more predictable. This helps the XST software people and > the users. But another design would have a better cost/performace > ratio. > Thanks - that makes it a bit clearer. It seems there are a couple of different ways to interpret the term "granularity" here, based on different aspects of the "grains". I was thinking in terms of the amount of logic and/or registers that are packed into a single minimal unit - the ALM with 6 inputs and two registers, outputs and arithmetic logic has a larger grain size than traditional 4 input elements (Peter Alfke mentions that the Virtex-5 uses 6-bit LUTs for the same reason) because more can be done in a single elemental step. You, I believe, are thinking more in terms of configuration and hard coding - a larger "grain" does more work for the same amount of configuration, and is thus smaller and faster than using multiple small grains for the same job. Examples include things like multipliers and multi-bit multiplexers (do any FPGAs have such things as hard macros? It seems an obvious idea for efficient implementation of soft processors, amongst other things). From Peter's post, it looks like FPGAs are moving towards larger granularity in both senses. mvh., DavidArticle: 132539
Ray wrote: > > Well, does this http://www.andraka.com/shortwave.htmdemo project count? > I did it as a demo back in early 2003. It worked surprisingly well > considering there is no analog front end. > FYI, TI now makes a nifty eval board for their ADS554x family that includes a 3S250E on board, about $300 USD, that makes for a great low budget 'SDR' platform: http://focus.ti.com/docs/toolsw/folders/print/ads5547evm.html 14-bit, 210 MSPS ADC XC3S250E with config flash expansion connectors for spare FPGA I/O BrianArticle: 132540
On Apr 24, 10:40 pm, krunal <krunal.c...@gmail.com> wrote: > hi....I want to implement Sigma Delta ADC in Spartan 3E starter > kit....i have implemented it as xilinx's xapp-155.....in ise it works > well for 8 bit....but give problem for 16 bit.....When i open it in > sysgen it now work.......actually in program the dac.v is > included......i dont know how to open that include file in > sysgen....please help........if any one have verilog or vhdl code for > that please send me........and i want to interface the exeternal ADC > also.....so please help me...... Hi Krunal, I understood you. English is a second language for me as well... Send me the files or links to them and I can see if I can make any sense for you... btw a tip... I would try to learn Mandarin instead of perfecting English. -sanjayArticle: 132541
Hi all, From the datasheet of 3c120 (cyclone III), the data[0] is a pin used in configuration, and in user mode it can be used as a dedicated input pin with "optional user control". But when I use it as an input pin in my design, the fitter reports an error saying this pin has been used. Is there any settings I should set before I can use this pin in user mode? Thanks, HuaArticle: 132542
My Virtex5 design has a clock from an input pin going to a PLL that generates several clocks at different frequencies. My design treats these as asynchronous clocks, so I don't want the ISE timing analyzer to work on timing for the registers that cross clock domains. I can write the timespecs as unrelated in my ucf, but ngdbuild always traces the input clock into the PLL, and generates additional constraints for the PLL output clocks that are all related. So timing analyzer reports timing violations on my clock domain crossings. In the past, I have put a TIG on every register that crosses clock domains, and that works. But it seems like if I could only make ngdbuild accept my (unrelated) PERIOD specs, instead of generating its own (related) specs, then it would be simpler to maintain. Anyone know how to control this in ngdbuild?Article: 132543
"backhus" <nix@nirgends.xyz> wrote in message news:g1o928$c8$1@news.hs-bremen.de... > Hi Vijayant, > every "rule of thumb" you are trying to use will give you a misleading > result. Even if you just want a maximum value. > > The only way to get a nearly accurate number is to synthesize your design > with an asic synthesis tool using the desired technology library. > > You may use a default synthesis at first, to get an idea of the size and > gate count. These results may vary depending on your design goals. If you > want to increase speed your design may become larger. If speed is > negotiable the design may become smaller with some area optimization > constraints. > > However, the result of this synthesis will be an area value (most likely > in square micro meters) because the used gates (and flipflops) heavily > vary in size and transistor count. Unless you are using a sea of gates > technology that has only nand2-elements. > > To give you an idea think about this: > > If you have a simple 4to1 mux, this may be synthesized with a single mux4 > cell in some standard cell technologies. With a sea of gates technology > you need a bunch of nand2's for this function, plus some routing > resources. > So, how would you express the number of gates in these two cases? > The mux4 is just the solution with the minimum number of cells. depending > on your constraints the result might be any correct combination of simpler > gates. > > Also, the gate count, however calculated is not relevant for production. > Only the area tells you how many chips can be fabricated on a single > waver. And the area changes with the used technology of course. > So 1000 gates in a 130nm technology yield less chips per waver than 2000 > gates in a 45nm technology. (rough estimation, just to give you an idea) > > So forget gate counts if you want to compare technologies. > Only use of gate counts is if you want to compare designs using the same > technology. And I mean the very same technology! (Just take a look at some > of the fruitless gate count discussions about Brand-A and Brand-X FPGAs) > Just wanted to argue on your last point .. gate count is the easiest means to compare technologies. It will stay relatively constant from tech to tech and you will have the nand2 area for the technology you are in so you can roughly compare the area of a design for different technologies using the gate count for the design. MikeArticle: 132544
On Fri, 30 May 2008 13:53:44 -0400, "Mike Lewis" > >gate count is the easiest means >to compare technologies. It will stay relatively constant from tech to tech Only if you ignore the possibility of the use of high drive strength gates. If your design is at the boundary of just meeting timing in a process the actual gates used in your design will most probably require higher drive strengths and your actual gate count will be higher than what you'd have guessed by just looking at logic requirements. Then when you port to the next lower feature process, your relative gate count change will be much higher than what you expect. As an example a NAND2X4 might be %50 larger than a NAND2X1 and the former might be needed in one process where as the latter would do in another.Article: 132545
Barry wrote: > My Virtex5 design has a clock from an input pin going to a PLL that > generates several clocks at different frequencies. My design treats > these as asynchronous clocks, so I don't want the ISE timing analyzer > to work on timing for the registers that cross clock domains. I can > write the timespecs as unrelated in my ucf, but ngdbuild always traces > the input clock into the PLL, and generates additional constraints for > the PLL output clocks that are all related. So timing analyzer > reports timing violations on my clock domain crossings. > > In the past, I have put a TIG on every register that crosses clock > domains, and that works. But it seems like if I could only make > ngdbuild accept my (unrelated) PERIOD specs, instead of generating its > own (related) specs, then it would be simpler to maintain. Anyone > know how to control this in ngdbuild? I've had the same issue and don't know of any solution except the TIGs. I wish there were some parameter on the DCM/PLL that you could use to specify that the outputs are unrelated. I use groups for the TIGs so I don't have to find every single crossing: NET "*fifo/wclk" TNM="write_stuff"; NET "*fifo/rclk" TNM="read_stuff"; TIMESPEC "TS_false_path7"=FROM "write_stuff" TO "read_stuff" TIG; TIMESPEC "TS_false_path8"=FROM "read_stuff" TO "write_stuff" TIG; -KevinArticle: 132546
On 30 Mai, 10:47, David Brown <da...@westcontrol.removethisbit.com> wrote: > You, I believe, are thinking more in terms of configuration and hard > coding - a larger "grain" does more work for the same amount of > configuration, and is thus smaller and faster than using multiple small > grains for the same job. Examples include things like multipliers and > multi-bit multiplexers (do any FPGAs have such things as hard macros? > It seems an obvious idea for efficient implementation of soft > processors, amongst other things). Well, the thread started with math stars FPOA which are granularity 16 devices, similar to MITs Matrix Architecture. http://www.mathstar.com/overview.html In theses devices groups of 16 wires are routed together and logic elements operate on 16 bit words. FPGAs by C-Switch contain 20 bit wide busses that connect to RAMs and ALUs of the same width in addition to the fine grain FPGA fabric. http://www.cswitch.com/images2/980_downloads/cswitchBro.pdf (B.T.W.: They claim to have 1067Gbps per pin DRAM support) Kolja Sulimma Kolja SulimmaArticle: 132547
On Fri, 30 May 2008 01:31:51 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >"Grant Stockly" <grant@stockly.com> wrote in message >news:0370016c-1f93-4cb5-ba0a-3ce58b804b3f@q27g2000prf.googlegroups.com... >> >> I found something... >> >> http://www.pldworld.com/_xilinx/html/tip/sixeasypieces.htm >> >No pictures for me. :-( > This seems to be problem with firefox. Internet explorer manages to view site correctly with the embedded images.Article: 132548
On May 30, 11:37=A0am, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > > NET "*fifo/wclk" TNM=3D"write_stuff"; > NET "*fifo/rclk" TNM=3D"read_stuff"; > TIMESPEC "TS_false_path7"=3DFROM "write_stuff" TO "read_stuff" TIG; > TIMESPEC "TS_false_path8"=3DFROM "read_stuff" =A0TO "write_stuff" TIG; > > -Kevin Thanks, Kevin. After some research, I came up with something similar. It appears to work, and relieves me of having to keep track of every asynchronous register. Barry NET "pci_clk" TNM =3D FFS pci_clk_grp; NET "ddr2_clk0" TNM =3D FFS ddr2_clk0_grp; NET "ilb_clk" TNM =3D FFS ilb_clk_grp; TIMESPEC TS_false_path1 =3D FROM pci_clk_grp TO ddr2_clk0_grp TIG; TIMESPEC TS_false_path2 =3D FROM pci_clk_grp TO ilb_clk_grp TIG; TIMESPEC TS_false_path3 =3D FROM ddr2_clk0_grp TO pci_clk_grp TIG; TIMESPEC TS_false_path4 =3D FROM ddr2_clk0_grp TO ilb_clk_grp TIG; TIMESPEC TS_false_path5 =3D FROM ilb_clk_grp TO pci_clk_grp TIG; TIMESPEC TS_false_path6 =3D FROM ilb_clk_grp TO ddr2_clk0_grp TIG;Article: 132549
On May 30, 10:06 am, Hua <Tommy...@gmail.com> wrote: > Hi all, > > From the datasheet of 3c120 (cyclone III), the data[0] is a pin used > in configuration, and in user mode it can be used as a dedicated input > pin with "optional user control". But when I use it as an input pin in > my design, the fitter reports an error saying this pin has been used. > Is there any settings I should set before I can use this pin in user > mode? > > Thanks, > Hua In the Device and Pins menu, Dual-Purpose Pins tab (Setting->Device- >Device and Pins Options->Dual-Purpose pins.) there's an option for what this pin should be after configuration. My guess is that you need to set this. G.
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