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
rickman wrote: > > Doesn't Microsoft provide a CUI for Windows? If nothing else, all you > have to do is fire up most *any* program to learn how mouse clicks > work to select items. Having the default action of a click to be > "adding" items to the selection is a new twist. Most programs use > Cntl-Left Click to cumulatively select items (or often to unselect > them too). Unselection is typically done by clicking on *anything* > else including nothing. Yes, certainly the common EDA/CAD model is Click Selects, and ^Click toggles the Selected flag on eash item. So you can add/delete at will, from a selected set. Some systems also then allow right-click Combine into a Group/Block. > So if I click on object A and then click on > object B and drag, I would not expect object A to be dragged along > with B. This happened to me with this program. Object A was dragged > off the view and the undo didn't work. I couldn't find a way to > expand the view, so I ended up with a drawing that had things in it > that I couldn't delete or see. Better pgms have a Zoom Extents, to cover this type of problem. > I ended up closing the program (partly > out of frustration and partly out of time constraints) and let it save > the file. I tried to start the program up again and it would not > run. The author says the drawing file is now corrupt. When the > program auto-opens it on startup, it crashes. If this is easily reproduced, it should also be easy to fix. -jgArticle: 132726
On 5 Jun., 17:39, austin <aus...@xilinx.com> wrote: > Gabor, > > I believe they have a new memory technology, where they can OTP the > device, and then even after that, they can reload a bitstream into SRAM. > > Thus, you may prototype by just downloading streams until it is correct, > and then do the OTP step to "freeze" that stream in place. > > This avoids the traditional OTP (fuse) problem of wasting parts until > you get it right. It also allows you to test the parts before you ship > them (unlike fuse FPGAs). The datasheet states, they use on-chip flash to store the bitstream and configure SRAM from this flash. AFAIK is this similar to Lattice FPGAs. The power consumption seems to me very impressive. I wonder, if the numbers are usable for real designs. It might be interesting to here someone independend comparing Actel Iglooplus and Lattice against this technology. bye ThomasArticle: 132727
austin wrote: > Gabor, > > I believe they have a new memory technology, where they can OTP the > device, and then even after that, they can reload a bitstream into SRAM. > > Thus, you may prototype by just downloading streams until it is correct, > and then do the OTP step to "freeze" that stream in place. > > This avoids the traditional OTP (fuse) problem of wasting parts until > you get it right. It also allows you to test the parts before you ship > them (unlike fuse FPGAs). That is not really 'new' - other devices out there, already allow config without memory access/pgm. - ie a volatile config. It can also be useful for board testing (and maybe hacking ;) Most of the simpler applications, have quite stable PLD code, so OTP is not a big hurdle, unless it has other gotchas. The Volatile mode covers development. It certainly DOES save in process costs, and allows a couple of generation jumps, which for a FPGA matters much more. [ I think some other vendors OTP is VERY slow to pgm ? ] -jgArticle: 132728
"MikeWhy" <boat042-nospam@yahoo.com> wrote in message news:6yX1k.3643$ZE5.2616@nlpi061.nbdc.sbc.com... > "PFC" <lists@peufeu.com> wrote in message > news:op.ub9x8di9cigqcu@apollo13.peufeu.com... > > I have an escape route. > If I include FireWire in the project (which now seems likely), then I can > use the ARM7 cpu which is in the DICE FireWire chip. I would have to > connect its bus to the FPGA, using lots of pins, but there are enough pins > to do this. I think this is going to be the simplest way to pass the > licensing minefield. > > ========== > > If you're going that route, the Atmel AP7 Cortex M3 has dual Ethernet > MII/RMII MAC, USB 2.0 PHY, LCD/TFT, yada yada (all the makings of a WinCE > device). I don't recall seeing 1394 in its feature list, however. $25 > single quantity. No licensing of "core" issues, obviously. Development > tools are open source GCC. Some applications benefit less from FPGA > capabilities than other, more traditional solutions. Your project > description can fit this slot. Come to think of it, I would like such a device if paired with a mid-size Spartan, something on the WebPack supported-device list. A development platform with broad connectivity options using free and open source tools sounds very, very appealing. Even the relatively large S3ADSP 1800 can take advantage of offloading some functions to a real MPU, filling some of the ground between it and the 3400, and avoiding EDK licensing. That's pushing toward a LinuxCE with onboard FPGA. IOW, fpga for the masses. Hmmm...Article: 132729
"JeDi" <jaydev.shelat@gmail.com> wrote in message news:5927360c-b4ca-488f-9019-cee1a0ed569f@a9g2000prl.googlegroups.com... > > So, my question is regarding Verilog HDL coding - Is there any > recommended coding style which improves timing closure (or in other > words makes it easier for the tools to meet timing ) ?? > No, there are no 'coding styles' in any language that will do anything to improve clock cycle performance. To improve timing you change your design to pipeline the processing. To pipeline you break up a 'big' computation (i.e. one that takes a long time and therefore becomes a critical timing path) into smaller ones that take multiple clock cycles. Kevin JenningsArticle: 132730
Gabor wrote: > By the way, the FPGA Journal article seems to imply that the > OTP non-volatile memory can hold more than one configuration. > The datasheet does not bear this out. Might be some models only ? It's a simple trade off, if the die-area of memory is really as small as their graphics indicate, then you can mitigate part of OTP drawbacks, by allowing (eg) TWICE the config. (plus you also cover other uses, like Test modes, or country-modes etc) Be interesting to see their Device Program times, AND their OTP memory Yields (that's another OTP drawback: yield < 100%). Even in Microcontrollers, companies like Silabs are releasing OTP variants, at sigificantly lower prices than flash. That suggests either the FAB, or TESTING, (or both) costs are quite large. -jgArticle: 132731
On 2008-06-05, rickman <gnuarm@gmail.com> wrote: > On Jun 5, 9:14 am, Brian Drummond <brian_drumm...@btconnect.com> > wrote: >> >> Do you work in the NHS, or for one of their equipment suppliers? >> All the CUI references (includinghttp://www.mscui.net/seem to be >> associated with the health care sector. > > I have no idea what you are talking about... I am an electronic > design engineer and have never worked in the health care sector. What > exactly is NHS? Is that a government agency or a company? NHS = National Health Service, the state run healthcare provider here in the UK. Unlike state healthcare provision in the US the NHS is fairly comprehensive and covers the entire population (paid for out of general taxation). As a result it is a massive organisation - it dwarfs the entire Ministry of Defence, for instance. ISTR it is Europe's biggest employer. > I'm really not trying to bash the tool. I expect there are those who > like it and use it. I have often wanted a good tool for drawing > waveforms and timing diagrams. But the very first and most important > feature is that it has to be easy and intuitive to use. I feel that I > should be able to sit down and use it without reading a manual or > taking a tutorial. Many years ago I did that with a Mac! I expect > most people do that with the iPhone and iPod. A timing diagram editor > is not a complex tool. I should be able to draw simple waveforms > without learning a complex interface. I currently use Visio and I > find that to be a burdensome tool for simple things. It also has its > own ways in which it doesn't work. I just wanted something a bit > simpler. Interesting that you mention Macs. For many years Apple have published user interface guidelines that document exactly how UIs should behave. I recall looking through the one for the Newton a few years ago and it was very prescriptive and quite forceful in places. I remember it was full of things like "This UI component has square corners. This other component has rounded corners. If you need to reimplement them for some reason you stick to those conventions or your users will be swamping your helpdesk with support enquiries." This might not give designers as much leeway to create "really cool" interfaces but I suspect it is more in tune with what many users actually want. This is also an area where Microsoft have completely lost the plot. Since Windows 95 every major release of Windows has been accompanied by a new interface. Applications are even worse - I don't know how many style of toolbar have been played with over the last 15 years. Microsoft always make great play of the new interface but who exactly does it benefit? Users are forced to learn new interfaces every upgrade and application developers are forced to 'upgrade' their programs with the new UI or risk being considered outdated. The only people I can see benefiting are Microsoft themseleves (it provides a very obvious reason to upgrade, even if it does lack clear benefits) and hardware manufacturers (the upgrade needs newer faster hardware). For all the talk of enhancing the user's experience it seems obvious to me that MS don't give a shit about users. All that matters is ensuring that the revenue keeps coming in from repeated meaningless upgrades. -- Andrew Smallshaw andrews@sdf.lonestar.orgArticle: 132732
Andrew Smallshaw <andrews@sdf.lonestar.org> writes: > [...] > For all the talk of enhancing the user's experience it seems obvious > to me that MS don't give a shit about users. Have you ever met Tux? :) -- % Randy Yates % "Maybe one day I'll feel her cold embrace, %% Fuquay-Varina, NC % and kiss her interface, %%% 919-577-9882 % til then, I'll leave her alone." %%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO http://www.digitalsignallabs.comArticle: 132733
On 2008-06-05, Randy Yates <yates@ieee.org> wrote: > Andrew Smallshaw <andrews@sdf.lonestar.org> writes: >> [...] >> For all the talk of enhancing the user's experience it seems obvious >> to me that MS don't give a shit about users. > > Have you ever met Tux? :) I prefer Beastie myself. Shackleton had the right idea about penguins. ;-) Seriously though the situation on Unix platforms is getting worse by the minute. 10-15 years the toolkit wars were over and Motif was the winner. Most apps were shifting to Motif and CDE was coming to further standardise the UI. However, as soon as Linux started to gain traction things started to deteriorate again, quite probably becasue Motif wasn't free. Now you need any number of different toolkits to cover a broad range of apps and things like Gnome and KDE are far more substantial bits of code than anything that went before. The net result is that each app has a completely different appearance, works in a different way, and the whole assembly is one great waste of memory and processor time. -- Andrew Smallshaw andrews@sdf.lonestar.orgArticle: 132734
In article <4b62488d7f5738ca9575348d78d8@news.ks.uiuc.edu>, mdhicks2 @uiuc.edu says... > I can think of a few obvious reasons why Xilinx would fire and hire at the > same time. One, they probably cleared-out some of the middle management > fluff that comes with a company of Xilinx's size. This would explain why > they are still trying to hire for technical positions. Two, new hires tend > to be cheaper than veteran employees are. Three, new hires, on AVERAGE, > are more productive than more established employees. Four, new people bring > new ideas; Xilinx already has the good ideas from the people they fired. > Five, firing can be used to eliminate the replication of ideas and services > provided by a company's work force. Why does Austin need x employees who > only know a strict subset of what he knows? He may have to do more work, > but the company should save money in the end. Three, four, and five are the most repulsive *excuses* for a layoff I have ever heard! ...and two is close. -- KeithArticle: 132735
MikeWhy wrote: > > If you're going that route, the Atmel AP7 Cortex M3 has dual Ethernet > MII/RMII MAC, USB 2.0 PHY, LCD/TFT, yada yada (all the makings of a > WinCE device). The Atmel AP7 is an AVR32 core, not Cortex M3, but they do have low cost development boards for this, and it has plenty of horsepower. -jgArticle: 132736
>> If you're going that route, the Atmel AP7 Cortex M3 has dual Ethernet= = >> MII/RMII MAC, USB 2.0 PHY, LCD/TFT, yada yada (all the makings of a = >> WinCE device). I don't recall seeing 1394 in its feature list, howeve= r. = >> $25 single quantity. No licensing of "core" issues, obviously. = >> Development tools are open source GCC. Some applications benefit less= = >> from FPGA capabilities than other, more traditional solutions. Your = >> project description can fit this slot. Yeah I thought about using this one, too. I have a board with this CPU here (the NGW100) but was not impressed by= = the ethernet performance. It is probably the Linux overhead, though. If = my = plans for firewire fail due to licensing I will consider it again ;) > Come to think of it, I would like such a device if paired with a = > mid-size Spartan, something on the WebPack supported-device list. A = > development platform with broad connectivity options using free and op= en = > source tools sounds very, very appealing. Even the relatively large = > S3ADSP 1800 can take advantage of offloading some functions to a real = = > MPU, filling some of the ground between it and the 3400, and avoiding = = > EDK licensing. That's pushing toward a LinuxCE with onboard FPGA. IOW,= = > fpga for the masses. Hmmm... Actually I wonder why no-one proposes such a board at a decent price. = There are some that come close, but there is always a gotcha, either = price, or some other problems like in this one : http://www.embeddedarm.com/products/board-detail.php?product=3DTS-7300 Where the connection between the CPU and FPGA is using a crummy 8 bit b= us = and the the FPGA hasn't got enough IO pins exposed...Article: 132737
Matthew Hicks wrote: > I can think of a few obvious reasons why Xilinx would fire and hire at the > same time. One, they probably cleared-out some of the middle management > fluff that comes with a company of Xilinx's size. This would explain why > they are still trying to hire for technical positions. Two, new hires tend > to be cheaper than veteran employees are. Three, new hires, on AVERAGE, > are more productive than more established employees. Four, new people bring > new ideas; Xilinx already has the good ideas from the people they fired. > Five, firing can be used to eliminate the replication of ideas and services > provided by a company's work force. Why does Austin need x employees who > only know a strict subset of what he knows? He may have to do more work, > but the company should save money in the end. > > > ---Matthew Hicks (my first ability to post today) Your conjecture is opinion that may be closer or further from the truth for any and all cuts in work force. While all are welcome to their opinion, it's sometimes hurtful to comment about the possible reasons with ABSOLUTELY no knowledge of the reasoning behind the cuts. This applies to many recent posters. The nature of publicly traded companies (and perhaps the capitalist system in general) results in cuts in work force under certain market conditions whether it's Xilinx, GM, or your neighborhood grocery store. Ugly truth. Talking about why we think this unfortunate turn occurred does nobody any justice. I was fortunate to leave my previous company before their "first ever" job cuts. I've been present while Voluntary Reductions in Force (VRIF) claim many veterans I've known and seen a RIF sincerely affect the moral of the groups subjected to this involuntary form. Reductions come for reasons that are rarely obvious to those affected directly. It's toughest for the employees who care deeply for their company and their coworkers. My heart goes out to those who are dealing with the agony or angst that comes with such a huge change. In the end - if done right - job cuts in general may help to improve the company in the long run. The short term can simply hurt, especially for those who are cut or work directly with those who lost their jobs. - John_HArticle: 132738
fazulu deen wrote: > Hai, > > > I am pretty clear about cutoff and sampling frequency of FIR filter. > > Wat r all the FIR filter constraints to be considered to set FPGA > clock frequency before targetting to FPGA device? > > I guess i should consider maximum number of taps and maximum sampling > frequency used by the FIR filter...am i correct? > > can i implement a FIR filter of 256-taps(all the taps clocked > synchronously),1Ghz cutoff frequency,2.5GS/s with a input FPGA clock > frequency of 250Mhz? > > pls clarify this. > > regards, > faza It appears you *aren't* "pretty clear about cutoff and sampling frequency." From your discussion so far, it seems that you don't know (and therefor respect) the breadth of filter requirements from audio, through video, to RF systems and the myriad of other applications in between. You appear to want to design a digital filter that is all things to all people. It can't be done. No one design will satisfy all needs. It further seems that you don't know the fundamentals of signal processing to understand what a "Nyquist frequency" is or how it affects what you're trying to accomplish. It's like someone who doesn't know how to multiply wanting to take up calculus. As an electrical engineer with knowledge on how to wash clothes, I would never try to design a clothes washer that should accomodate single users in mobile homes to industrial-sized operations like hotels. First, I'm not an appliance designer though I know how to cut metal and drill holes. Second, I have the foresight to understand that I *cannot* provide a solution that will meet the demands of such a broad spectrum of designers. I'd suggest you simply abandon your quest since it appears that you have no direction available to you except for 1)your knowledge that there is such a thing as an "FIR filter" and 2) the professionals, students, and hobbyists that frequent this newsgroup. If you had an idea of the scope and knew the underlying fundamentals, I'd encourage you. You are starting from SO FAR off from where you need to be that I'd encourage taking up a very different pursuit. Perhaps a summer of reading up on signal processing? Good luck in wherever life takes you, - John_HArticle: 132739
"John_H" <newsgroup@johnhandwork.com> wrote in message news:9be1f653-d8ef-4047-98c1-ed053d466c6c@c58g2000hsc.googlegroups.com... > Reductions in Force (VRIF) claim many veterans I've known and seen a > RIF sincerely affect the moral I've seen that as well, but to a smaller extent than to morale.Article: 132740
"John_H" <newsgroup@johnhandwork.com> wrote in message news:f9cf11ec-b05f-48f6-b576-786738cbe6f1@k13g2000hse.googlegroups.com... > It appears you *aren't* "pretty clear about ... I hesitate to say anything here. I agree with all you said, except in tone, with which I can't disagree more. And while I cherish intellectual curiosity, I also am in no position to even toy with volunteering to be an online mentor. So, ... > If you had an idea of the scope and knew the underlying fundamentals, > I'd encourage you. You are starting from SO FAR off from where you > need to be that I'd encourage taking up a very different pursuit. > Perhaps a summer of reading up on signal processing? > > Good luck in wherever life takes you, Addressed elsewhere in this NG today, I believe. Good luck, Faza.Article: 132741
Hello again, Just to update on the Actel story : I have finally successfully created a (simple combinatorial) VHDL design, compiled it and run it on the A3P250 board. I feel so relieved... It's still a terrible SW pain, but at least i can try some stuffs. ygArticle: 132742
MikeWhy wrote: > "John_H" <newsgroup@johnhandwork.com> wrote in message > news:9be1f653-d8ef-4047-98c1-ed053d466c6c@c58g2000hsc.googlegroups.com... >> Reductions in Force (VRIF) claim many veterans I've known and seen a >> RIF sincerely affect the moral > > I've seen that as well, but to a smaller extent than to morale. You noticed I had a typo. Damn those decades of English education!Article: 132743
On Jun 5, 11:47 pm, Matthew Hicks <mdhic...@uiuc.edu> wrote: > I can think of a few obvious reasons why Xilinx would fire and hire at the > same time. One, they probably cleared-out some of the middle management > fluff that comes with a company of Xilinx's size. This would explain why > they are still trying to hire for technical positions. Two, new hires tend > to be cheaper than veteran employees are. Three, new hires, on AVERAGE, > are more productive than more established employees. I have never heard this before. Where did you get this info? I would expect just the opposite. New hires are very unproductive for some period of time while they adjust to the unique methods of a different company and they learn all of the corporate culture. I am always amazed at how much of the knowledge in a company is passed on by oral tradition. If you shipped off all of the current employees and replaced them with new, most companies would cease to exist. Maybe that is a bit extreme, but I know of a company that had more than half the employees with less than 1 year of tenure. It was a real cluster ****. No one knew anything for sure and it always took way too long to get anything done because it was always pulled in 10 different directions from no one knowing what to expect from the others. > Four, new people bring > new ideas; Xilinx already has the good ideas from the people they fired. I don't agree with this either. Most "new" ideas are not brought with people, they are created in response to the need of a situation. If your statement were true, then all those people fired would be bringing "new" ideas to the next companies they joined. > Five, firing can be used to eliminate the replication of ideas and services > provided by a company's work force. Why does Austin need x employees who > only know a strict subset of what he knows? He may have to do more work, > but the company should save money in the end. Yes, that is a valid point. Surely Austin can't do the work of the people laid off around him, but the work that doesn't get done is likely less of an impact on the company than the dollars saved... at least in the short term. In the long run, this sort of thinking can cause the loss of customers and lowered revenues. RickArticle: 132744
Are you using the 88E111 Marvell PHY by any chance because I remember seeing GTX_CLK etc.. Anyways GTX_CLK and RX_CLK on the PHY are inputs to the FPGA .But you need XTAL for the PHY. You can look at the EDK reference design for ML505 too... --parag On Jun 5, 12:29 pm, chrisde...@gmail.com wrote: > Hi Parag, Aiken, > thanks for your inputs. They are very helpful. > > Hi Parag, > when i mean clock generator, i mean the EDK clock generator module > which generates clocks on board the FPGA using DCMs, deriving clocks > based on what the user wants. will look at ML505 and ML506 reference > designs. > > thanks again > ChrisArticle: 132745
"John_H" <newsgroup@johnhandwork.com> wrote in message news:SaqdnTwBMvMmFNXVnZ2dnUVZ_qninZ2d@comcast.com... > MikeWhy wrote: >> "John_H" <newsgroup@johnhandwork.com> wrote in message >> news:9be1f653-d8ef-4047-98c1-ed053d466c6c@c58g2000hsc.googlegroups.com... >>> Reductions in Force (VRIF) claim many veterans I've known and seen a >>> RIF sincerely affect the moral >> >> I've seen that as well, but to a smaller extent than to morale. > > You noticed I had a typo. Damn those decades of English education! If it matters, I was responding to the unintended irony. No offense or slight intended.Article: 132746
I can think of a few obvious reasons why Xilinx would fire and hire at the same time. One, they probably cleared-out some of the middle management fluff that comes with a company of Xilinx's size. This would explain why they are still trying to hire for technical positions. Two, new hires tend to be cheaper than veteran employees are. Three, new hires, on AVERAGE, are more productive than more established employees. Four, new people bring new ideas; Xilinx already has the good ideas from the people they fired. Five, firing can be used to eliminate the replication of ideas and services provided by a company's work force. Why does Austin need x employees who only know a strict subset of what he knows? He may have to do more work, but the company should save money in the end. ---Matthew Hicks > On Jun 5, 12:09 pm, Frank Buss <f...@frank-buss.de> wrote: > >> rickman wrote: >> >>> There are just some posts that are better left without responses. I >>> think Frank's was one of those. >>> >> I don't see what was wrong with my post, I just explained why big >> companies needs new people all the time. And Peter's comment is >> right: a company can't stop hire people, because if someone like >> Peter would leave the company, someone from accounting can't replace >> him. >> >> -- >> Frank Buss, >> f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de > I don't think there was anything "wrong" with your post. I just don't > think that Peter's response was at all helpful to Xilinx and I don't > know that it "needed" a response at all. You stated an observation. > Xilinx has its reasons for what it did. Since none of us know what > those reasons were, including Peter most likely, there is no point in > trying to justify or condemn Xilinx for not meeting our > expectations. > I would rather condemn Xilinx for its marketing decisions if anything. > They certainly don't meet my expectations there... ;^) > > But to your argument, I don't agree. It is very often that a company > will simply put out a hiring freeze rather than a layoff, partly > because it is much cheaper! Layoffs mean an immediate reduction in > paychecks, but at the expense of several weeks of severance pay and > potentially higher unemployment insurance rates. A hiring freeze > costs next to nothing and does allow for filling positions that are > the exception. Let's face it, this is not the government, they will > do what makes the most sense to them including violating their own > rules if needed. > > Although you can't replace Peter with someone from accounting (at > least we can assume that) I am sure that Xilinx has any number of good > engineers who *can* take over his duties. Yes, I expect there will be > some loss of productivity in the company overall, but that is the > goal, to reduce productivity (as little as possible) to bring expenses > in line with expected revenue. > > If I had to guess, I would say that the layoffs were not in reaction > to a bad quarter, but because of the darkening clouds on the horizon > of coming quarters. A company can always ride out a single quarter or > even a single year. It is the long term perspective that causes > layoffs. > > Perhaps Xilinx senses a change of sea state... a new paradigm coming? > > Rick >Article: 132747
I disagree; however, I would include 'pipelining' as part of the coding style/trick. You can also try to code such that the critical path(s) with have small enough blocks of logic between flip-flops to enable timing closure. You may add attributes to signals to try to coerce the synthesizer into doing 'the right thing'; if it doesn't come automatically, you might do some low-level coding, synthesize that, and then use the resultant edif file as a black box to the the next level up. Before troubling with all that, though, do some bottom-up evaluations, particularly of things you feel will have trouble meeting timing. The tools will often produce sub-optimal solutions when trying to solve many simultaneous, conflicting requirements (resource location, timing, ...), and thus have trouble for the total design. Generally, the timing performance achieved at the chip level is less optimal that at the block level, so make sure your blocks will meet timing. If they do, and the whole doesn't, you might try incremental design techniques, where you solve one problem, build on it for the next, etc... If they don't, you can try re-coding and/or re-architecting to get the block(s) to meet timing, and then try the whole. Solve the relatively simple problems first... and sometimes the big problems become simple. Other (non-coding) tricks: location constraints, multi-cycle constraints, ... JTW "KJ" <kkjennings@sbcglobal.net> wrote in message news:kOY1k.3933$89.3886@nlpi069.nbdc.sbc.com... > > "JeDi" <jaydev.shelat@gmail.com> wrote in message > news:5927360c-b4ca-488f-9019-cee1a0ed569f@a9g2000prl.googlegroups.com... >> >> So, my question is regarding Verilog HDL coding - Is there any >> recommended coding style which improves timing closure (or in other >> words makes it easier for the tools to meet timing ) ?? >> > > No, there are no 'coding styles' in any language that will do anything to > improve clock cycle performance. > > To improve timing you change your design to pipeline the processing. To > pipeline you break up a 'big' computation (i.e. one that takes a long time > and therefore becomes a critical timing path) into smaller ones that take > multiple clock cycles. > > Kevin Jennings >Article: 132748
SiliconBlue Pioneers New FPGA Technology for Handheld, Ultra-Low Power Applications Monday, SiliconBlue(tm) announced a revolutionary new class of single-chip, ultra low-power FPGA devices that set a new industry standard for price, power and space along with unprecedented ASIC-like logic capacity for battery-powered, handheld consumer applications. Manufactured on TSMC's 65nm LP (low-power) standard CMOS process, the new single-chip iCE(tm) family of FPGAs incorporate the company's proprietary NVCM (Non-Volatile Configuration Memory) technology, eliminating external flash PROM costs while making it easy-to-use. For more information, please visit www.siliconbluetech.com Press Release: http://www.siliconbluetech.com/docs/press/news060208.htm Brochure: http://www.siliconbluetech.com/media/iCE65Brochure.pdf iCE for Handhelds: http://www.siliconbluetech.com/ice_handhelds.html iCE Die Products: http://www.siliconbluetech.com/ice_vendors.html iCECUBE Design Software: http://www.siliconbluetech.com/designtools.html iCEman65 Evaluation Kit: http://www.siliconbluetech.com/iCEman65/index.htmlArticle: 132749
Hi, beeraka@gmail.com wrote: > Are you using the 88E111 Marvell PHY by any chance because I remember > seeing GTX_CLK etc.. Anyways GTX_CLK and RX_CLK on the PHY are inputs > to the FPGA .But you need XTAL for the PHY. You can look at the EDK > reference design for ML505 too... It's not documented, but you can drive the ll_temac MGT_CLKP from an internally derived DCM clock (external differential clock not required). However, there is a special magical XIL_... setting that you need to get through DRC. export XIL_MAP_NO_GT_CLKIN_DRC=1 Hope this helps, John
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