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
Your posts are thought provoking if not very accurate. You seem to have formed some personal opinions, but offer no real evidence to support them. The one thing I have observed about layoffs as well as hiring is that it more resembles Brownian motion than anything else. A company tries to bias the motion in a positive direction, but it is mostly just random changes. This is in no small part because managers have very poor insight into what is really good or bad for a company. If a company has inefficient programs or workers, they don't need layoffs to get rid of them. Once identified, inefficiency can be easily dealt with. Forced firings (layoffs) are no different than chopping off a limb because a person is overweight. It solves the immediate problem, but doesn't really solve the long term issue. Whenever there is a problem with a company, it is *always* due to management. The workers have very little control over the fate of a company. If it were any other way, management would not be doing their jobs! If I told you of a great new company to invest in and you found that the workers all had total control over the success or failure of the company, would you invest in it? So don't say mass firing is a good thing in any way other than reducing the payroll. That is their sole purpose and any other benefit is just due to random chance. Rick On Jun 6, 5:11 am, Matthew Hicks <mdhic...@uiuc.edu> wrote: > > 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. > > I knew my statements would be contentious due to their brashness. In the > real world, it's not that simple, and my comments really pertain to companies > in the growth (R&D) phase. A company keeps its most experienced people around > to teach and lead the new hires. That way, stuff gets done and ideas flow > from the top directly to the bottom (no middle-men to muddle things up). > Yes, a company will have reduced productivity for a couple of months, but > will have an overall increased productivity in the long term. All at a lower > cost, leading to increased profits. Doing this also allows for a change > of "corporate culture", if required. After a few months, the new hires will > be at the same place in current projects that the fired employees were. > The difference is new hires, generally younger, have more time to put into > the job and feel they have more to prove, and hence work harder. More established > workers, generally, have families and a sense of entitlement. This means > they tend to work less (and less efficiently), have other stuff to think > about than their work problems, and aren't motivated to expand their knowledge > base. > > In my work interning and consulting, I've found that I can get up to speed > on the culture, tools, development process, etc. in less than three months. > I also found that longer-term workers spent more time not working (talking, > internet, ...) and were less likely to adopt new design processes or learn > new technologies. Of course, there are exceptions to every rule, ala Peter > and Austin, but I'm mainly writing about mid-level workers. > > > > > > >> 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. > > > Rick > > Lost revenues aren't necessarily bad. If it costs a company more money than > it makes to get the revenue, lose the revenues and gain the net profit. > > All of this is the beauty of the capitalist system, it's too bad most CEOs > and government leaders doesn't understand how to use it. If done right, > in the end, the layoffs will be good for not only the company but for those > fired. If forces both the company and those fired to re-evaluate their position > in the market, resulting in better products and more motivated, possibly > better trained employees. > > ---Matthew HicksArticle: 132776
On Thu, 05 Jun 2008 08:39:39 -0700, austin <austin@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). > >They have a number of ex-X employees working there. > >Good luck guys (I mean it)! > >Austin There was something in one of the trade mags this week about this - they claim the OTP uses 2% of the die - I think it was a TSMC process called something like oxide disruption The big selling point appears to be low power draw - tens of uA at 32KHz and a <10mA at 200MHz filled with counters. ISTR. There are some datasheets up at : http://www.siliconbluetech.com/ Nothing about how/where/when to buy though....Article: 132777
On 6 Jun., 14:42, PFC <li...@peufeu.com> wrote: > > No, that wasnt the case. > > I found out something interesting. When I touch the TDO signal with > > the oscillscope probe, the ID check and programming works!!!! And I > > think the probe induced a small parallel capacitance to GND that made > > this work. I have never found anything on this on xilinx application > > notes. The question is now what capacitance value is the best? > > Oh yeah I forgot : last time this happened to me it was because the > pressure I exerted while probing did restore the contact in the faulty > flat cable connector... Thanks for the feedback. But in my case it was definatly the capacitor. I added a 100pF from GND to TDO on the JTAG programmer side and it worked. The cable is less than 30 cm and the frequency is 3/6 MHz. The JTAG programmer or Xilinx FPGA must be really sensitive.Article: 132778
On 6 Jun., 15:29, jid...@hotmail.com wrote: > On 6 Jun., 14:42, PFC <li...@peufeu.com> wrote: > > > > No, that wasnt the case. > > > I found out something interesting. When I touch the TDO signal with > > > the oscillscope probe, the ID check and programming works!!!! And I > > > think the probe induced a small parallel capacitance to GND that made > > > this work. I have never found anything on this on xilinx application > > > notes. The question is now what capacitance value is the best? > > > Oh yeah I forgot : last time this happened to me it was because the > > pressure I exerted while probing did restore the contact in the faulty > > flat cable connector... > > Thanks for the feedback. But in my case it was definatly the > capacitor. I added a 100pF from GND to TDO on the JTAG programmer side > and it worked. The cable is less than 30 cm and the frequency is 3/6 > MHz. The JTAG programmer or Xilinx FPGA must be really sensitive. What I want to understand, is why only the TDO signal? And if 30 cm was long or the cable was bad quality, then why didnt I see any distortions on the signals coming from the JTAG programmer?Article: 132779
On Jun 5, 11:34 am, austin <aus...@xilinx.com> wrote: > OK, > > What about the press release did you not get? > > We reorganized from a business unit structure, to a functional unit > structure. > > We recognized the need to be more efficient, and serve our customers better. > > Get it? ...snip... > Austin Obviously tact with customers was not one of the criteria used to decide who to layoff. ;^) BTW, this idea of business unit vs. functional unit, that is exactly the sort of Brownian motion stuff I mentioned in my other post. Management has to do something. So they rearrange the furniture. Then if a new customer walks in the door and buys something they can say it is working. I find management is a lot more effective if they focus on the realities of running a business rather than the superficial aspects. Expenditures is one of those realities. Cutting payroll is a good short term solution to the need to reduce expenditures. But it has to be combined with other changes that produce long term improvements... changes other than decor. RickArticle: 132780
Hi there, I'm designing a PCB that incorporates a Virtex4 FX60 with 16 RocketIOs. All RocketIOs function only as a receiver and I wonder if you should care for length compensation on my FR4 board, anyway. The reason I am not sure is that in my opinion each RocketIO synrchonizes itself independently on the incoming data stream since I am using 8B/10B coding. If this is true I could save myself a lot of useless work... :-) Regards JoeArticle: 132781
rickman wrote: > > Obviously tact with customers was not one of the criteria used to > decide who to layoff. ;^) <snip> "I'm being completely disrespectful - possibly even hurtful - but it's okay because I'm winking." Please let us know when a tragedy strikes close to your own heart. ;-) <snip> > BTW, this idea of business unit vs. functional unit, that is exactly > the sort of Brownian motion stuff I mentioned in my other post. > Management has to do something. So they rearrange the furniture. > Then if a new customer walks in the door and buys something they can > say it is working. I find management is a lot more effective if they > focus on the realities of running a business rather than the > superficial aspects. <snip> I agree that this kind of realignment is superfluous. Businesses tend to vasciallate between functional orientation and product orientation, reorganizing to the other side of the fence every several years. Bizarre behavior in this engineer's eyes but it's the way things often go. <snip> > Expenditures is one of those realities. Cutting payroll is a good > short term solution to the need to reduce expenditures. But it has to > be combined with other changes that produce long term improvements... > changes other than decor. > > Rick I agree that mass job cuts do little more for the business than to affect the stock price in the near term. The human cost is large. If any one company's layoffs are better than the "brownian motion" you suggest, then the long term benefits might be felt, but at a large human cost. The business cycle has regular boom and bust periods but tends to come out better over each cycle. It's just sad that it comes at such a cost. - John_HArticle: 132782
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:48474632$1@clear.net.nz... > [snip] > > Anyone actually got some devices/tools ? > > -jg FULL DISCLOSURE: We've had access to the iCE65 devices and iCECUBE design tools since about February because we worked on a few aspects of the evaluation kit and on both the data sheet and evaluation kit user guide. We were compensated for the opportunity so I'm not completely impartial. I worked primarily with the alpha and beta releases, mostly on Linux although there is a Windows version available now. All of my work used the iCEman65 evaluation kit which includes the iCE65L04 device with about 3,500 logic cells and 80Kbits on it. I can compile most VHDL and Verilog code without too much effort because the iCECUBE tools are based around the Magma BlastFPGA synthesis package. The architecture is a traditional 4-input look-up table although the block RAM and carry logic is slightly different, likely to reduce power consumption. Run times on the beta versions weren't as peppy as I'd hoped, but they weren't obnoxiously slow either. The floor planner works but could still use a little more sophistication. I was running the betae Linux version under VMware on a Vista laptop. The beta version was certainly no worse than some of the production software we use. The iCE65L04 part on the evaluation board exclusively loads from SPI Flash or can be downloaded. The part on the board doesn't have the Nonvolatile Configuration Memory (NVCM) in it. The board is powered over USB and you can program the SPI Flash and iCE65 device over USB. The low-power nature of the parts are truely amazing. I don't know how many times I thought I blew a fuse because there was no current flowing to the board (okay, there actually was current flowing but the analog meter on my cheap bench supply has too wide a range to see it). I had to keep reminding myself that at 32 KHz, the _active_ power consumption is below 50 uA. With a good quality multimeter, I only measured about 27 uA, but that's for a single part at room temperature, nominal voltage). But hey, that's a good two to three orders of magnitude smaller than the _static_ power on the other devices we normally use. The 27 uA didn't require any special standby modes--that's active power at 32 KHz! I also did a few projects that ran at 32 MHz, which is included on the board, and at 19.2 MHz. Both were about 75-80% full designs that consumed 11 mA and 6 mA active current respectively on the 1.2V supply. That's without power optimizing the design. The great thing about the part is that if something doesn't move, it doesn't burn power so power-aware design really pays off as well. I haven't tried speed stressing the part yet either but the 32 MHz design had plenty of margin. Most of the low-power projects we do use the lowest clock rate possible in order to minimize power. In terms of I/O, there are four different I/O banks (five if you include the SPI bank, which has its own supply input). Three of the banks support 3.3, 2.5, or 1.8V LVMCOS I/O and are even 5V-input tolerant. One of the banks skips the 3.3V LVCMOS standard but adds SSTL25, SSTL18, and LVDS I/O while keeping 2.5 and 1.8V LVCMOS. Each bank also has an input-disable and you can individually control which inputs are controlled by the disable. This keeps external switching from causing unnecessary power consumption. In terms of samples, I know that the iCE65L04 is available in both the 284-ball 0.5 mm BGA and in the 132-ball 0.5 mm BGA. There's a button the front page of the SiliconBlue web site (www.siliconbluetech.com) to request samples. -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 132783
Hi, I'd like to use an Intel StrataFlash Memory 28F320J3A with my Virtex4 FPGA and write / read data from it. Is there a ready-to-use core available to communicate with the Flash or am I supposed to start from the scratch, writing VHDL code line by line. Does anybody know how complicated this can get? Is it something sophisticated or just "line production"..?! ;-) Greetz JoeArticle: 132784
PFC <lists@peufeu.com> wrote: >> If you are going to do multi-channel audio, Xilinx may have the >> advantage that you can use the LUTs as 16x1 memory instead of >> flipflops. If you want to process up to 16 channels, you can use luts >> as temporary storage for filter results etc. The space savings can be >> huge. > > For the FIR I will probably use some BRAM but I was looking into this the >other day and I really like the tiny FIFOs you can make with the Xilinx >parts. Very useful for me ! I can instantiate one FIFO per channel using >very little slices and it greatly simplifies my data flow. And the SRLs >are nice to make audio I²S encoders, too. > Why FIR? AFAIK it takes less logic to implement an IIR filter. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 132785
"Thomas Stanka" <usenet_nospam_valid@stanka-web.de> wrote in message news:2f2be3f7-bd57-4c94-b4da-063552cd2e2f@79g2000hsk.googlegroups.com... > On 5 Jun., 17:39, austin <aus...@xilinx.com> wrote: > [snip] > > 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 on-chip memory is something that SiliconBlue calls Nonvolatile Configuraiton Memory (NVCM). It's nonvolatile like Flash but doesn't require any special processing or extra metal layers. It's based on the technology they acquired from Kilopass. The advantage for SiliconBlue is that they're already on a 65 nm process. Most programmable logic parts that use Flash are typically back a few generations because of the special processing and qualification necessary. If I remember correctly, the Lattice parts are Flash based. Both technologies have the pros and cons. -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 132786
Hi all, Does anybody know a good source for a single wire cable which allows me to connect two 0.1" header pins (IDC connectors, JTAG pins etc)? I scanned the web/eBay but only found one source in the US (end of page, 1 Pin MTE Cable), http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable Unfortunately shipping to the UK is a bit expensive for just a few short wires so I wonder if anybody else knows where to get them from. Thanks, Hans. www.ht-lab.comArticle: 132787
Hi jtw !! "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." I tried pipelining - mainly to break large combinational blocks into smaller ones. But, the problem I run into is that the logic utilization increase almost 15-20 % more than the already high utilization !!! This creates a situation where the tool is not able to place everything close enough to meet timing - because the interconnect delay of the FPGA now becomes the bottle neck !!! " 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" This is what I am trying to do now and seeing what impact does this have - fingers crossed !!! Thanks for the suggestion though. "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. Other (non- coding) tricks: location constraints, multi-cycle constraints," So true !! I have seen exactly this - block level everything is fine .. but chip level ... performance starts deteriorating !! I have tried the resource allocation and timing constraints also. Though these improve the frequency a little, I think the biggest constraint comes from the very high logic utilization and hence the tool is not able to concentrate its efforts efficiently !!! However, I am working on a few things ... lets see if the efforts pay dividends !!! Thanks for the suggestions. If you come across anything else, please point it to me !! JeDiArticle: 132788
What's the difference between target and the result freq.? On Jun 6, 12:48=A0pm, JeDi <jaydev.she...@gmail.com> wrote: > Hi jtw !! > > "I disagree; however, I would include 'pipelining' as part of the > coding style/trick. =A0You 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." > > I tried pipelining =A0- mainly to break large combinational blocks into > smaller ones. But, the problem I run into is that the logic > utilization increase almost 15-20 % more than the already high > utilization !!! This creates a situation where the tool is not able to > place everything close enough to meet timing - because the > interconnect delay of the FPGA now becomes the bottle neck !!! > > " 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" > > This is what I am trying to do now and seeing what impact does this > have - fingers crossed !!! Thanks for the suggestion though. > > "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. =A0Generally, the timing > performance achieved at the chip level is less optimal that at the > block level, so make sure your blocks will meet timing. Other (non- > coding) tricks: =A0location constraints, multi-cycle constraints," > > So true !! I have seen exactly this - block level everything is > fine .. but chip level ... performance starts deteriorating !! I have > tried the resource allocation and timing constraints also. Though > these improve the frequency a little, I think the biggest constraint > comes from the very high logic utilization and hence the tool is not > able to concentrate its efforts efficiently !!! However, I am working > on a few things ... lets see if the efforts pay dividends !!! > > Thanks for the suggestions. If you come across anything else, please > point it to me !! > > JeDiArticle: 132789
On Thu, 5 Jun 2008 09:48:45 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >On Jun 5, 9:14 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> On Wed, 4 Jun 2008 12:44:03 -0700 (PDT), rickman <gnu...@gmail.com> >> >> 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 think what rickman was trying to remember was the 'Common User >Access' or 'CUA' developed by IBM. > >http://en.wikipedia.org/wiki/Common_User_Access Probably was; that makes more sense. All I could find searching for Microsoft and CUI (or Common User Interface) was that healthcare stuff. - BrianArticle: 132790
On Jun 6, 11:42 am, "Denkedran Joe" <denkedran...@googlemail.com> wrote: > Hi, > > I'd like to use an Intel StrataFlash Memory 28F320J3A with my Virtex4 FPGA > and write / read data from it. Is there a ready-to-use core available to > communicate with the Flash or am I supposed to start from the scratch, > writing VHDL code line by line. > > Does anybody know how complicated this can get? Is it something > sophisticated or just "line production"..?! ;-) > > Greetz > > Joe If you have EDK, there is a core readily available with it: the EMC: External Memory Controller. It's worked flawlessly for every external discrete flash part I've used it with. -- MikeArticle: 132791
Andrew Smallshaw <andrews@sdf.lonestar.org> writes: > 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. Who considers anything but the "latest and greatest" to be outdated? This group is supposedly intelligent and familiar enough with computing to make decisions about "upgrading". If newer products don't offer anything in valued improvements, ignore them. > 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.Article: 132792
"Denkedran Joe" <denkedranjoe@googlemail.com> wrote in message news:4849588d$0$7554$9b4e6d93@newsspool1.arcor-online.net... > Hi there, > > I'm designing a PCB that incorporates a Virtex4 FX60 with 16 RocketIOs. > All RocketIOs function only as a receiver and I wonder if you should care > for length compensation on my FR4 board, anyway. The reason I am not sure > is that in my opinion each RocketIO synrchonizes itself independently on > the incoming data stream since I am using 8B/10B coding. If this is true I > could save myself a lot of useless work... :-) > > Regards Joe > Hi Joe, You don't need to worry about making all the differential pairs equal in length. Of course, each trace in a pair should match length. If you need to synchronise between lanes, use something like XAUI. HTH., Syms.Article: 132793
On Jun 6, 8:42 am, "Steve Knapp" <steveD.O.TknappA.Tprevailing- technologyD.O.Tcom> wrote: > FULL DISCLOSURE: We've had access to the iCE65 devices and iCECUBE design .... > The great > thing about the part is that if something doesn't move, it doesn't burn > power so power-aware design really pays off as well. Thanks, this is pretty interesting. A quick question, can the PLLs be reconfigured dynamically? TommyArticle: 132794
"Aiken" <aikenpang@gmail.com> wrote in message news:0eaf6519-6902-42c2-8686-79be14ba6ba8@t54g2000hsg.googlegroups.com... >>What's the difference between target and the result freq.? What yer want v. what yer getArticle: 132795
On Jun 6, 12:48=A0pm, JeDi <jaydev.she...@gmail.com> wrote: > Hi jtw !! > > I tried pipelining =A0- mainly to break large combinational blocks into > smaller ones. But, the problem I run into is that the logic > utilization increase almost 15-20 % more than the already high > utilization !!! Then you have the following options (in no particular order): 1. Choose a faster speed grade part. 2. Choose a larger part and keep pipelining. 3. Design better algorithms that can be implemented with better performance. 4. Slow the clock down > " 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" > > This is what I am trying to do now and seeing what impact does this > have - fingers crossed !!! Thanks for the suggestion though. > Unless you're just missing by a little bit, don't expect to attribute your way to happiness, you'll most likely be sadly disappointed...after spending a (possibly) considerable amount of time trying to get it to work. Uncross your fingers, let the blood flow through and go back to one of the four suggestions given previously...or give it the old college try and hope for the best. > "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. =A0Generally, the timing > performance achieved at the chip level is less optimal that at the > block level, so make sure your blocks will meet timing. Other (non- > coding) tricks: =A0location constraints, multi-cycle constraints," > > So true !! I have seen exactly this - block level everything is > fine .. but chip level ... performance starts deteriorating !! I have > tried the resource allocation and timing constraints also. Though > these improve the frequency a little, I think the biggest constraint > comes from the very high logic utilization and hence the tool is not > able to concentrate its efforts efficiently !!! However, I am working > on a few things ... lets see if the efforts pay dividends !!! > Saying that each block has good performance but tying them all together is a problem caused by 'sub-optimal' placement is without any basis. While it could be a contributor, the most likely cause is not the synthesis tool but the algorithm you're trying to implement. Look at your worst case timing path. If you see it going through a whole bunch of levels of logic, then it's not the synthesis tool's poor placement, it's your logic. If you see only one or two levels of logic and unreasonably long delays then it is either the synthesis tool (as you suggest) or you have an unrealistic expectation of what kind of clock speed you can expect to run at. Good luck Kevin JenningsArticle: 132796
Everett M. Greene wrote: > Andrew Smallshaw <andrews@sdf.lonestar.org> writes: > >> 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. > > Who considers anything but the "latest and greatest" to be > outdated? This group is supposedly intelligent and familiar > enough with computing to make decisions about "upgrading". > If newer products don't offer anything in valued improvements, > ignore them. It's not that simple. Others upgrade, then you can't read what they send you. MS sees to that. >> 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. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 132797
On Fri, 6 Jun 2008 17:48:14 +0100, "HT-Lab" <hans64@ht-lab.com> wrote: >Hi all, > >Does anybody know a good source for a single wire cable which allows me to >connect two 0.1" header pins (IDC connectors, JTAG pins etc)? I scanned the >web/eBay but only found one source in the US (end of page, 1 Pin MTE Cable), > >http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable > >Unfortunately shipping to the UK is a bit expensive for just a few short >wires so I wonder if anybody else knows where to get them from. Easy (and cheap) to make your own. You'll need some stranded hook-up wire, a bit of shrink tube for each end to cover the connector, and a bag of connectors like Molex 16-02-0102 (tin, there's also gold plated available). An example (on this side of the pond) at: <http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=WM2510-ND> After crimping, push down the little tab that would normally be used to secure the connector into a plastic housing. Not absolutely necessary but its function won't be needed and there's a chance it could eventually wear through the shrink tube if left poking up. -- Rich Webb Norfolk, VAArticle: 132798
Jonathan Bromley wrote:
> Consider this example: Someone says to me that
> they want advice on how to build a staircase.
> In particular, they want the staircase to
> rise by 30 metres, and to have exactly 15 steps.
> I point out that this would require each step
> to be 2 metres high, and the response comes
> back "Each step is to be 20cm high".
> How do I respond intelligently to that?
Perhaps the staircase could be
accelerated to an appropriate velocity. ;)
L_v := L*(1-v**2/c**2)**0.5 ;
-- Mike Treseler
Article: 132799
Stef wrote:
> Why should that be a signal? control_state_v is my state variable and is
> declared (not visible in the fragments) and used only in the clocked
> process.
There is nothing wrong
with a state variable instead of signal.
When sim and synth don't match the
problem is often missing synchronization
or some sneaky asynch path.
I would bet that datain
is not synchronized to clock.
-- Mike Treseler
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