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
Steve Knapp wrote: > > "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. So it can self-load from SPI, which means a SPI part allows more-frequent design revisions, at an incremental cost ? 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. Thanks, interesting info. Do you have a silicon errata sheet ? Did anyone mention the OTP programming times, and OTP yields, and if any special voltages/profiles are needed ? -jgArticle: 132801
In comp.arch.fpga, Mike Treseler <mike_treseler@comcast.net> wrote: > 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. Phew, that was what I thought as well. ;-) > When sim and synth don't match the > problem is often missing synchronization > or some sneaky asynch path. As far as I know, there are no async paths in the design. Except for one async reset for a ripple counter that only controls an LED and that one is reported by synthesis. > I would bet that datain > is not synchronized to clock. No, datain is synchronized (it's internally generated, receive data from uart like device). The whole design runs on a single clock (except for the upper stages of said ripple counter) and all inputs are synchronized with that clock with 2 or more DFF's -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)Article: 132802
"Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message news:4b62488d7f7e38ca96313dd4f44a@news.ks.uiuc.edu... > Wow, you're omniscient now. Yes, I am a graduate student, but I've > seen/worked with graduate students of all different ages and levels of > experience. So coming from an .edu domain means nothing. > I'm not kicking anyone, I don't have anything invested in those that got > fired, I've been "let-go" before for less reason, that's life. These > people will all find another job, it may not be easy, but it won't be > devastating either. > > > > ---Matthew Hicks > Hey Matt, Imagine this future interview scenario. Interviewer: Hello Matt, nice to meet you. Matt: Hello. Likewise. Interviewer: As background to help you answer this question, I was laid off from my middle management job at a major FPGA company N years ago. Although a poster on comp.arch.fpga thought the layoff wasn't devastating, it wasn't easy either, but I found a new career here at NewCo. I was motivated to become head of recruitment in case a particular person's CV turned up. Now, almost as if I was omniscient, it has. I'd like you to explain what is meant by the phrase "some of the middle management fluff that comes with a company of Xilinx's size" ? Matt: I'll get me coat. For sure, although the interview above may not be easy, it won't be devastating either. The interviewee will find another job. Do you see now how you might have something invested in those guys? Google has a long memory. I expect you noticed that people quoted your post. Good luck mate, Syms.Article: 132803
On Jun 6, 2:13 pm, moja...@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote: > Andrew Smallshaw <andr...@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. You seem naive. I am very happy with Windows 2000 on my desktop computer. If I build another it will also run Windows 2000. But if I want a laptop, I won't have much choice but to run Win XP (for the next few weeks) or Vista. I only wish I had a choice. RickArticle: 132804
On Thu, 5 Jun 2008 00:45:57 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >http://www.edn.com/article/CA6566989.html > > My condolences to the folks who've been laid off, of course, but also to the folks left behind. I've worked at two companies that had first-time layoffs while I was there, and the effect was pretty wrenching to the collective psyche. Here's hoping that this is the last time the good people of Xilinx have to go through this. Bob Perlman Cambrian Design Works http://www.cambriandesign.comArticle: 132805
Wow, you're omniscient now. Yes, I am a graduate student, but I've seen/worked with graduate students of all different ages and levels of experience. So coming from an .edu domain means nothing. I'm not kicking anyone, I don't have anything invested in those that got fired, I've been "let-go" before for less reason, that's life. These people will all find another job, it may not be easy, but it won't be devastating either. ---Matthew Hicks > "krw" <krw@att.bizzzzzzzzzz> wrote in message > news:MPG.22b23bc9da169c14989ce4@news.individual.net... > >> 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. >> >> -- Keith >> > ...and even 'one' is repulsive, especially if it was posted by a > student > with time in the workplace. However, I'm sure Matthew is sharing his > vast > experience of layoffs in industry from his .edu email address. > Otherwise, > IMO, he'd be a complete dick for publicly kicking 250 folks going > through > some temporary bad luck. > Syms.Article: 132806
> 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 > Rick, My main point is that intelligent CEOs and managers can actually use layoffs as a tool and that getting fired isn't an entirely bad thing. The problem is most let emotions cloud making sound capitalistic decisions, creating this random back-and-forth drift towards mediocrity. Of course, the emotions of the workers should impact decision making, one reason why firings can be bad. ---Matthew HicksArticle: 132807
rickman wrote: > You seem naive. I am very happy with Windows 2000 on my desktop > computer. If I build another it will also run Windows 2000. But if I > want a laptop, I won't have much choice but to run Win XP (for the > next few weeks) or Vista. I only wish I had a choice. It seems many designers ARE using Win2000, and are happy with the quirks-they-know, and do NOT want to buy into another round of learn-the-quirk. [I have Win2000 here, on 2 machines!] Sadly, not all EDA companies see this, and Win2000 is moving off some radars. Given that XP and expecially Vista, will not install on hardware too out-of-phase with the release date, that will also mean retiring functional PCs to a land-fill somewhere (and those PCs probably pre-date Lead-free)..... I did hear Dell were running XP supply to 2011 (or something like that ? )- because of customer demand, not Microsoft's. -jgArticle: 132808
rickman wrote:
> moja...@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote:
>
... snip ...
>
>> 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.
>
> You seem naive. I am very happy with Windows 2000 on my desktop
> computer. If I build another it will also run Windows 2000. But
> if I want a laptop, I won't have much choice but to run Win XP
> (for the next few weeks) or Vista. I only wish I had a choice.
Seriously consider Linux, especially Ubuntu. You do have a
choice. A better choice.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Article: 132809rickman <gnuarm@gmail.com> writes: > [...] > But if I want a laptop, I won't have much choice but to run Win XP > (for the next few weeks) or Vista. I only wish I had a choice. You do. I have successfully installed Fedora 8 on an HP Pavillion DV9620US. However one thing to be careful of in running linux on laptops is Broadcom's stubborn refusal to open up their wireless card specifications so that open source drivers can be developed. Translated: don't buy a laptop with a Broadcom wireless card (or chipset) if you want to run linux on it. Atheros I've heard is very good and supported by madwifi.org. But, even though Broadcom is stubborn, I have still been successful at getting the card to work on my home network. Unfortunately the reverse engineered drivers (b43-fwcutter...) do not seem to support the Master modes used in public hotspots. -- % Randy Yates % "The dreamer, the unwoken fool - %% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Eldorado Overture', *Eldorado*, ELO http://www.digitalsignallabs.comArticle: 132810
That's one of the downsides of being open and honest, people can use it against you. I'd rather people know where I stand, I can work somewhere else. This isn't the 1950's, employees are assets, I don't feel the need to grovel at the feet of a large company, I feel a company would be lucky to have me. Egotistical, maybe, but I work very hard and I'm good at and enjoy what I do. ---Matthew Hicks > "Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message > news:4b62488d7f7e38ca96313dd4f44a@news.ks.uiuc.edu... > >> Wow, you're omniscient now. Yes, I am a graduate student, but I've >> seen/worked with graduate students of all different ages and levels >> of >> experience. So coming from an .edu domain means nothing. >> I'm not kicking anyone, I don't have anything invested in those that >> got >> fired, I've been "let-go" before for less reason, that's life. These >> people will all find another job, it may not be easy, but it won't be >> devastating either. >> ---Matthew Hicks >> > Hey Matt, > > Imagine this future interview scenario. > > Interviewer: Hello Matt, nice to meet you. > > Matt: Hello. Likewise. > > Interviewer: As background to help you answer this question, I was > laid off from my middle management job at a major FPGA company N years > ago. Although a poster on comp.arch.fpga thought the layoff wasn't > devastating, it wasn't easy either, but I found a new career here at > NewCo. I was motivated to become head of recruitment in case a > particular person's CV turned up. Now, almost as if I was omniscient, > it has. I'd like you to explain what is meant by the phrase "some of > the middle management fluff that comes with a company of Xilinx's > size" ? > > Matt: I'll get me coat. > > For sure, although the interview above may not be easy, it won't be > devastating either. The interviewee will find another job. > > Do you see now how you might have something invested in those guys? > > Google has a long memory. I expect you noticed that people quoted your > post. > > Good luck mate, Syms. >Article: 132811
"KJ" <kkjennings@sbcglobal.net> wrote in message news:f1ac06eb-bd12-4ff5-a9bd-f88d2abb7104@k37g2000hsf.googlegroups.com... On Jun 6, 12:48 pm, JeDi <jaydev.she...@gmail.com> wrote: .. snip.. > "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 !!! > 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 Jennings ----- I have seen specific cases where the synthesizer gets carried away optimizing away redundant logic; e.g., several instances of the same logic. When the individual block is sent through synthesis and then place & route, everything is fine; when the chip, containing multiple copies of the logic, is sent through, the synthesizer perceives (correctly) redundant logic. Unfortunately, in my case it made par work much harder, because of the increase in fanout (more spacing/distribution than number of loads.) When I synthesized the block independently, and then did the top-level sim with the several instances appearing as black boxes, the chip-level place & route improved significantly, achieving timing closure. I often run low-level blocks through preliminary synthesis & par, even when I don't do black-box instantiation, to give me that realistic expectation. I try to find out the limits of performance here, not just that it meets my 'top-level' timing; if it just barely meets at the low-level, I expect trouble later.... It also gives me the opportunity to experiment with different optimization schemes (coding style, re-architecting, synthesis directives, etc.) with a quick turnaround. In many of my designs, some blocks may be used 4 or more times; the more times, the more relevant to optimize for utilization, particularly when pushing the limits (space/routing/speed.) JTWArticle: 132812
"Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message news:4b62488d7f8948ca9649c9a6ca8a@news.ks.uiuc.edu... > That's one of the downsides of being open and honest, people can use it > against you. I'd rather people know where I stand, I can work somewhere > else. This isn't the 1950's, employees are assets, I don't feel the need > to grovel at the feet of a large company, I feel a company would be lucky > to have me. Egotistical, maybe, but I work very hard and I'm good at and > enjoy what I do. And not a single person reading that thinks any less of himself or herself. Others besides myself, I suspect, connected your insights to the .edu address, shrugged, and just moved on. You've learned so much, and yet, know so little. Don't take that wrong. Some things just aren't taught in classrooms. Getting RIF'ed hurts. It will feel extremely personal and completely misguided. The only way it can fail to affect you is if you truly don't give a rat's *** about what you've done and how well you've done it. That's all that was said. We know that you didn't know. As for the other side, prune a shrub someday, and you'll see just how little hard work and innate talent matters. Really, really take the time to prune a shrub. Father's Day would be a good pretext if you need one.Article: 132813
Matthew Hicks wrote: > Wow, you're omniscient now. Yes, I am a graduate student, but I've > seen/worked with graduate students of all different ages and levels of > experience. So coming from an .edu domain means nothing. > I'm not kicking anyone, I don't have anything invested in those that got > fired, I've been "let-go" before for less reason, that's life. These > people will all find another job, it may not be easy, but it won't be > devastating either. I have been made redundant twice so I know how these people are feeling. If you can't help them by giving them sympathy or help with job contacts then I think you should shut up and go. You have not done yourself any favours. AndyArticle: 132814
Randy Yates wrote: >... > Atheros I've heard is very good and supported by madwifi.org. Here is what I found on that madwifi.org: " The About/HAL: Hardware Abstraction Layer. All access to the hardware has to go thru this closed source component which is maintained by Atheros. Unfortunately there is no documentation for it except the public interfaces in hal/ah.h." I can understand they want to have something working with linux, but I definitely lose all sympathy when those of the "open source" community begin to get involved in the wifi secrecy scenario. It is not just hypocrytic, it is of course fuelling the monopoly over wifi related software. I would much rather have something with closed sources but documented rather than open source here and there and closed key parts. If such cooperation to blackmail companies (like MS and those making wifi parts usable only for MS) is OK with linux and GNU then they should certainly shut up with their claim about openness. Didi ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/36859f5adcc6089e?dmode=sourceArticle: 132815
On Fri, 06 Jun 2008 16:16:56 -0700, Mike Treseler wrote: >Perhaps the staircase could be >accelerated to an appropriate velocity. ;) > > L_v := L*(1-v**2/c**2)**0.5 ; Ah. Thanks for your relatively novel suggestion [sorry] which I had overlooked... -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 132816
On Thu, 05 Jun 2008 18:11:29 +0100, Jonathan Bromley wrote: >You may have noticed that I've been struggling to explain >some rather basic stuff about FIR filters to someone here. >I've run out of puff, and wish to sign off by recommending >some good books. [...] >Thanks in advance for getting me off the hook :-) And thanks to everyone for the excellent and helpful suggestions. Plenty there to keep _me_ busy, and I hope the querant I was talking about will benefit too. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 132817
JeDi wrote: >> I tried pipelining - mainly to break large combinational blocks into > smaller ones. And there it is... Stop making large combinatorial blocks. As others have pointed out, make 1 or 2 levels of logic, then a flip flop. Here's an example that I see often in image processing: you're processing a raster-scan image, so you need to know when you're at the end of an image line. You make a counter to count out the pixels on a line, then you pepper the control equations with a comparison of the row counter to the limit value. It might meet timing when synthesized and placed in unit testing, but as the chip grows, the placement of these equations has to compete with the placement of all other logic, and it no longer meets timing. The worst case timing path is the counter increment signal (hopefully a register output), through the counter, and through the carry chain, the counter output goes through the comparator, the comparator output combines with the rest of the control logic, then mercifully shows up at the D of a flip-flop. Now, if you had just registered the comparator output instead, the increment logic, counter logic and comparator delays would no longer contribute to your timing problem because they all happened in the previous clock cycle. Yes, this means that you have to compensate for the flip-flop delay of the comparator, but you just work that out in the design before you code (or you'll work that out anyway when the design doesn't meet timing). --- Joe Samson Pixel VelocityArticle: 132818
Joseph Samson wrote: The worst case timing path is the counter increment signal > (hopefully a register output), through the counter, and through the > carry chain, the counter output goes through the comparator, the > comparator output combines with the rest of the control logic, then > mercifully shows up at the D of a flip-flop. Oops! Those counter outputs are registered! In my defense, it was 7AM. The principle remains, though. Think of your logic register to register, not as large combinatorial chunks. --- Joe Samson Pixel VelocityArticle: 132819
"HT-Lab" <hans64@ht-lab.com> schrieb im Newsbeitrag news:DTd2k.59$pu3.37@newsfe05.ams2... > 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.com > > > Hello Hans, look at #1011430 @farnell in UK http://uk.farnell.com/1011430/connectors/product.us0?sku=hirschmann-mkl0-64-25-0-25-red also availlabe in black, but the farnell number is difficult to find. You can also find the cables in .de: http://www.buerklin.com/ Look for # 973604-100 MIKE www.oho-elektronik.de OHO-Elektronik Michael Randelzhofer FPGA und CPLD Mini Module Klein aber oho ! Kontakt: Tel: 08131 339230 mr@oho-elektronik.de Usst.ID: DE130097310Article: 132820
On Jun 4, 5:16 pm, Stef <stef...@yahooI-N-V-A-L-I-D.com.invalid> wrote: > Something simular to the following code fragments works in pre-synthesis > simulation, but not in real hardware and post P&R timing simulation. > ...snip... > > This works in pre-synthesis simulation (modelsim) and "STATE_CHANGED" is > only reached when datain is actually different from lastval_v. After > synthesis however, STATE_CHANGED is always reached except when datain is > equal to X"00". If I check the synthesis report, I find something about > lastval_v_mux0000 has a constant value during circuit operation. There > is also no 8-bit comparator found for the check state. Both I find > amazing as the pre-synth simulation works and I know the data on datain > is changing. > > To localize the problem, I have split the state in a separate check and > update state like this: > > when STATE_CHECK => > if datain /= lastval_v then > control_state_v := STATE_UPDATE > else > control_state_v := STATE_OTHER; > end if; > > when STATE_UPDATE => > lastval_v := datain; > control_state_v := STATE_CHANGED; > > This works in both pre- and post-synthesis simulation and also in real > hardware. There is now an 8-bit comparator found for the compare line > and no more warning about constant values. This can be significant. Do you have the tools to "see" the logic produced by this code? It will be a *lot* easier to understand the logic produced if you can reduce the problem code to a minimum set. Look at exactly what is being produced in the way of logic. You talk about an 8 bit comparator, but I only see an equivalence check. If the variables are 8 bits, this only takes 5 LUTs in two levels. I supposed it might use 4 LUTs with the carry chain, but I don't think that is essential. > So my question is: Is there a problem with comparing and updating a > value in the same state (clock)? No, certainly the language does not know what you are doing in terms of updating or comparing. It only knows what you tell it. If you said to compare values and update the register that is used in the compare, it is happy doing that... as long as that is what you are telling it.Article: 132821
On Jun 7, 12:13 am, Randy Yates <ya...@ieee.org> wrote: > rickman <gnu...@gmail.com> writes: > > [...] > > But if I want a laptop, I won't have much choice but to run Win XP > > (for the next few weeks) or Vista. I only wish I had a choice. > > You do. I have successfully installed Fedora 8 on an HP Pavillion > DV9620US. > > However one thing to be careful of in running linux on laptops is > Broadcom's stubborn refusal to open up their wireless card > specifications so that open source drivers can be developed. Translated: > don't buy a laptop with a Broadcom wireless card (or chipset) if you > want to run linux on it. Atheros I've heard is very good and supported > by madwifi.org. > > But, even though Broadcom is stubborn, I have still been successful at > getting the card to work on my home network. Unfortunately the reverse > engineered drivers (b43-fwcutter...) do not seem to support the Master > modes used in public hotspots. I knew someone would mention Linux. Linux is still an alien platform to me and there is any amount of software that is not supported under it... or I should say that there is any amount of software that is only supported on specific versions of Linux. If I run Fedora 8, maybe vendor X gives me support and vendor Y doesn't. I run Redhat and vendor X gives me support and vendor Z doesn't... etc, etc, etc. The reason that I still run windows at all is because for me, it is the only option. Currently Win2000 is the best that runs the minimum required set of software. If I want a laptop, my only choice currently is to buy a machine running XP which I can do for the next few weeks. After that there will be no choice on a new machine except for Vista. With a number of vendors not supporting that still, I will not have the option of buying a new laptop with an installed OS that runs the software I need. RickArticle: 132822
On Jun 7, 1:08 am, Matthew Hicks <mdhic...@uiuc.edu> wrote: > That's one of the downsides of being open and honest, people can use it against > you. I'd rather people know where I stand, I can work somewhere else. This > isn't the 1950's, employees are assets, I don't feel the need to grovel at > the feet of a large company, I feel a company would be lucky to have me. > Egotistical, maybe, but I work very hard and I'm good at and enjoy what > I do. It's not a question of egotistical or not, it is a question of reality. Like Mike said, everyone thinks they are good at what they do. The question is do you meet the expectations of your employer? There are any number of reasons for being hired and and any number of reasons for being let go. We all have to believe in ourselves and not use our jobs as our identity or basis of self-worth. More importantly, we all need to remain financially independent of our jobs just because we never know when they will end. Most people spend their lives thinking that they will have a job as long as they want to work. But lots of things can, and ***WILL*** happen. Virtually all companies can either go belly up overnight, or sell off huge chunks with no notice. When that happens you find yourself in a new company or in no company with no recourse. New companies then often "consolidate" and boom, you are out the door. The rule of thumb I have always heard is to maintain 6 months of income in a safe place such as a savings account or other highly liquid asset. My personal rule is 12 months. I have gone through layoffs three times over the last 25+ years and I don't care for it. Further, it is getting harder and harder to find a new position which I can only relate to my age. A friend can prove age discrimination at Google. I never thought it was real until I am now being faced with it. My response is to go into consulting. The pay is much better and the vacations much longer. But the best part is that my age actually helps give an air of experience (the gray fur doesn't hurt either...)! I just don't think of a job as anything but an open ended consulting gig. Maybe that shows and it works against me. But I am not going to put anything into a job other than what is required as part of the standard expectation. I have been burned too many times in the past with long work weeks for others and then being let go when the job was finished. A job is not a personal relationship, it is just a job. Learn to live without it. Xilinx claims to have had no layoffs up until now. But I bet there have been a lot of people without jobs after they bought the many other companies or their pieces. If they bought a process from a company in Europe and employees came with it, do you think they maintained the offices there forever? No, once the company had what they wanted from the deal, the offices were closed and the employees were given the choice of moving to the US or quitting. Isn't that pretty much the same thing as a layoff? I bet the employees felt like it. Xilinx folk, free free to correct me if I am mistaken. RickArticle: 132823
"jtw" <wrightjt @hotmail.invalid> wrote: >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, This will work, but the time involved to get the design finished will increase exponentially. A simpler way to do the same is using more than one clock. I usually have 3 clocks: slow (several MHz), main processes (tens of MHz) and high speed. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 132824
Joseph Samson wrote:
> The principle remains, though. Think of your logic register to register,
> not as large combinatorial chunks.
Yes. A well-packed FPGA design will utilize
about the same number of LUTs and flops.
Lets say that I instead describe
a large combinational chunk
using 100 LUTs and maybe a
multicycle constraint of 10 ticks.
This will work fine in isolation as long as
the flops associated with those 100 LUTs are not needed.
However, as the FPGA fills up, eventually place+route
will need those spare flops for other processes,
and the synchronous Fmax will start to suffer from
the long routes needed to wire them up.
In other words, adding a large combinatorial
chunk can "injure" an unrelated
high-speed synchronous block,
that was working fine before.
-- 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