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
On Tue, 05 Jan 1999 11:04:16 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: >Does anybody out there using the Leonardo tools know how to do >incremental compilation & linking. Sure, no problem. You know, you can always give us a call at Saros for this kind of support: 01491 837787 >i.e. I have a module foo with an instantiiated block-box called bar >definined in foo.v with the real bar module held in a separate file >called bar.v. What I want to do is compile & synth foo.v and bar.v >separately into EDIF files foo.edn & bar.edn and then link them. In >other words merge bar.edn into the correct place in foo.edn. This would >save a lot of time by not re-synthesising and re-optimising stable >pieces of the design. Standard procedure for generating internal lumps of IP, as well as integrating bought-in netlists. You can even decide to dissolve the hierarchy (L3) and re-optimise across the boundary if that's what you want. You have to be a little careful with global resources in FPGA's when you synthesise instantiated blocks but there are some tricks you can use so it isn't much of a problem. For your simple example, below are three scripts that should show you the essence of the process. I have assumed that your foo is a top level and needs ports, while the bar is to be instantiated into the design. Hence macro and chip mode synthesis runs. Note the final foobar script does not run any synthesis. It basically reads in your top level foo, and then reads in bar, which replaces the empty placeholder in the work library previously written out in the foo.edf netlist. You set the present_design to foo, as the last design read in was bar, and then just write out the netlist. The last command just kicks off the design manager GUI, but you can use it to run the whole P&R if you like. There are three individual scripts so that you can shut down the tool between runs to satisfy yourself that there is "nothing up our sleeves". The scripts obviously pertain to Level 3, but for your specific example, you can do this with Level 2 by driving the GUI. Give me a call, and I can walk you through it if you would like. Cheers Stuart foo script ---------- set part 4005xlPC84 set process 3 set wire_table 4005xl-3_avg load_library xi4xl read foo.v set_attribute .work.bar.INTERFACE -name NOOPT -value 1 PAD BUFGLS clk optimize .work.foo.INTERFACE -target xi4xl -effort quick -area -chip -flatten write -format EDIF foo.edf bar script ---------- set part 4005xlPC84 set process 3 set wire_table 4005xl-3_avg load_library xi4xl read bar.v optimize .work.bar.INTERFACE -target xi4xl -effort quick -area -macro -flatten write -format EDIF bar.edf foobar script ------------- load_library xi4xl read foo.edf bar.edf present_design .work.foo.INTERFACE auto_write -format EDIF C:/Work_sc/work/foobar.edf place_and_route foobar.edf -target xi4xl -gui foo.v ----- module foo (in0, in1, out, clk); input in0, in1, clk; output out; wire sync_in0; bar U0 (in0, sync_in0, clk); // Instantiate bar assign out = in1 & sync_in0; endmodule /* Black-box definition of bar */ module bar (in, sync_in, clk); input in, clk; output sync_in; endmodule bar.v ----- module bar (in, sync_in, clk); input in, clk; output sync_in; reg sync_in; always @(posedge clk) begin sync_in = in; end endmodule For Email remove "NOSPAM" from the addressArticle: 13976
Peter wrote: > Regarding a) I found that the AMD 22V10 was awful, while the Philips > one was "perfect". (There was a probably unrelated problem with the > early Philips samples I had being thoroughly duff). I had email from a > Philips man who saw my posts and he basically says that they don't > guarantee identical prop delays in the input buffer - well this is > clear since that would be a theoretical impossibility anyway. I would > however have hoped that the skew between the two signals would be less > than the response time of the product term AND gate and this certainly > seems to be the case in the current Philips P3Z22V10 several of which > have been running for a week or two now with not one error. You seem to put a lot of blame on the AMD part with the thinking that the skew in prop delay must be much worse than in the Philips part. But if I understand your situation correctly, skew in one direction will cause the problem, while skew in the other direction will mask it. The failure you are seeing is only on one edge of the input. It may just be that the Philips part has as much skew as the AMD part, just in the direction that helps your test case rather than harming it. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13977
Hi, has anyone done a CRC-16 generator/checker, x16+x15+x2+1 polynomial, in an FPGA? Preferably in schematic form? Wanna trade for money/food/beer? I also have MC68332 code to boot Xilinx 4010XL's from CPU shared program/FPGA-config EPROM if anybody's interested.... THAT one took a while to get up! Thanks, John -- ****************************************************************** John Larkin, President phone 415 753-5814 fax 753-3301 Highland Technology, Inc 320 Judah Street jjlarkin@worldnet.att.net San Francisco, CA 94122 http://www.highlandtechnology.comArticle: 13978
This is a multi-part message in MIME format. --------------7D806DDB6243A0DE1CAAFDD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It's amazing what you can get away with in video. If you apply the non-linearity to YUV and then transform to RGB, it doesn't look too bad, but it's really not correct and will generate discernable color errors. The correct way is: 1) transform YUV to R'G'B' where R'G'B' is the color space of the actual monitor you are using to display the data. This is different than RGB which seems to be generally assumed to work with NTSC monitor phosphors. 2) apply a calibrated look-up-table to each channel. IE: R'=Y*c0+U*c1+V*C2+C3; rout=RLUT[R']; This method will ignore non-linear interactions between channnels and time dependent brightness issues as well as ambient light chroma and intensity. It also requires you to calibrate the curves, as well as obtaining an absolute chroma measurement for each of the monitor phosphors. Another method would be to apply a 3D LUT with interpolation directly to YUV. Keep in mind that the gamma function is a crude approximation to the actual luminance curve. Also, monitors drift over time. All this probably impractical for your needs, so it would probably be best to simply do a gamma (R^^2.2) function on the RGB values after transformation from YUV. Best Wishes Brad Armin Mueller wrote: > > Hello, > > I know the Gamma correction is normally done in the > RGB color space (by component). > > Would it be possible to do the Gamma directly in YUV terms? > Sure, the exp-function can't be added, but maybe there are > some simplifications... > > Armin --------------7D806DDB6243A0DE1CAAFDD7 Content-Type: text/x-vcard; charset=us-ascii; name="blt.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brad Taylor Content-Disposition: attachment; filename="blt.vcf" begin:vcard n:Taylor;Brad tel;work:1-408-730-3300 ext108 x-mozilla-html:FALSE url:www.cmln.com org:Chameleon Systems;Applications version:2.1 email;internet:blt@cmln.com title:Director of Applications adr;quoted-printable:;;1195 W. Fremont Ave=0D=0A;Sunnyvale;CA;94087-3825;USA note;quoted-printable:Chameleon Systems is a fabless semiconductor company. Chameleon=0D=0Ais developing a new class of devices known as ASPPs for=0D=0A"Application Specific Programmable Device". Please contact me=0D=0Adirectly for more information about our product line at=0D=0Ablt@cmln.com=0D=0A=0D=0A fn:Brad Taylor end:vcard --------------7D806DDB6243A0DE1CAAFDD7--Article: 13979
Happy new year! Visit MY SEMICONDUCTOR LINKPAGE at http://home.t-online.de/home/a.tillmann where you can find semiconductor related links in the following categories: Companies Wafer Manufacturers(21) Equipment Vendors(455) Used Equipment/ Refurbished Equipment(17) IC Manufacturers/ Foundries/ Wafer Processing Services(301) Software/ Process and Device Simulation(46) Service/ Photomask Manufacturers/ Others(78) Quartz manufacturers(6) Consultants(10) Universities/ Institutes(49) Journals(14) Organisations/ Directories/ Linkpages U.S.A.(30) Japan(11) Europe(7) News(5) Usenet Groups(14) Conferences(5) Online Shop Software(4) Books in Association with Amazon.com: General Semiconductor(67) Books in Association with Amazon.com: Chemical Vapor Deposition(7) Books in Association with Amazon.com: Ion Implantation(7) Books in Association with Amazon.com: Rapid Thermal Processing(4) Search Engines (english)(31) Search Engines (french, german)(6) Jobs/ Recruitment(10) If you would like to add your own link please submit the URL, the name of the company or organization and the category, where the link should appear. Best regardsArticle: 13980
I'm looking for copies of datasheets on a couple of old PLD products: Plus Logic H5110 and Intel FlexLogic iFX780 these chips were around about 1990. Any technical literature or conference/ magazine papers on these products would be much appreciated! (I know they are no longer available and am not looking for suggestions for equivalent or better devices). Cheers, Tom KeanArticle: 13981
Sorry. I'm sure you know all this, but I feel compelled to say it anyway: You are playing with fire. Either make sure the code is theoretically glitchless, or sync the async input. I would never depend on the characteristics of 1 (or several) batches of a particular vendors parts for a characteristic that he doesn't advertise. Who knows, maybe next month maybe they will ship AMD parts. Good information though. Bruce "Having spent untold hours at analyzing and measuring metastable behavior, I can assure you that it is (today) a highly overrated problem. You can almost ignore it." Peter Alfke 12/28/98 "Having spend untold hours debugging digital designs, I can assure you that metastable behavior is a real problem, and every digital designer had better understand it" Bruce Nepple 12/31/98Article: 13982
Hello Folks, I've discovered a great new search engine that beats all the others hands down. It's called I-Search Online! What makes them better than the rest is that they filter out all spam postings so you get clean, accurate, no nonsense results. Plus, if you're a webmaster, they also make a great place to advertise your website because you can choose your listing's rank which is excellent! Go check them out at this URL: WWW.ISEARCH.TO and tell them Dave sent you! Best Regards, David AllenArticle: 13983
Jonathan Bromley <jsebromley@brookes.ac.uk> writes: > [version 1: no hazard coverage] > if (clk) then q=d else q=q ---maps to--> q = clk.d + /clk.q > > [version 2: hazard covered] > q = clk.d + /clk.q + d.q > > Commonsense says that version 1 is dodgy and version 2 is OK. BUT: > in QuickLogic FPGAs, for example, [1] works just fine because clk is used > as the select input to a multiplexer implemented by break-before-make > pass transistors with capacitive hold on its output. On the other > hand, it is possible to imagine table-lookup implementations of > 3-input OR which could make [2] fail despite the extra term. I have read that Xilinx and Altera FPGAs implement their logic tables in the "safe" way you describe (pass transistors with capacitive hold, or equivalent). So if you pick the right devices, you don't need to worry about these sort of hazards. (But don't rely on my second hand info -- check the manuals if you need to). > The net result is that any tool that attempts to achieve automatic hazard > coverage will need to preserve information about the dynamic behaviour of > the logic (which transitions it will make) all the way down to the > hardware - even, perhaps, down to place-and-route - in order to decide > how to implement the hazard coverage. Or use an FPGA that guarantees no hazards on single input transitions. -- JamieArticle: 13984
Hello, I must convert a microcontroller based digital AGC to an FPGA. The
AGC in question uses relatively simple math (adds, shifts, and Look up
Tables). I also need to implement digital peak detectors that peak detect
using and A/D converter.
I am a novice with FPGAs and my expertiese only extends to micro coding
for controllers. Any help on how to choose FPGAs, and what company FPGAs sound
apt for my application will be greatly appreciated.
Thank you all in advance.
Eldho Kuriakose
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Article: 13985I believe this is correct. >I have read that Xilinx and Altera FPGAs implement their logic tables in >the "safe" way you describe (pass transistors with capacitive hold, or >equivalent). -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13986
I have externally synced the input with a HC74, anyway. I realise that one cannot guarantee equal propagation delays. I merely observed that Philips seem to have got it about right. >now that you have it working, try cooling and heating it. >Your problem may come back. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13987
In article <S4WnzrBY0ok2EwBJ@jmwa.demon.co.uk>, John Woodgate <jmw@jmwa.demon.co.uk> writes: > <76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote: > >If the problem is "irrelevant" for "most applications", how do I tell > >if I'm working on one where it is relevant? > > Assume that it is, until you prove that it isn't. In other words, if it > works, OK; if it doesn't, don't rule out metastability as the cause. That's the sort of attitude that gets people burned. Testing a design doesn't tell you it doesn't have any metastability problems. It only tells you that they don't happen often enough for your tests to catch them. Suppose you design a disk controller. You test it hard for a week. It works great. So you test 10 of them for a month. No troubles. So you ship it. Suppose it has a once-a-year metastability bug that trashes your data. Your testing only has a 50-50 chance of finding one. Maybe you missed it. Most systems don't run the disk as hard as test programs do but some machines are pretty busy. So every 10 years you get some data trashed. If you have a dozen machines that means an obscure bug/glitch every year or so. If you are running crappy software nobody will notice a quirk a year. But not all software is crappy. Some of us expect disk subsystems and operating systems to work - or at least not trash our data without some hint. Once a year type bugs are a real pain to track down. You can't test out metastability! You have to understand things and do it right at design time. -- These are my opinions, not necessarily my employers.Article: 13988
John Woodgate wrote: > <76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote: > >If the problem is "irrelevant" for "most applications", how do I tell > >if I'm working on one where it is relevant? > > Assume that it is, until you prove that it isn't. In other words, if it > works, OK; if it doesn't, don't rule out metastability as the cause. ah, the russian roullette [spell] theory of electronics design. if you take your parameters and analyze the failure rate as a result of metastability, then you will see it's a pretty small number, if the system is properly designed, which includes timing margin to resolve flip-flops that have gone metastable. this makes a "qualification by test" somewhat, well, impractical. poorly designed systems may not have enough margin [getting tougher, as the times are getting to be quite small] but worse bad design practices can leave you further exposed to metastable [or logic hazard or whatever] problems.. so, how do you tell if it works? run it in the lab for a day? over a weekend? for a week? for a months? if you have to design systems that run interrupted for, say, 15 years, and it's a critical system - it better not fail. what do you do? and when you test it, how do you know if you get the right combination of parameters? i've been called in to debug systems that were designed for YEARS and then had a failure, frequently blamed on parts or phase of the moon. virtually everytime it was a design defect that was not detectable by just sticking it on a bench and running it. or even cooking it in the oven and moving the voltage up and down. independent of what the design flaw is, assuming that a circuit is good until proven guilty is really a crime against humanity and you shouldn't really have anything to do with electronics, in my opinion. in practice, one should follow barto's law: EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL PROVEN INNOCENT! damn, another reason to have the little red buttons on the front of electronic boxes, rk p.s. sorry 'bout the rant, but people read this stuff, this junk needs to be stepped on, HARD! ================================== > -- > Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124. > OOO - Own Opinions Only. You can fool all of the people some of the time, but > you can't please some of the people any of the time.Article: 13989
I have read that there is effort to design a metastable-proof flip-flop. Anyone have any facts to share? Dan Prysby Peter Alfke wrote: > > Hal Murray wrote: > > > Big snip here. I'm extracting the parts I want to comment on. I > > don't > > think I've tossed too much context. > > > > > I never said that metastability does not exist. I have measured it. > > It does > > > exist, but the recovery delay from the metastable (=balanced) > > condition to the > > > ultimately stable state is so short in modern CMOS latches and > > flip-flops, that > > > the problem has lost most of its impact. > > > > > 1. A modern CMOS latch can go metastable, but recovers so fast that > > the problem > > > is, in most applications, irrelevant. ( see curves in the Xilinx > > data book, > > > page 13-49 ) > > > > I cringe when I see things like that, especially from people that I > > usually > > agree with. > > > > What I meant to say was: > If your asynchronous events occurs at a few MHz rate, and you clock at > less than 50 MHz, and you have a few ns "slop" between the synchronizing > flip-flop and the next flip-flop, and you use modern chips ( I should > say Xilinx XC4000XL, but I don't want to be accused of advertising...), > then you can safely ignore the metastable probability. > > If you try to synchronize an asynchronous even that is well above 10 > MHz, and your clock rate is so high that you have not even 2 ns spare > time, then you should think about meatstability and do some > calculations. > > I wanted to dispel some of the paranoia, and explain that our flip-flops > have become dramatically better, actually more so than the general chip > performance and thus system clock rate. Flip-flop gain-bandwidth > benefits directly from advances in semiconductor processing, while chip > performance unfortunately gets dragged down by interconnect capacitance. > > I did not realize the hornets nest... > > Peter Alfke, Xilinx Applications > >Article: 13990
Hej! Jag har upptäckt ett lustigt beteende hos min 1 årige (groenendal/collie/border collie). Han älskar grisöron, men när han är mätt så gömmer han öronen (grisens öron ...). Han bäddar in de i sin säng, trycker in de mellan kuddarna i soffan, gömmer bakom bokhyllan osv. Jag antar att han beter sig som ekorren och bunkrar upp sin mat. Är detta beteende vanligt hos hundar? Det är min första hund, så jag har inte sett detta bettende förut. God forsättning på det nya året! / Jonas ThorArticle: 13991
Oops, I am so sorry about this... I was going to send the previous message to the swedish newsgroup for dogs. However somehow I sent it to comp.arch.fpga. I suppose there are no swedish speaking dog owners in this group so, please ignore my previous post :( / Jonas ThorArticle: 13992
Hi All, I am working toward the implementation of an FPGA based Image Processing Coprocessor. My work will enable the user to describe Image Operations from a high level description and obtains an efficient FPGA configuration very quickly ( I generate EDIF description in less than 2 seconds for a 3 by 3 convolver for any given weights). I am moving toward the implmentation phase. We think about using MIROTECH ARISTOTLE board ( includes DSP processor). I would appreciate to have any information from someone who has already used this board or has any information about it. Cheers.Article: 13993
>ekuria01@kepler.poly.edu >Hello, I must convert a microcontroller based digital AGC to an FPGA. The >AGC in question uses relatively simple math (adds, shifts, and Look up >Tables). I also need to implement digital peak detectors that peak detect >using and A/D converter. > > I am a novice with FPGAs and my expertiese only extends to micro >coding >for controllers. Any help on how to choose FPGAs, and what company FPGAs >sound >apt for my application will be greatly appreciated. > The key item in you list of functions is the look up table. You will require an fpga with some presettable ram to do a look up. Atlera and Xilinx have products with ram. You should note how much ran you will require and try to match it to the device. The parts with RAM are relatively expensive, so you might consisder using an external rom. The other functions you mentioned should be fairly easy. If your a newby then Altera's integrated software system should be easier. If your looking at using these parts in quantity, and you work for a reasonable sized corporation, then the field service engineers representing the vendor will be glad to help. Good Luck Rocky Lavine Rocky TestArticle: 13994
Rolavine wrote: > The key item in you list of functions is the look up table. You will > require an > fpga with some presettable ram to do a look up. Atlera and Xilinx have > products > with ram. You should note how much ran you will require and try to > match it to > the device. The parts with RAM are relatively expensive, so you might > consisder > using an external rom. The other functions you mentioned should be > fairly easy. > I may be biased, but I would not call the Xilinx Spartan devices "relatively expensive", when they sell for $10 and less. Also, a $70.- software package including a tutorial manual can be bought at amazon.com ( look for Xilinx Foundation Student edition. ) Sorry for the "commercial". Peter Alfke, Xilinx ApplicationsArticle: 13995
Rolavine wrote: > The key item in you list of functions is the look up table. You will require an > fpga with some presettable ram to do a look up. Atlera and Xilinx have products > with ram. You should note how much ran you will require and try to match it to > the device. The parts with RAM are relatively expensive, so you might consisder > using an external rom. The other functions you mentioned should be fairly easy. there are other options for a look up table and i believe that they can be done without either an fpga with sram or an external rom device, depending on the characteristics of the contents, of course. as many devices do not have rom (actel, at6k, dynachip, quicklogic, + whatever), we have spent quite a bit of time looking at this problem. for example, one can code up the rom contents as a constant array in vhdl and then access it in the code, letting the synthesizer map it onto the fpga's architecture. another approach is to code up the contents into a case statement located inside of a process. another approach is to look at the rom as a combinational function, not a memory. then, you can write down logic equations, making each output of the "rom" a function of the "address" inputs. there are several ways to do this, either taking the terms that are a '1', or taking the terms that are a '0' (and of course inverting the output). which method works better depends on a number of factors such as data contents, the synthesis tool being used (and the algorithms implemented in that specific version), the device architecture, and the coding style, discussed above. of course, trying this out results in quite a bit of typing. fortunately, this is easily automated by software, which has been done and quite large tables can be mapped this way, the largest that i have seen done was 16-bit address with 24-bit output, about 10% of the entries used (the rest processed as don't cares since nobody cared what their output was). the vhdl file was 1.6 megabytes and it took 20 minutes to run. good luck! rkArticle: 13996
Dan Prysby wrote: > I have read that there is effort to design a metastable-proof > flip-flop. Anyone have any facts to share? i believe the delivery data has slipped ... until just after delivery of the perpetual motion machine. while modern flip-flops have quite good metastable state characteristics, it is impossible to design a guaranteed by law metastable state proof flip-flop. the best you can do is describe it statistcally; and you can get good performance, making the failure rate insignificant w.r.t. normal cmos device failure rates. also, about 10 years ago, amd (and perhaps signetics) produced metastable-state hardened flip-flops. rkArticle: 13997
This is a VHDL-87 vs. VHDL-93 thing. So a library will not help you. To be portable between both VHDL-87 and VHDL-93 either of the use the following: A <= to_StdLogicVector(bit_vector'(X"BE")) ; A <= to_X01(bit_vector'(X"BE")) ; When Synopsys supports VHDL-93, you will be able to use bit-string literals directly. Call you local Synopsys marketing person and submit a feature request. Cheers, Jim Lewis VHDL Trainer, ASIC and HDL Consultant telejim@teleport.com Adam J. Elbirt wrote: > Does anyone know the IEEE or Synopsys library that must be added to use > bit string literals with std_logic_vectors? > > Thanks. > > AdamArticle: 13998
Also bear in mind that the U and V chrominance signals have half the luminance bandwidth and should be upsampled (interpolated by a factor of 2) before the YUV is matrixed to RGB. Ed. In article <3692B193.3FD685A1@cmln.com>, Brad Taylor <blt@cmln.com> writes >It's amazing what you can get away with in video. If you apply the >non-linearity to YUV and then transform to RGB, it doesn't look too bad, >but it's really not correct and will generate discernable color errors. >The correct way is: > >1) transform YUV to R'G'B' where R'G'B' is the color space of the actual >monitor you are using to display the data. This is different than RGB >which seems to be generally assumed to work with NTSC monitor phosphors. > >2) apply a calibrated look-up-table to each channel. IE: > >R'=Y*c0+U*c1+V*C2+C3; >rout=RLUT[R']; > >This method will ignore non-linear interactions between channnels and >time dependent brightness issues as well as ambient light chroma and >intensity. It also requires you to calibrate the curves, as well as >obtaining an absolute chroma measurement for each of the monitor >phosphors. > >Another method would be to apply a 3D LUT with interpolation directly to >YUV. >Keep in mind that the gamma function is a crude approximation to the >actual luminance curve. Also, monitors drift over time. > >All this probably impractical for your needs, so it would probably be >best to simply do a gamma (R^^2.2) function on the RGB values after >transformation from YUV. > >Best Wishes >Brad > > >Armin Mueller wrote: >> >> Hello, >> >> I know the Gamma correction is normally done in the >> RGB color space (by component). >> >> Would it be possible to do the Gamma directly in YUV terms? >> Sure, the exp-function can't be added, but maybe there are >> some simplifications... >> >> Armin >[ A MIME text / x-vcard part was included here. ] > -- Edward MooreArticle: 13999
thor@sm.luth.se (Jonas Thor) writes:
> Hej!
>
> Jag har upptäckt ett lustigt beteende hos min 1 årige
> (groenendal/collie/border collie). Han älskar grisöron, men när han är
> mätt så gömmer han öronen (grisens öron ...). Han bäddar in de i sin
> säng, trycker in de mellan kuddarna i soffan, gömmer bakom bokhyllan
> osv.
>
> Jag antar att han beter sig som ekorren och bunkrar upp sin mat. Är
> detta beteende vanligt hos hundar? Det är min första hund, så jag har
> inte sett detta bettende förut.
>
> God forsättning på det nya året!
Nja, jag tycker att du skall använda en PLD. Ta tex de senaste Lattice
2032VE, den har bara fyra nanoskeunders fördröjning. På så sätt tjänar
man en klockcykel. Akta dig för metastabilitet, bara!
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
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