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
Dolphin wrote: > Hello, > > In my future design I could win a lot of pins if I could drive a bus at > 160MHz. Because of bank restrictions and because this bus is connected > to a CPLD, I will have to use LVTTL. > Has anybody tried driving a bus in LVTTL at 160MHz? > > I would prefer to use LVDS but the CPLD doesn't allow that. Lattice has > LVDS CPLDs but only the large CPLDs support LVDS inputs. > > I am afraid that this bus will have a lot of EMI/EMC problems. What do > you think of it, should series termination be adequate to limit the > EMI/EMC problems? > > best regards, > Dolphin > It can be done with extreme care. Keep the lines short, you may need to terminate them, and by all means do a SI simulation on it so that you know it will work rather than blindly applying "fixes".Article: 109501
John_H wrote: > "rickman" <gnuarm@gmail.com> wrote in message > news:1159365978.100646.5140@i42g2000cwa.googlegroups.com... > > > > Do the S3e parts have the same issue with the overly stiff pullups that > > the S3 parts have? I'm not sure if they are going to fix that in the > > S3a parts or not. > > It was fixed, indeed. The pullups on the S3s were pretty stiff. Things are > back toward expectations now with the S3E. I would expect the S3A to follow > S3E's lead. Fixed is a relative term. Worst case for the S3 is 1.4 kohms while the Virtex 4 is 16.5 kohms. The S3E is between at 2.7 kohms, only about 2x the S3 value and under a fifth of the V4 value. I can only assume that there is some issue with the IO design in the Spartan series that makes it hard to get a realisticly useful pullup value around 20 kohms like the V4 and other Xilinx product use. I'm sure we will never know the reason why.Article: 109502
If you are using a differential signal, like LVDS, you need to use a differential to single ended signal buffer. So, you would have two global "in" signals, in_P and in_N, which you assign pins to. Look at the FPGA's data sheet for examples of differential signal buffers. Then, "in" would be the output from the buffer. ---Matthew Hicks "tersono" <ethel.thefrog@ntlworld.com> wrote in message news:agkdh29dtdvp8p6t3rfr70iad3t3qrp0h5@4ax.com... > I've come to FPGAs from CPLDs and am rapidly realising that a > reasonable (but not complete) knowledge of Verilog is not enough! > > So tonight's question is: > > How do I set up a balanced input? > > I can write (a minimal example to make the point) > > ############ > module top(Q, in, clk); > output Q; > input in; > input clk; > > reg Q; > > always @(posedge clk) > Q<=in; > > > endmodule > ################ > > and in PACE I can specify that I want "in" to be- let's say- LVDS_25- > a balanced input type; I can put that input on pin 2- one of a pair. > (Diff Type and Pair Name are not writeable in the Design Object List). > > However, when the design has been fitted and routed, I find that pin > 3- the other of the pair- is not connected. > > What am I missing? > > Thank you in anticipation, > > Colin > > -- > Per ardua ad nauseamArticle: 109503
Peter, mixing clock domains (i.e. having multiple clock domains) is part of most digital designs. I'm surprised to see such an answer from a Xilinx engineer. I prefer the other two options stated here by other engineers, but I guess the answer to my question really is to use a DCM and control delays through it rather than a hand-coded divider? I'd still want to know if the Xilinx P&R tools could automatically handle the routing/buffering of the clock tree such that the skew between clocks declared as synchronous will be minimal. In my case, I see skew of upto 5 ns.Article: 109504
You can also buy hardware devices that use the I2C bus off of Digikey for a few bucks. That's what I did to completely test my design. ---Matthew Hicks "vits" <vittal.patil@gmail.com> wrote in message news:1159176429.670095.279080@h48g2000cwc.googlegroups.com... > Hi, > I need some (2 to 3) different I2C Slave models from different > companies (in verilog) > to test my I2C Bus .I have verified with the model given in opencores > site. > Please point me in this direction. > -Vits. >Article: 109505
Hi We are planning to use MIG to generate a DDR2 interface for a V2Pro30 design, but I'd like to know if anyone has done this successfully already? The MIG tool doesn't seem to have the quality level of other Xilinx tools and that makes me a bit nervous for something as timing critical as a DDR2 controller. We are using MIG 007 Rel 6 (as it's the recommended version for V2P). So far the only irritations we have encountered is that it forces the use of specific DCMs and requires the user to reselect every option each time it is invoked (no saving of current design). We plan to run 1 32 bit controller at 200MHz (400 Mb/s/pin) with Micron MT47H16M16. We would like to hear of any experiences with MIG and DDR2 and V2P, if only to convince us that this is doable. Our final design should be open sourced and available to all, if that encourages you to be open about your experiences. If you would rather contact me directly I am at gwatson@stanford.edu Thanks Greg WatsonArticle: 109506
> > there is no direct upper bound freq limitations its rather complicate > to > give such numbers actually. > > but as thumb guess if the system is not optimized for Xilinx marketing > to give absolute total max sysclock then the system in S3e would > have more chance to pass timing on sysclock below 100MHz > > but, again it all depens what IP cores you have in and how you apply > constraints and if you run xplorer script and multipass PAR, etc.. > > Its also hard to get 100Mhz on Virtex-4 (Xilinx advertizes 200MHz max > MicroBlaze clock for ver 4) so timing trouble on realworld microblaze > design in S3e at 100Mhz are just to be expected. > > you should try EDK 8.2 and MB5 it has improved pipeline that should > allow higher clocks, also it can run xplorer script on XPS system > > Antti Thanks for the help Antti. Even by dividing the clock down from 100MHz to some 'reasonable' value of 50MHz to 75 MHz, I am still unable to get a functioning UART on this board when trying to implement a new design. The fact that it works when modifying designs intended for the evaluation board is literally driving me nuts. It seems rediculous that I will have to originate designs targeted for evaluation hardware and then hack my way to funcional designs on my own hardware. I will try upgrading to 8.2 and see if that solves some issues. Consequently, is it possible that I'm exeeding the input range of the DCM at 100MHz? The more I fight with this, the less I think EDK is a time-saver when compared to a standard ISE flow. Thanks again though.Article: 109507
Let me "surprise" you even more: In an FPGA you should use the Global Clocks (there are many of them). Any global clock can drive any or all flip-flops on the chip, and its clock skew is so small that you will not have any hold-time issues between any flip-flops clocked by the same Global Clock. You will never see a Global Clock skew in exces of 1 ns. Your example of 5 ns indiates a scary way of using local clock routing. Don't do that! Using deliberate clock delays to balance away the clock-to-Q of a synchronous clock divider is something I would advise you NOT to do in an FPGA, unless you have a very good understanding of the signal distribution in the design (As I explained in my previous posting, which you chastized me for. You are forgiven, but I stand by my statements). Peter Alfke =========== zohair wrote: > Peter, mixing clock domains (i.e. having multiple clock domains) is part of most digital designs. I'm surprised to see such an answer from a Xilinx engineer. I prefer the other two options stated here by other engineers, but I guess the answer to my question really is to use a DCM and control delays through it rather than a hand-coded divider? > > I'd still want to know if the Xilinx P&R tools could automatically handle the routing/buffering of the clock tree such that the skew between clocks declared as synchronous will be minimal. In my case, I see skew of upto 5 ns.Article: 109508
Hi, There are 2 modes of operation for lwIP stack - RAW API, Sockets API. The initializations are different based on the mode chosen. Please take a look at the lwIP documentation that is part of the EDK release. Look for the lwIP chapter in the OS & Libraries guide. Sathya u_stadler@yahoo.de wrote: > hi > > i have a quick question: > > do i have to use lwip_init() for raw_api mode as well or do i have to > call all the mem_init() etc. seperatly? > > when using the raw mode and calling all the init functions as in the > xilinx example a call to sys_new_thread() wont start the new thread and > it looks likte the function doesn't do anything. > could somebody help me out here please? > > thanks > urbanArticle: 109509
Also be careful of Simulaneously Switching Outputs guidelines. As Ray says it can be done but if you use a crappy package like PQ208 or TQ144 you may have big problems with ground bounce that causes the interface to fail. Most of the BGA packages do much better at this fast type of driving from our experience. Some CPLDs like the bigger Coolrunner-IIs can also support single ended standards like SSTL, HSTL that are designed for high speed and may be a an alternate solution for you. These standards have the advantage of small signal swings too which is better for ground bounce and EMC. John Adair Enterpoint Ltd. Ray Andraka wrote: > Dolphin wrote: > > Hello, > > > > In my future design I could win a lot of pins if I could drive a bus at > > 160MHz. Because of bank restrictions and because this bus is connected > > to a CPLD, I will have to use LVTTL. > > Has anybody tried driving a bus in LVTTL at 160MHz? > > > > I would prefer to use LVDS but the CPLD doesn't allow that. Lattice has > > LVDS CPLDs but only the large CPLDs support LVDS inputs. > > > > I am afraid that this bus will have a lot of EMI/EMC problems. What do > > you think of it, should series termination be adequate to limit the > > EMI/EMC problems? > > > > best regards, > > Dolphin > > > It can be done with extreme care. Keep the lines short, you may need to > terminate them, and by all means do a SI simulation on it so that you > know it will work rather than blindly applying "fixes".Article: 109510
i used the branch of the ppc kernel mentioned here http://www.stanford.edu/~malechen/linux_on_fpga.htm and copied over the files from the BSP then what i did was to edit the Makefile in the drivers/net directory and change the references from xilinx_enet to xilinx_gige, and select the regular xilinx driver in the menuconfig -rimas p.s. if the PVR (processor version register) in your mini-module is 0x20011430 make sure you apply patches to turn off caching or you will have problems. more info here: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPagePath=20658&BV_SessionID=@@@@0781667753.1159381366@@@@&BV_EngineID=ccccaddimemlhmicefeceihdffhdfjf.0 Benedikt Wildenhain wrote: > Hello, > > On Wed, Sep 13, 2006 at 05:15:24PM -0700, funkrhythm wrote: > > Benedikt Wildenhain wrote: > > > Now I want to try sending some IP packets accross the wire, but both > > > xilnet and lwip insist on using either opb_ethernet or -lite. Are there > > > any adjusted versions for one of these? > > don't know about that, i am running linux on the V4FX12 and the EDK > > generates an ethernet driver (xilinx_gige) that works with the > > PLB_TEMAC > How did you compile a matching kernel? I tried to compile a 2.4 kernel > (I tried several branches, but finally got farest with the branch from > bee2.eecs.berkeley.edu as it already has integrated the xilinx_gige > driver) with the BSP for Montavista Linux 3.1. As (menu|x)config doesn't > offer my board I set CONFIG_MEMEC_2VPX=y, tried to compile it with > support for uartlite (for the serial console) and xilinx_gige, but > linking the kernel fails with >Article: 109511
Antti schrieb: > Peter Alfke schrieb: > > > You can order Virtex-5 devices from your distributor now, and he will > > offer short delivery times. > [...] > > Peter Alfke, who has been working on and with these parts for over a > > year. > [my own ***** snipped] > until both the silicon AND tools are available there is no supprort. > So no matter how ready we may be for Virtex-5, and belive me some > of us really are - we are not really able todo any real work until > tools support is also made available by Xilinx. > EDK 8.1 SP1 has Virtex-5 MicroBlaze 5.00.a and 5.00.b in it it is just labelled as "early access" but its readily available. there is some minor mess with MPD files like FSL bus is not supported (eg requires manual edit of the MPD) but otherwise the Virtex-5 can be targetted ok on EDK 8.1 SP1, eg no need to wait for SP2 here is the picture of the EDK system with Virtex-5 http://www.microfpga.com/joomla/index.php?page=shop.browse&category_id=12&option=com_virtuemart&Itemid=26 AnttiArticle: 109512
mjackson schrieb: > > > > there is no direct upper bound freq limitations its rather complicate > > to > > give such numbers actually. > > > > but as thumb guess if the system is not optimized for Xilinx marketing > > to give absolute total max sysclock then the system in S3e would > > have more chance to pass timing on sysclock below 100MHz > > > > but, again it all depens what IP cores you have in and how you apply > > constraints and if you run xplorer script and multipass PAR, etc.. > > > > Its also hard to get 100Mhz on Virtex-4 (Xilinx advertizes 200MHz max > > MicroBlaze clock for ver 4) so timing trouble on realworld microblaze > > design in S3e at 100Mhz are just to be expected. > > > > you should try EDK 8.2 and MB5 it has improved pipeline that should > > allow higher clocks, also it can run xplorer script on XPS system > > > > Antti > > Thanks for the help Antti. Even by dividing the clock down from 100MHz > to some 'reasonable' value of 50MHz to 75 MHz, I am still unable to get > a functioning UART on this board when trying to implement a new design. > The fact that it works when modifying designs intended for the > evaluation board is literally driving me nuts. It seems rediculous that > I will have to originate designs targeted for evaluation hardware and > then hack my way to funcional designs on my own hardware. > > I will try upgrading to 8.2 and see if that solves some issues. > Consequently, is it possible that I'm exeeding the input range of the > DCM at 100MHz? The more I fight with this, the less I think EDK is a > time-saver when compared to a standard ISE flow. > > Thanks again though. after years of fight, I still fight (with EDK) - but I think EDK is actually getting better. get 8.2 and let the xplorer script to optimize timing if you want to squeeze the max clock. getting the DCM to work in EDK isnt so simple, or maybe it is but it is equally simple to get something wrong and they want work. I think as of some errata S3e early silicon had DCM input range maxed at 90MHz? production silicon is defently ok to use way higher inputs clocks good luck and many succesful fights with EDK! AnttiArticle: 109513
> Stop this already, some of us are not going to get much work done today > if you keep this up. > > Now I have to go clean myself up:) > > John Jakson > transputer guy I hope you used the new m=F6bius strip wipes that come packaged in a four-dimensional Klein bottle for a never-ending supply! ToddArticle: 109514
Ralph Hartley wrote: > David Ashley wrote: > > Speaking of which, here's a nobel prize winning idea. > > Assuming the problem of protein folding is part of NP > > complete, all you'd have to do is construct a DNA > > sequence that encodes for a protein, and the protein > > itself is equivalent to some OTHER NP problem you > > want to solve. So you let the protein go and fold however > > it wants to, and then you look at how it's folded, and you > > have your answer. So you've managed to get the universe > > to work for you. :) > > Not a particularly new idea, I'm afraid. The problem is that the protein > corresponding to a hard problem will take nearly *forever* to fold. > > It is not true that an arbitrary protein sequence will quickly fold into > a stable structure that is the same each time. In fact, most will *not* > do that. Biological proteins do (mostly), but they were selected for that. > > Ralph Hartley Hi, Here is a good introduction reference on the minimum vertex cover problem: http://www.cs.uu.nl/docs/vakken/amc/lecture03-4.pdf#search=%22minimum%20vertex%20cover%22 WengArticle: 109515
Hello, I've been seeing more training at Altera concerning their SOPC Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if these tools are gaining acceptance in the engineering world? A co-worker used the Nios processor a few years ago and said that it was slow so they didn't use it in their project. Are these tools useful for high-speed applications? If anyone can comment on these tools I'd greatly appreciate it. Thanks, joeArticle: 109516
jjlindula@hotmail.com schrieb: > Hello, I've been seeing more training at Altera concerning their SOPC > Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if > these tools are gaining acceptance in the engineering world? A > co-worker used the Nios processor a few years ago and said that it was > slow so they didn't use it in their project. Are these tools useful for > high-speed applications? If anyone can comment on these tools I'd > greatly appreciate it. > > Thanks, > joe learning is almost always worth (something). NIOS (or any soft-core CPU) - is not as fast as dedicated CPU's today can be, and equally is the bus structure and peripherals also not as fast as they can be in dedicated MCU's - so the real advantages come from the combination of configurable processor core, user selectable peripheral, AND user added IP cores. a small task that may take up 99% of the CPU time could possible be moved to FPGA hardware directly and only consume 1% of the FPGA resources. That would give you a feeling like the CPU did come 100 times faster! if using the softcore processor alone, then it want compete with dedicated CPU's it has never been the goal also. AnttiArticle: 109517
Xilinx isnt advertizing 'small things' that are also coming as bonus with Virtex-5, I found one by accident while browsing the ML501 reference designs and docu, namly * Virtex-5 has fully dedicated pins for the parallel flash so any NOR flash connected properly as configuration memory is also accessible by the dedicated pins for both read and writes. Those it is possible to use indirect nor flash programming for V5-connected nor flash, and surprise it is already offered by Xilinx! its hidden in the "LAB resources" for ML501 but the indirect programming software and bitstreams are available for all v5lx devices. * anothes small thing is the access to configuration clock oscillator after configuration from FPGA fabric (but that has already been told here) * not to mention that the SYSMON what is there in V4 (but disabled by the tools) is now finally user accessible * CRC32 and CRC64 as primitives * EFUSE primitive whats that !? * KEYCLEAR primitive !! Thanks you, Xilinx! this is for clearing the encryption key from the FPGA fabric - I was missing this feature badly, now its there !! * PCIE primitive ? I am not believing what I am seeing ?! * PMV is still there too * USR_ACCESS is enhanced as well I guess there are some more nice small things hidden - anyone found something? or was I just dreaming? too late maybe I'd better rest or who knows what else I would be seeing! AnttiArticle: 109518
Dear Miss Lazarut, It seems i am the victim of using capital letters with my words! I did not know in the first place that this was prohibited for a formal conversation. My whole point was to take some ideas from professionals like you for performing my paper related to FPGA's and optimization of placement and routing. May you help me, please? Regards! Aurelian Lazarut wrote: > Mr. Aoun, > ************* > Alexandre Aoun > Computer Engineering Student > Mathaf Adlieh street - Beirut, Lebanon > Born 1983 > ************* > if you have anything to do with FPGA's or digital design you are > welcome, but you need to know your place > it seems that you've been caught on the wrong foot here, so you have the > chance to back off, read and learn, otherwise you'll become a clown in > this newsgroup. > at the end of the day it's your choice. > > Aurash > > PS, and please stop imitating Yoda from Star Wars when you post > messages, Syms is at least one order of magnitude better than you ;-) > > solo wrote: > > >Mr Peter, > > > >I didnt like your reply: > > > >First, all my ideas are interesting since i am related to the field of > >software enginnering and i ignore the field where you come from! > > > >Second, i didnt understand the impolite word "ass-backwards" that you > >used and i wish that you keep those rude words for yourself and your > >culture! > > > >Third and most importantly, my statements are not arrogant at all! Your > >reply to me seems that you want to revenge from someone and this is not > >acceptable! > > > >Hope you be more lineant and understanding when replying to people, > >otherwise your replies are not interesting and will be rejected! > > > >Thanks! > > > >Peter Alfke wrote: > > > > > >>We may have to teach Mr Solo some basic facts: > >>First you must have an interesting idea or some valuable specific > >>knowledge. > >>Then, and only then, do you start writing an article. > >>He seems to have this ass-backwards. > >>Beyond that it might also be wise not to insult this newsgroup with > >>arrogant statements about the lust for capitalization. > >>Peter Alfke > >>============= > >>Todd Fleming wrote: > >> > >> > >>>This gives a whole new meaning to the term "partial reconfiguration" > >>> > >>>Todd > >>> > >>>jacko wrote: > >>> > >>> > >>>>how about single inline fpga which use veroboard spacing, and can be > >>>>broken off at one pin intervals. > >>>> > >>>>place 4 pins in prigrammer for power, clk, and program data, and then > >>>>break off to length specified by fpga compilier. > >>>> > >>>> > >>>>available in 1m strips maybe. > >>>> > >>>> > >>>>needs comparator for analog input, and as much logic in 1 pin segment > >>>>as possible. > >>>> > >>>> > >>>>flash on board prefered, with some 4 cycle dram too, for compactness. > >>>> > >>>> > >>>>is this the kind of thing u meant?? > >>>> > >>>> > > > > > > > > > -- > __ > / /\/\ Aurelian Lazarut > \ \ / System Verification Engineer > / / \ Xilinx Ireland > \_\/\/ > > phone: 353 01 4032639 > fax: 353 01 4640324Article: 109519
On 26 Sep 2006 14:33:03 -0700, "Patrick Dubois" <prdubois@gmail.com> wrote: >Hello, > >I know that this has been discussed here a few times but I still can't >find a definitive answer so here we go again... > >What is the best way (with Xilinx flow) to ensure that registers are >packed into IOB? In my case I want three registers to be packed into >the IOB for a bidirectionnal signal (in, out and oe). You seem to have the standard tricks... >I read quite a bit about the issue and the standard tricks seem to be: >1- Use the IOB = "true" constraint in the HDL code for the registers >2- Use the flag -iob true for xst (redundant with #1) Not only redundant, but quite dangerous since this flag appears to apply the IOB=TRUE attribute to every individual register (maybe only every register on a hierarchy boundary) regardless of whether it is anywhere near a pin. And this attribute prevents packing registers into multipliers and who knows what else... #1 applied ONLY to the registers in question gives much better control >4- Duplicate the oe registers and use equivalent_register_removal = >"NO" to prevent xst from optimizing them away Essential - and again, apply equivalent_register_removal as an attribute ONLY to the registers in question, not as an XST flag... With both of these as global flags I have seen a 15% slowdown and 20% greater register usage in a design. - BrianArticle: 109520
On 27 Sep 2006 08:31:02 -0700, "zeeman_be" <zeemanbe@gmail.com> wrote: >Hi all, > >I am implementing a microblaze processor in a subdesign in a Virtex4 >component (ISE v7.1 sp3, EDK v7.1 sp2). >The microblaze is using the internal BRAMS as instuction and data >memory. > >The program is increasing and becomes more than 64kByte. >It would be a solution to split the textblock in two parts. I have >found the instructions for writing a LinkerScript for doing that. The >only problem I have is to find the place where the object files of my >code are temporary stored. XAPP642 and Answer Record 16547 show how to locate individual functions into segments other than "text". In fact it's even slightly simpler than shown there. You only need to use the "Generate Linker Script" dialog to generate a new segment (say, "text2") and locate it in your second 64K block. Then use the attributes as shown to place any individual functions in text2 instead of text. No need to write linker scripts or find object files. (I've only used it with the PPC gcc under EDK 7.1 but see no reason why mb should be any different in this respect) - BrianArticle: 109521
Hi, I'm looking for the two QED's accessory files: qed_filt.c qed_cgen.h Can you help me? Thanks, Roberto -- "Malo ho'omou tokoni " 73's de IZ5FCY Roberto ----------------------------- http://www.iz5fcy.it (work in progress..)Article: 109522
Hi! i am having problem to communicate between virtex4 fx60 to 512 SODIMM. I use the MIG1.6 to generate a controller. I add one module into the design, change some names and run ModelSim. The simulation looks fine. So, i use the ICE tools to get my bit file. When i check all the report, I saw the map report have the follwoing message: WARNING:MapLib:851 - Your design is using FIFO16 primitives, Please note that there are additional requirements for the FIFO16 to guarantee full functionality. For more information regarding requirements for the FIFO16 primitive, please see Answer Record 22462. is that going to cause me fail on the design? I didn't fine any .edn or ngc file in the folder that MIG generate. I also run the time simulation, it didn't match with the funcational simulation. Seems like signal start fail in 200ns. Am i missing anything? In addition, I chipscope the signal. It seems like data did get in the fifo. But the controller never request a read. Any ideas? Thanks! Wai ShanArticle: 109523
Alexandre, at least you have become polite now. The problem we all had with your original posting (besides the ALLCAPS) was that you seem to claim that you can write a valuable article about absolutely anything. All we need is to give you a topic. That's pretty arrogant coming from a 23-year old student. There are people in this newsgroup that have a professional experience much longer than your age (double that in my case). You might have asked: What is an interesting, somewhat unexplored subject in FPGAs, so that I can study it, and perhaps (after a while) contribute to it. Peter Alfke ======================================= solo wrote: > Dear Miss Lazarut, > > It seems i am the victim of using capital letters with my words! I did > not know in the first place that this was prohibited for a formal > conversation. > My whole point was to take some ideas from professionals like you for > performing my paper related to FPGA's and optimization of placement and > routing. > May you help me, please? > > Regards! > > Aurelian Lazarut wrote: > > Mr. Aoun, > > ************* > > Alexandre Aoun > > Computer Engineering Student > > Mathaf Adlieh street - Beirut, Lebanon > > Born 1983 > > ************* > > if you have anything to do with FPGA's or digital design you are > > welcome, but you need to know your place > > it seems that you've been caught on the wrong foot here, so you have the > > chance to back off, read and learn, otherwise you'll become a clown in > > this newsgroup. > > at the end of the day it's your choice. > > > > Aurash > > > > PS, and please stop imitating Yoda from Star Wars when you post > > messages, Syms is at least one order of magnitude better than you ;-) > > > > solo wrote: > > > > >Mr Peter, > > > > > >I didnt like your reply: > > > > > >First, all my ideas are interesting since i am related to the field of > > >software enginnering and i ignore the field where you come from! > > > > > >Second, i didnt understand the impolite word "ass-backwards" that you > > >used and i wish that you keep those rude words for yourself and your > > >culture! > > > > > >Third and most importantly, my statements are not arrogant at all! Your > > >reply to me seems that you want to revenge from someone and this is not > > >acceptable! > > > > > >Hope you be more lineant and understanding when replying to people, > > >otherwise your replies are not interesting and will be rejected! > > > > > >Thanks! > > > > > >Peter Alfke wrote: > > > > > > > > >>We may have to teach Mr Solo some basic facts: > > >>First you must have an interesting idea or some valuable specific > > >>knowledge. > > >>Then, and only then, do you start writing an article. > > >>He seems to have this ass-backwards. > > >>Beyond that it might also be wise not to insult this newsgroup with > > >>arrogant statements about the lust for capitalization. > > >>Peter Alfke > > >>============= > > >>Todd Fleming wrote: > > >> > > >> > > >>>This gives a whole new meaning to the term "partial reconfiguration" > > >>> > > >>>Todd > > >>> > > >>>jacko wrote: > > >>> > > >>> > > >>>>how about single inline fpga which use veroboard spacing, and can be > > >>>>broken off at one pin intervals. > > >>>> > > >>>>place 4 pins in prigrammer for power, clk, and program data, and then > > >>>>break off to length specified by fpga compilier. > > >>>> > > >>>> > > >>>>available in 1m strips maybe. > > >>>> > > >>>> > > >>>>needs comparator for analog input, and as much logic in 1 pin segment > > >>>>as possible. > > >>>> > > >>>> > > >>>>flash on board prefered, with some 4 cycle dram too, for compactness. > > >>>> > > >>>> > > >>>>is this the kind of thing u meant?? > > >>>> > > >>>> > > > > > > > > > > > > > > > -- > > __ > > / /\/\ Aurelian Lazarut > > \ \ / System Verification Engineer > > / / \ Xilinx Ireland > > \_\/\/ > > > > phone: 353 01 4032639 > > fax: 353 01 4640324Article: 109524
Thanks for the good advice Brian. Small details often make a big difference. Patrick Brian Drummond wrote: > On 26 Sep 2006 14:33:03 -0700, "Patrick Dubois" <prdubois@gmail.com> > wrote: > > >Hello, > > > >I know that this has been discussed here a few times but I still can't > >find a definitive answer so here we go again... > > > >What is the best way (with Xilinx flow) to ensure that registers are > >packed into IOB? In my case I want three registers to be packed into > >the IOB for a bidirectionnal signal (in, out and oe). > > You seem to have the standard tricks... > > >I read quite a bit about the issue and the standard tricks seem to be: > >1- Use the IOB = "true" constraint in the HDL code for the registers > >2- Use the flag -iob true for xst (redundant with #1) > > Not only redundant, but quite dangerous since this flag appears to apply > the IOB=TRUE attribute to every individual register (maybe only every > register on a hierarchy boundary) regardless of whether it is anywhere > near a pin. And this attribute prevents packing registers into > multipliers and who knows what else... > > #1 applied ONLY to the registers in question gives much better control > > >4- Duplicate the oe registers and use equivalent_register_removal = > >"NO" to prevent xst from optimizing them away > > Essential - and again, apply equivalent_register_removal as an attribute > ONLY to the registers in question, not as an XST flag... > > With both of these as global flags I have seen a 15% slowdown and 20% > greater register usage in a design. > > - Brian
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