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
fl wrote: > Hi, I want to put a column of independent SRL16 in a Virtex 4 xc4vlx15 > continuously. For even number, there is no problem. For odd number, I > cannot make them continuously even though these SRL16s are parallel, > independently with each other, see below code. I tried BEL attribute > without success. It seems ISE9.2i has to put "G" first, again here > does not require these SRL16 serially connected. Is it possible to put > independent SRL16 in a straight column? Thanks in advance. > <snip code> I recall some oddities when assigning BELs. I think the trick is when you assign two items to a slice, you assign both to the slice but only assign the G BEL. Or something similarly peculiar. I've been able to get my elements to go where I want, usually, using RLOCs and the occasional BEL. - John_HArticle: 131601
Un bel giorno austin digiṭ: > It is no secret that the low temperature range parts really have the > same mask set as the extended range parts. Yes, of course; I know how the selection is made, but I was wondering why Xilinx decided to use two nonstandard ranges (0/+85 instead of 0/+70 for commercial, and -40/+100 instead of -40/+85 for industrial) and I made the hypothesis that too many parts tested successfully for -40/+85 range, therefore they were "demoted by marketing" to 0/+85. Instead, the correct answer was Peter's: these aren't ambient temperatures, therefore they (unfortunately) don't have a direct relation with the temperature ranges of the common silicon parts. -- emboliaschizoide.splinder.comArticle: 131602
In article <k4t21496ku8p7hs9vm2t00254ov2q6udc0@4ax.com>, quiettechblue@yahoo.com says... > On Sat, 19 Apr 2008 20:47:57 -0400, krw <krw@att.bizzzzzzzzzz> wrote: > > >In article <PLsOj.7522$GE1.332@nlpi061.nbdc.sbc.com>, > >notthisjoergsch@removethispacbell.net says... > >> Joel Koltner wrote: > >> > "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message > >> > news:tq7Oj.1556$FF6.588@newssvr29.news.prodigy.net... > >> >> All I know from here (CA) is that their benefits are mind-boggling... > >> > > >> > Well, it's entirely reasonable to have retirement benefits for public > >> > employees be comparable to what private companies offer... I just hope that > >> > public employee salaries will then become comparable as well (which implies a > >> > pay raise), since otherwise I don't see how the gov't. expects they'll get > >> > comparable quality out of their workers. > >> > > >> > >> Private companies generally offer zilch in retirement benefits. Those > >> days are long gone. > > > >I don't know about "gone". The age of the "defined benefit" is > >pretty much gone in private industry but several still have "defined > >contribution" plans. Now, 401Ks make up for a lot of what's been > >lost and are portable. > > > >> > One problem with the government seems to be that they don't expect their > >> > employees to be agile over time. See this article: > >> > http://www.gcn.com/print/24_30/37174-1.html -- Someone the government ends up > >> > with a bunch of 70 year old programmers and therefore has to hire IBM to build > >> > them the modernized e-filing systems? Surely there must be some new hires in > >> > the past, say, 40 years who could have been working on this and hence, on > >> > average, would only be middle-aged today!? > >> > > >> > >> A 70 year old programmer can be better than a 40 year old. At least > >> that's my impression when I see all the "modern" bloatware ;-) > > > >Maybe. There are better things to do at 70, though. ;-) > >> > >> >> Oh, and then lots of jobs have the retirement benefit tied to the last work > >> >> year. > >> > > >> > I expect that was implemented to help people who were *forced* to move? > >> > > >> > It seems like it needs reworking to differentiate between cases where the > >> > government wants to move you vs. you just voluntarily wanting to do so. > >> > > >> > >> Or you just have to have the right connections to make that happen ... > >> > >> Anyhow, why should retirement checks be based on the last year of > >> service? IMHO that's wrong. For everyone else it sure doesn't work that way. > > > >The last years' is indicative of the final salary. Most "defined > >benefit" plans do take the last year, or last couple of years into > >account. What most private pensions *don't* do, that public plans > >do is include overtime in the formula. It's not hard to double > >one's income for a couple of years. There is no way the tax payer > >should pay that forever. > > So you say. While there are classes where that is easily done it is > usually in the mid range hourly and low range salaried that it is > reasonably possible. But how may 50+ year olds do you know that can > and will work significant overtime? Overtime should never be needed in a well run company. That said, I've been averaging 60hr weeks (some 70+ and a few weeks with holidays, less) since August and have at least a few more months of work left on the pile, if I want it. There is no reason a 50s can't work overtime but there is also no reason to need, want, or expect it. BTW, I certainly wouldn't be working the overtime were I salaried. -- KeithArticle: 131603
On Apr 21, 2:35 pm, Evan Lavelle <nos...@nospam.com> wrote: > Imagine you've > spent a day writing your FSM, or bus interface, or whatever. It gets > to 5 o'clock, and your choice is either (a) to go home and spend the > next day writing a testbench for it, when you've already forgotten > what it does, or (b) spend the next half-hour writing "test vectors" > (yes, bad phrase) for it. I know which one I'd go for. Any engineer who can't write simple code in his target language to test the RTL he wrote, shouldn't be writing either one. Secondly, if the vectors can be written in a half-hour, the RTL design code shouldn't have taken all day, unless you're testing to what you designed, instead of testing to the requirements. My point is that a designer should approach developing the test from the same point of view as developing the design. What's the likelihood that a designer will have spent all day and forgotten a required feature, and a half- hour later will have remembered that same feature when writing the vectors? AndyArticle: 131604
John, Thanks. My point (to anyone who cares) is that in the event of an emergency, even Morse code still has a real place in the world (not just in the movies). And, yes, getting the Morse right in the subject box is tough, on my monitor it is 8pt font, and hence unreadable. So, no more Morse (except on my keyboard and computer at home). Did you know that S.F.B. Morse himself was unable to decode his own code by ear? He had to see it on a printed strip of paper. Keyboard? Computer? Morse? Yup, hams have made it to the 21st century. Most hams use an ascii keyboard to Morse code generator, so I can type as I am typing now, and send the code (without mistakes). And, at the other end, the sound-card in the PC has a nice program that slices and dices the received audio, and provides the ascii right back out. Now the receiver program is not as good as the human brain-ear, but the programmers get better all the time, and before long, there will be a "Morse code" MODEM that is as good as the human, or better. Already we hams have 'digital' modes, such as PSK31, which is able to receive below the signal to noise ratio of the human ear-brain! http://en.wikipedia.org/wiki/PSK31 However, you can't decode it without a computer and sound-card. Morse does have the advantage that when the computers won't or don't work, your brain still is working. The '31' is the 31Hz wide spectrum the signal occupies, so it is efficient, too. AustinArticle: 131605
dalai, The Ambient temperature, combined with the user's deisgn, and their heatsinking and airflow, will determine the junction temperature. Or, another way to look at it, don't exceed the junction abs max. Lower the frequency, add more heatsink, increase the airflow, or lower the ambient. The CPLD has historically had low enough power, and sufficient design margins, that the worst design (for power) was still OK. Not so with the FPGA. The 125C abs max, like all abs max specs for Xilinx means that above this temperature (voltage or current), the failure rate might be 0.1% or more. At or below this temperature (voltage or current), the reliability and lifetimes of the parts are as specified in the quarterly reliability report. We have had people who have used our parts far above 125 C, and they understand that the parts may not live as long as they would at room temperature. But then, instrumenting an oil rig's drill bit is a tough application where 20 year life is not a requirement! AustinArticle: 131606
krw wrote: > In article <k4t21496ku8p7hs9vm2t00254ov2q6udc0@4ax.com>, > quiettechblue@yahoo.com says... >> On Sat, 19 Apr 2008 20:47:57 -0400, krw <krw@att.bizzzzzzzzzz> wrote: >> >>> In article <PLsOj.7522$GE1.332@nlpi061.nbdc.sbc.com>, >>> notthisjoergsch@removethispacbell.net says... >>>> Joel Koltner wrote: >>>>> "Joerg" <notthisjoergsch@removethispacbell.net> wrote in message >>>>> news:tq7Oj.1556$FF6.588@newssvr29.news.prodigy.net... >>>>>> All I know from here (CA) is that their benefits are mind-boggling... >>>>> Well, it's entirely reasonable to have retirement benefits for public >>>>> employees be comparable to what private companies offer... I just hope that >>>>> public employee salaries will then become comparable as well (which implies a >>>>> pay raise), since otherwise I don't see how the gov't. expects they'll get >>>>> comparable quality out of their workers. >>>>> >>>> Private companies generally offer zilch in retirement benefits. Those >>>> days are long gone. >>> I don't know about "gone". The age of the "defined benefit" is >>> pretty much gone in private industry but several still have "defined >>> contribution" plans. Now, 401Ks make up for a lot of what's been >>> lost and are portable. >>> >>>>> One problem with the government seems to be that they don't expect their >>>>> employees to be agile over time. See this article: >>>>> http://www.gcn.com/print/24_30/37174-1.html -- Someone the government ends up >>>>> with a bunch of 70 year old programmers and therefore has to hire IBM to build >>>>> them the modernized e-filing systems? Surely there must be some new hires in >>>>> the past, say, 40 years who could have been working on this and hence, on >>>>> average, would only be middle-aged today!? >>>>> >>>> A 70 year old programmer can be better than a 40 year old. At least >>>> that's my impression when I see all the "modern" bloatware ;-) >>> Maybe. There are better things to do at 70, though. ;-) >>>>>> Oh, and then lots of jobs have the retirement benefit tied to the last work >>>>>> year. >>>>> I expect that was implemented to help people who were *forced* to move? >>>>> >>>>> It seems like it needs reworking to differentiate between cases where the >>>>> government wants to move you vs. you just voluntarily wanting to do so. >>>>> >>>> Or you just have to have the right connections to make that happen ... >>>> >>>> Anyhow, why should retirement checks be based on the last year of >>>> service? IMHO that's wrong. For everyone else it sure doesn't work that way. >>> The last years' is indicative of the final salary. Most "defined >>> benefit" plans do take the last year, or last couple of years into >>> account. What most private pensions *don't* do, that public plans >>> do is include overtime in the formula. It's not hard to double >>> one's income for a couple of years. There is no way the tax payer >>> should pay that forever. >> So you say. While there are classes where that is easily done it is >> usually in the mid range hourly and low range salaried that it is >> reasonably possible. But how may 50+ year olds do you know that can >> and will work significant overtime? > > Overtime should never be needed in a well run company. That said, > I've been averaging 60hr weeks (some 70+ and a few weeks with > holidays, less) since August and have at least a few more months of > work left on the pile, if I want it. There is no reason a 50s can't > work overtime but there is also no reason to need, want, or expect > it. BTW, I certainly wouldn't be working the overtime were I > salaried. > So what do you do at the end of this gig? Maybe buy Adnan Kashoggi's yacht ;-) -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131607
I stand corrected. I should have looked at whois first. This is a bold move to open VMM. Now the only question is why Accellera has no listed VMM project.Article: 131608
On Apr 25, 4:56 pm, JosephKK <quiettechb...@yahoo.com> wrote: > On Fri, 18 Apr 2008 00:09:02 -0700 (PDT), "David L. Jones" > > > > <altz...@gmail.com> wrote: > >On Apr 18, 8:15 am, Dave <dhsch...@gmail.com> wrote: > >> On Apr 17, 5:13 pm, "Steve" <sjbur...@comcast.net> wrote: > > >> > "Joerg" <notthisjoerg...@removethispacbell.net> wrote in message > > >> >news:U5MNj.6956$GE1.6193@nlpi061.nbdc.sbc.com... > > >> > > qrk wrote: > >> > >> On Thu, 17 Apr 2008 09:43:09 -0700 (PDT), Dave <dhsch...@gmail.com> > >> > >> wrote: > > >> > >>> Does anybody out there have a good methodology for determining your > >> > >>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? > >> > >>> The brute force method is fairly maddening. I'd be curious to hear if > >> > >>> anybody has any 'tricks of the trade' here. > > >> > >>> Also, just out of curiosity, how many of you do your own PCB layout, > >> > >>> versus farming it out? It would certainly save us a lot of money to > >> > >>> buy the tools and do it ourselves, but it seems like laying out a > >> > >>> board out well requires quite a bit of experience, especially a 6-8 > >> > >>> layer board with high pin count FPGA's. > > >> > >>> We're just setting up a hardware shop here, and although I've been > >> > >>> doing FPGA and board schematics design for a while, it's always been > >> > >>> at a larger company with resources to farm the layout out, and we > >> > >>> never did anything high-speed to really worry about the board layout > >> > >>> too much. Thanks in advance for your opinions. > > >> > >>> Dave > > >> > >> Sure wish there was a slick way of doing FPGA pinouts. I usually use > >> > >> graph paper and figure out the FPGA pinout to other parts to minimize > >> > >> routing snarls. > > >> > >> I do pcb layouts on my own and other folks designs. Our boards have > >> > >> high-speed routing, switching power supplies, and high-gain analog > >> > >> stuff; sometimes all on the same board. Unless the service bureau has > >> > >> someone who understands how to lay out such circuitry and place > >> > >> sensitive analog stuff near digital junk, it is more trouble to farm > >> > >> out than do it yourself if you want the board to work on the first > >> > >> cut. > > >> > > Or find a good layouter and develop a long-term business relationship. My > >> > > layouter knows just from looking at a schematic which areas are critical. > >> > > He's a lot older than I am and that is probably one of the reasons why his > >> > > stuff works without much assistance from me. Nothing can replace a few > >> > > decades of experience. > > >> > >> Doing your own layout will take a lot of learning to master the PCB > >> > >> layout program and what your board vendor can handle. It will take 5 > >> > >> to 10 complicated boards to become mildly proficient at layout. I > >> > >> don't know about saving cost. Your time may be better spent doing > >> > >> other activities rather than learning about layout and doing the > >> > >> layouts. ... > > >> > > Yep, that's why I usually do not do my own layouts. Occassionally I route > >> > > a small portion of a circuit and send that to my layouter. No DRC or > >> > > anything, just to show him how I'd like it done. > > >> > >> ... The upside to doing your own layout - you control the whole > >> > >> design from start to finish. If you have a challenging layout, you'll > >> > >> have a much higher probability of having a working board on the first > >> > >> try which has hidden savings (getting to market earlier <- less > >> > >> troubleshooting + less respins). > > >> > >> --- > >> > >> Mark > > >> > > -- > >> > > Regards, Joerg > > >> > >http://www.analogconsultants.com/ > > >> > > "gmail" domain blocked because of excessive spam. > >> > > Use another domain or send PM. > > >> > I agree with Joerg. Good high speed or mixed signal PCB layout is a career > >> > choice, and we electrical engineers already chose our career. A good layout > >> > requires someone who understands not just the software package, but the > >> > details of how the manufacturing operation is going to proceed, what the > >> > limits of the processes are, what the assembly operations require of the > >> > board, and is anal about things like footprint libraries and solder mask > >> > clearances and a thousand other details that I'm only partially aware of. > >> > The more complex your design, the more critical these things become. > > >> > I have two good local outfits for farming out boards. For complex stuff, > >> > they know I'll come to their place and sit next to the designer for a good > >> > bit of the initial placement. While we are doing placement, we are also > >> > discussing critical nets, routing paths, layer usage, etc. That gives us > >> > direct face to face communication and avoids spending lots of time trying to > >> > write/draw everything in gory detail (which gets ignored or misunderstood a > >> > lot of the time). That investment pays big dividends in schedule and board > >> > performance. > > >> > Don't be fooled by the relatively low cost of the software. That's not where > >> > the big costs are. > > >> > I once laid off my entire PCB layout department and sent all the work > >> > outside, because although my employees all knew how to use the software, > >> > none of them could tell me what their completion date would be, or how many > >> > hours it would take, and they certainly weren't interested in meeting > >> > schedules. The outside sources would commit to a cost and a delivery date. > >> > And we already knew they could meet our performance objectives. Fixed price > >> > contracts are great motivators. Missing an engineering test window, or > >> > slipping a production schedule because of a layout delay can be enormously > >> > expensive. > > >> > Of course, if I had let my engineers do their own layouts, the motivation > >> > would have been present, but the technical proficiency would not. How > >> > proficient can anyone become if they only do layout a few times a year? > >> > Also, on many projects engineers use the layout period for other important > >> > things like documentation, test procedures, writing test code, etc. Doing > >> > your own layout serializes these tasks and will stretch your schedule. > > >> > So my advice is to keep doing what you have been doing. Its far more likely > >> > that its the cheapest approach, even though you occasionally have to write a > >> > big check. > > >> > Steve > > >> I tend to agree with the 'farm-it-out' crowd. Unfortunately, my > >> current employer doesn't want to work with my previous layout people, > >> so I've been trying to search for a new partner. I've found plenty of > >> board fab and assembly places, but not so much on the layout. It made > >> me think that the rest of the world did their own layout. The opinions > >> look pretty split from the replies here, maybe it comes down to how > >> many times you do a layout each year, and how much you enjoy that sort > >> of work. I definitely think it's something you have to do fairly often > >> to keep your chops up. > > >> Andy, I'd also like to hear more about your pin-swap FPGA design flow > >> - what tools do that? Also curious about any timing issues that have > >> been caught after the pin-swap. > > >In Altium Designer I use the incredibly useful "subnet jumper" feature > >for BGA's. > >The procedure goes something like this: > >1) Fan out all the required FPGA pins first (automatically or > >manually) to just outside the chip boundry. (leave several diagonal > >entry paths for core and other power flood fills to get in) > >2) Fully route all non-pin-swappable pins and other critical lines. > >3) Ensure any other parts placements are near any required FPGA pins > >or block features you think you might need. > >4) Route every track just short of the fanout tracks > >5) Hit the "add subnet jumper" feature and it finishes the tracks and > >does all the pin swaps for you and updates the schematic. > > >Probably needs a picture or two to explain it best though... > > >The great part about subnet jumpers is if there are timing or other > >problems you can just remove the subnet jumpers and add/edit tracks > >and pins as needed and then replace the subnet jumpers. Only takes a > >minute or two. > > >Dave. > > That does sound specific to one particular tool (vendors's software). Yes, it is specific to Altium Designer. It's their way of simplifying FPGA design and layout. Dave.Article: 131609
austin wrote: > Syms, > > Thanks! Wonderful. > > In all seriousness, I would suggest we treat the newbies with a little > more patience. It isn't easy starting out in this field. I know > these folks will not become your customers, but they might someday be > mine. > > Austin Austin, I gratefully accept the rebuke. In mitigation for my actions, I worry this newsgroup could turn into something as useless as sci.whatever.idiots which I occasionally get subjected to because of thoughtless cross postings. I've personally learnt a lot through this newsgroup over the years, from some very smart folks. I've learnt from you too. (Kidding!) It would be a terrible shame if smart folks stopped contributing because of people who can't even take the courtesy to post coherently. So, try this link, but, at the end, substitute 'comp.arch.fpga' for 'New Scientist' and 'FPGAs' for 'science'! http://www.youtube.com/watch?v=-_2xGIwQfik Cheers, Syms. p.s. Are you any good on an Aldiss Lamp?Article: 131610
"austin" <austin@xilinx.com> wrote in message news:fute06$78s2@cnn.xsj.xilinx.com... > Mikhail, > > If the ambient is never that hot, > then the max current is a lot less. How much is a 'lot'? > If the Vccint is not 5% high, the > max current is less. Current is measured in units of 'less'? > If the process is closer to typical, the current > is a lot less. > Another vacant 'lot'? I think you failed in your attempt to answer the OP's basic question which was >> I >> wonder if there is some more precise information on how it actually >> depends >> on it?... Vague generalities as a response to a question about needing more specifics to verify the design aren't usually too helpful. Maybe you'd like another crack at it? KJArticle: 131611
"KJ" <kkjennings@sbcglobal.net> wrote in message news:BdvQj.22988$%41.12812@nlpi064.nbdc.sbc.com... > > "austin" <austin@xilinx.com> wrote in message > news:fute06$78s2@cnn.xsj.xilinx.com... >> Mikhail, >> >> If the ambient is never that hot, >> then the max current is a lot less. > > How much is a 'lot'? > >> If the Vccint is not 5% high, the >> max current is less. > > Current is measured in units of 'less'? > >> If the process is closer to typical, the current >> is a lot less. >> > > Another vacant 'lot'? > > I think you failed in your attempt to answer the OP's basic question which > was > >>> I >>> wonder if there is some more precise information on how it actually >>> depends >>> on it?... > > Vague generalities as a response to a question about needing more > specifics to verify the design aren't usually too helpful. > > Maybe you'd like another crack at it? > > KJ > K, I would imagine that Xilinx, or any other company, will not get any more specific on specs that are being violated, because of liability issues. Austin has given "rules of thumb" that may make one sleep more easily with this under-designed product. If it were my product, I would (re)design it to meet the specification. Bob -- == NOTE: I automatically delete all Google Group posts due to uncontrolled SPAM ==Article: 131612
KJ, I am trying to politely say, he is on his on, he has exceeded the spec. I am also saying that there are those who might test their systems in a burn-in oven, and reject the units that won't power on when hot. If he has 10 units he has to ship next week, this might be a perfectly good temporary solution, until he re-designs his power supply. AustinArticle: 131613
Which version of the tools are you using (which version of the PLB?)Article: 131614
Andy wrote: > Any engineer who can't write simple code in his target language to > test the RTL he wrote, shouldn't be writing either one. That may be true, but some get by with trial and error synthesis on designs that glue together IP and "known good" modules. An fpga guy who is good with logic analyzers and test fixtures can debug some fpga designs on the bench. Not my cup of tea, but I've seen it done on some successful products. > Secondly, if the vectors can be written in a half-hour, the RTL design > code shouldn't have taken all day, unless you're testing to what you > designed, instead of testing to the requirements. For new synthesis code, most of my simulation time is testing the design. Working demo units are required to sign off a business case, and specifications start out fuzzy. Quick turn-around is the key, and a clean, closed loop testbench is an advantage. > My point is that a > designer should approach developing the test from the same point of > view as developing the design. What's the likelihood that a designer > will have spent all day and forgotten a required feature, and a half- > hour later will have remembered that same feature when writing the > vectors? I agree. I design and test interactively. I can't imagine doing otherwise. Once I have a testable procedure with inputs and outputs, I add stim procedures to the testbench and at least some "printf" style verification before moving on to the next lump of logic. -- Mike TreselerArticle: 131615
Joerg wrote: > The latter is a concern in my field (medical). We need to be able to > inspect. For medical devices/equipment, I'd be concerned with getting an RoHS waiver and non-green parts and solder, so that the device/equipment isn't likely to fail in a few years due to tin wiskers and harm the patient.Article: 131616
Peter Alfke wrote: > The design is done, we are finishing documentation, and Ken Chapman > has graciously agreed to give it a thorough hardware test net week: > 4 LUTs, 4 flip-flops, insensitive to contact bounce or any type of > erratic mechanical movement. Then it must be VERY clever, even Clairvoyant, if it can separate 'any type of erratic mechanical movement', from a genuine mechanical movement! ;) > 1, 2, or 4 counts per encoder cycle (i.e. 90, 180 or 360 degrees > between counts, as a config option) > "The end of all discussions about quadrature encoders, mechanical or > optical." No mention of catching illegal states ? (clock too slow) ? -jgArticle: 131617
Julio Espada wrote: > Hi! > > I'm looking for the Atmel ATF750C library for Proteus but I'm unable to find > it on both Atmel & Labcenter sites. Does anyone know where can I find this ? > Or perhaps, any other application that can simulate the ATF750C ? > > Thanks in advance for any help. If you want mixed mode Spice simulation, then you will need a Spice flow that supports D/T FF and AND/OR PLD logic. If you just want functional boolean simulation, the Atmel tools can support that. The 750 is similar to a 2 x 22V10 (but with .T register option). Some Spice flows support Boolean Eqn, or other methods of Logic - I see Proteus mention a JED pathway, so you need to find the intermediate format, that the JED is turned into, and try and work with that. -jgArticle: 131618
On Fri, 25 Apr 2008 14:06:44 +0200, Thorsten Kiefer <webmaster@nillakaes.de> wrote: >Hi, >when i synthesize this : > > > >architecture Behavioral of vga_test is > constant MXINIT : integer := 100; > constant MYINIT : integer := 100; > signal mousex_reg,mousey_reg : unsigned(9 downto 0); > signal mousex_next,mousey_next : unsigned(9 downto 0); >.... >begin > process(clk,reset) > begin > if reset='1' then > rgb_reg <= (others=>'0'); > mousex_reg <= MXINIT; > mousey_reg <= MYINIT; > elsif rising_edge >...... > >i get the following error messages : >HDLParsers:800 - "/home/thorsten/work/xilinx/vgatest1/vga_test.vhd" Line 66. >Type of mousex_reg is incompatible with type of MXINIT. >ERROR:HDLParsers:800 - "/home/thorsten/work/xilinx/vgatest1/vga_test.vhd" >Line 67. Type of mousey_reg is incompatible with type of MYINIT. 1) DO NOT declare registers as std_logic_vector(9 downto 0) or use conv_std_logic_vector(). I presume you are using the correct numeric_std library; stick with this. 2) As others have said, numeric_std defines to_unsigned() to perform this conversion. 3) A peculiarity of this library is that while direct assignment of integer is not defined, mixed arithmetic between [un]signed and integer is defined, by overloading +,- etc with different signatures. Hence mousex_reg <= (others=>'0') + MXINIT; will work (but it's UGLY) 4) Consider declaring your constants MXINIT etc to be unsigned. If this is the only place they are used, why declare them as a different type to their purpose? If you find yourself using type conversions everywhere, it's usually a sign that you are working at the wrong abstraction. 5) Another option is to use a subtype subtype mouse_word is unsigned(9 downto 0); -- makes it easy to change mouse resolution later constant MXINIT : mouse_word := to_unsigned(100, mouse_word'length); -- at this point we don't need to know how big mouse_word is... signal mousex_reg,mousey_reg : mouse_word; mousex_reg <= MXINIT; 6) The ugly conversion can be wrapped in a function, if you find yourself using it a lot. function to_mouse_word (int : integer) return mouse_word is begin return to_unsigned(int, mouse_word'length); end mk_unsigned; constant MXINIT : mouse_word := to_mouse_word(100); 7) These subtypes and functions can be moved into a package (a) to reduce clutter in your main code, or (b) if they need to be visible in different places - BrianArticle: 131619
"BobW" <nimby_NEEDSPAM@roadrunner.com> wrote in message news:UrqdnU3qjLA1Fo_VnZ2dnUVZ_t2inZ2d@giganews.com... > > > "KJ" <kkjennings@sbcglobal.net> wrote in message > news:BdvQj.22988$%41.12812@nlpi064.nbdc.sbc.com... >> >> "austin" <austin@xilinx.com> wrote in message >> news:fute06$78s2@cnn.xsj.xilinx.com... >>> Mikhail, >>> > > K, > > I would imagine that Xilinx, or any other company, will not get any more > specific on specs that are being violated, because of liability issues. > Austin has given "rules of thumb" that may make one sleep more easily with > this under-designed product. If it were my product, I would (re)design it > to meet the specification. > > Bob > Bob, Austin, The request was "if there is some more precise information on how it actually depends". If Xilinx doesn't have (or doesn't want to disclose even under NDA) then the answer to the question is quite simply 'no'. Whether Austin is representing Xilinx or not on this newsgroup he certainly is privy to more detailed info on the parts as are all of the Xilinx engineering reps that support Xilinx products. As such, those people are in a position to provide some form of engineering assisstance to customers (since that is pretty much the job description of such a rep). Whether Xilinx is willing to share such info (if it exists) is a business decision that Austin and other reps would also know....if not, the answer to the request can simply be 'no'. The answer that Austin gave was the type of lame response I might expect from someone who doesn't know much about the particular parts. Since Austin is clearly not in that class, his answer came across as pretty lame, so I thought pointing out that he might want to take a second go at it or simply say that no more detailed info can be provided would clarify the issue a bit. If more useful and precise info could be provided in an open forum, then he could have provided it. Since it likely can not, the reply could have been taken off group or Mikhail could have been referred to a local engineering rep for assisstance or simply told 'no' and maybe a statement it's possible at any time and temp that a particular part might draw the max inrush current therefore you have to redesign your supply. In any case, don't interpret this as a slam on Austin or Xilinx, just an attempt to elicit a clearer response to whether the info that Mikhail requested is available or not. Kevin JenningsArticle: 131620
On Apr 26, 12:14=A0am, -jg <Jim.Granvi...@gmail.com> wrote: > Peter Alfke wrote: > > The design is done, we are finishing documentation, and Ken Chapman > > has graciously agreed to give it a thorough hardware test net week: > > 4 LUTs, 4 flip-flops, insensitive to contact bounce or any type of > > erratic mechanical movement. > > =A0Then it must be VERY clever, even Clairvoyant, if it can separate > 'any type of erratic mechanical movement', from a genuine > mechanical movement! =A0;) > > > 1, 2, or 4 counts per encoder cycle (i.e. 90, 180 or 360 degrees > > between counts, as a config option) > > "The end of all discussions about quadrature encoders, mechanical or > > optical." > > No mention of catching illegal states ? (clock too slow) ? > > -jg I'll run the clock between 10 and 100 MHz, so it will never be too slow. There is no way to move a whole quadrant in one such clock period. PeterArticle: 131621
Eric Smith wrote: > Joerg wrote: >> The latter is a concern in my field (medical). We need to be able to >> inspect. > > For medical devices/equipment, I'd be concerned with getting an RoHS > waiver and non-green parts and solder, so that the device/equipment > isn't likely to fail in a few years due to tin wiskers and harm the > patient. Sure. However, about a year ago we learned that we better brace ourselves for not so good things to come: http://www.greensupplyline.com/howto/192300282 -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131622
Austin, Just curious: why even spec "Iccintmin is 244 mA typically" if Xilinx really wants their users to design for 1.65A on power-up/configuration? I haven't read the data sheet on this part but the OP makes it sound like the data sheet suggests a lower power-up requirement if the design is within the nominal limits on voltage, temperature, etc... Rob austin wrote: > KJ, > > I am trying to politely say, he is on his on, he has exceeded the spec. > > I am also saying that there are those who might test their systems in a > burn-in oven, and reject the units that won't power on when hot. > > If he has 10 units he has to ship next week, this might be a perfectly > good temporary solution, until he re-designs his power supply. > > AustinArticle: 131623
is someone has the code of CRC (cyclical redundancy check) that xilinx use in the bitstream ? is it a simple CRC ( the XOR of words ) ?Article: 131624
swissiyoussef@gmail.com wrote: > is someone has the code of CRC (cyclical redundancy check) that xilinx > use in the bitstream ? is it a simple CRC ( the XOR of words ) ? try <http://www.xilinx.com/support/documentation/application_notes/xapp151.pdf> Alan Nishioka
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