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
shahzad2512@my-deja.com wrote: > I have to implement the following: > 1. 8032 microcontroller, > 2. 64kbytes SRAM, > 3. some 8 latches and two 3x8 decoders, > 4. 12kHz Generator > 5. 16kHz detection > 6. DTMF dialer. > > The above is the customized solution for a telephone set for some > telecom company. > > After some initial study, i think that Virtex could give me solution. > There is also an A/D converter(which i might need) in the Virtex and > such a large memory could only be implemented in an Virtex. The A/D is news to me, unless you want to build a delta-sigma converter. Virtex would be an overkill for this. With the exception of the memory and ADC, you could get the rest of this into a spartan or spartanII device. True, you could have the 64Kx8 in a large virtex EM, but you'll pay alot more than you would for a small FPGA and external RAM. You might look at the Triscend chip. It's an 8032 with integrated FPGA fabric that isn't all that different than the xilinx 4K fabric. It also has a fair amount of memory on-chip, but I think that is less than 64Kx8. > > > But then i thought that since Virtex is expensive, this is not a good > solution. I thought of SPARTAN II but then SRAM is out. > What do u thing and suggest. > Any comments........? > Thanks and Regards, > SHAH > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- P.S. Please note the new email address and website url -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 22576
ASIC = Application Specific Integrated circuit. Generally these are considered to be chips that are manufactured for one specific application...they do that task well but are not suited to doing much anything else. FPGAs end function is determined by a user program, so all the FPGAs come off the chip fab looking the same. The user then configures them for his application through a bitstream. Sharp wrote: > i'm newbie to this field > > what is the diff between an asic and fpga? > > sharp -- P.S. Please note the new email address and website url -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 22577
You need to instantiate the SRL16 rather than infer it to do this. Then put an INIT= value attribute on the instance label. to do the attribute use this in your architecture declarations: attribute INIT: string; attribute INIT of U1:label is "<your ascii hex string here>"; Refer to the libraries guide for details of the INIT usage for SRL16's. Tim Courtney wrote: > With SRL16 I am trying to specify an initial value without resorting to > playing with tools like JBITs. It's really doing my head in. Any ideas > out there? > > -- > Tim Courtney > Electrical & Electronic Engineering mobile : +44 (0)7801 250 903 > The Queen's University of Belfast tel(wk) : +44 (0)28 9027 4275 > Ashby Building, Stranmillis Road fax : +44 (0)28 9066 7023 > Belfast, Northern Ireland, BT9 5AH e-mail : t.courtney@ee.qub.ac.uk -- P.S. Please note the new email address and website url -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 22578
FPGAs will continues to replace asics where the FPGA costs end up being less (FPGAs being much lower NRE and time-to-market). FPGA-like logic will become very common in the System-on-a-chip environment, for undefined at fabrication-time I/O and operations. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22579
shahzad2512@my-deja.com wrote: > > Forget about what the FPGA vendor says about the future of the FPGAs. > Let us have discussion from professionals who are and have been working > in these areas. Discussion might be or may not be limited to the > following: > > Its true that FPGAs will never replace ASICs but will penetrate the > ASIC market in one way or the other. > > FPGAs will be used mainly for prototyping and educational environment. Ignore the vendor, and look what NASA, and other high speed processing users are doing. Using FPGA as reconfigable processing units is a function that cannot be duplicated in ASIC in a meaningful way. However, there might be a market for a new form of FPGA that was specialized for various types of processing. I think the more likely future would see ASIC getting less and less share of all but the biggest markets, and FPGA's taking over. For most applications FPGA's have more than enough performance, and are a much smaller risk. For my field of Defense the main issues with ASIC are time and risk. If you screw up a FPGA design, you down-load again. If you mess up an ASIC, you are looking at weeks of delay. That's just not tolerable anymore. I think FPGA's have a reasonable chance of replacing micro-contollers through emulation for applications where you have a microcontollers and several Digital Support IC. So FPGA's are here to stay, at least in the high performance processing area, and should continue to take market share from ASIC and conventional ICs as even commercial products become more and more short run items. In addition, as ASIC vendors finally reach maturity, ASIC design won't all that different from FPGA design. In both cases it will be a major of hooking together your own or someone else's IP in a higher level language, and then giving it to a program to fit in a device. So I don't see a lot of difference between the two job, other than the fact the FPGA designer maybe more algorithm oriented. Muddy > > There is going to be a market saturation very soon for the businesses > providing cores for FPGAs. > > The demand for job market for FPGAs is not very huge. > > The expected growth for PLD industry for the year 2000 is 35% > > Cheers, > SHAH > > Sent via Deja.com http://www.deja.com/ > Before you buy.Article: 22580
"Johan Kwisthout" <j.kwisthout@observator.com> wrote:
> I recall WP5.1 had a character for that, which (in my experience)
> noone ever used. Everyone types an 'i' and a 'j' instead of the dotted
> y.
And I even stopped using my real name
de Mu˙nck --> de Muijnck --> de Muynck
just for Internet ease...
(Note: the ˙ character is alt-152 on a PC numeric pad. It may not be visible
on non-PC systems or in other language settings).
Regards,
Arie de Muynck
arie at ademu dot com
Article: 22581On Mon, 08 May 2000 16:53:54 -0700, Jon Kirwan <jkirwan@easystreet.com> wrote: >I suppose that the term mutex might be applied to any specific >implementation that guarantees "mutual exclusion," even message-based. >But most of the use I've heard put to the term relates to this >obvious, special purpose use of semaphores. Correct. "Mutex" [in CS] is a generic term referring to any mechanism of mutual exclusion. The simplest using shared memory is the binary semaphore, the most complicated is Hoare's monitor construct. Separate memory, IPC implementations have given us distributed queuing, reservation, blackboarding, priority election, etc. In the '70s there was an explosion of papers proposing new ways to provide mutual exclusion under various contexts. There were so many papers published in such a short time that I was convinced CS researchers were doing nothing else. The '80s brought another round with network implementations. The use of "mutex" to refer to a particular implementation [effectively a binary semaphore] came with MS Windows. Unix had binary "mutex" semaphores prior to Windows, but the vast numbers of Windows programmers [having no other experience] brought the term into general use. George Neuner Dynamic Resolutions, Inc. =================================================== The opinions expressed herein are my own and do not reflect the opinions or policies of my employer. ===================================================Article: 22582
Quick thoughts: <shahzad2512@my-deja.com> wrote in message news:8fgkf4$euq$1@nnrp1.deja.com... > Its true that FPGAs will never replace ASICs but will penetrate the > ASIC market in one way or the other. Yes. FPGAs, if anything, are advancing in their speed and density faster than ASICs are. Although ASICs will always be cheaper for high volume runs, FPGAs will continue to look more and more attractive for small volumes and some mid-volume projects. > FPGAs will be used mainly for prototyping and educational environment. Nope. > There is going to be a market saturation very soon for the businesses > providing cores for FPGAs. Hard to say. Cores are a new field, and it's very difficult to make money with them at the moment. The market model of IP isn't even really all that solid yet. Heck, the market model for EDA tools isn't either. I do think that "standard cores" along the lines of data processing, CPUs, bus interfaces, etc. have a bright future. > The demand for job market for FPGAs is not very huge. Compared to what? Compared to, say, PC programmers for "dot com" companies, sure. But compared to, say, RF design engineers, there's lot of FPGA design jobs out there. And people who can combine FPGAs with one of these other "small" -- but technically challenging -- fields, such as digital radio front ends, video/audio signal processing, etc., are in a very good position to find themselves continuous employment. And throw in being able to program PCs at a decent level, and you can just about write your own check... > The expected growth for PLD industry for the year 2000 is 35% I'd have to refer to some trade magazine for that one. ---Joel KolstadArticle: 22583
All good points however I would be more interested to discuss if the fpga can move from all digital to a mix of analog and digital with the addition of a/d converters and configurable op-amps and comparators.Article: 22584
<shahzad2512@my-deja.com> wrote in message news:8fglhp$frl$1@nnrp1.deja.com... > I have to implement the following: > 1. 8032 microcontroller, > 2. 64kbytes SRAM, > 3. some 8 latches and two 3x8 decoders, > 4. 12kHz Generator > 5. 16kHz detection > 6. DTMF dialer. > > The above is the customized solution for a telephone set for some > telecom company. Sounds a lot like a homework assignment to me... > After some initial study, i think that Virtex could give me solution. > There is also an A/D converter(which i might need) in the Virtex and > such a large memory could only be implemented in an Virtex. There isn't an A/D converter in a Virtex FPGA, although you can certainly build crude ones with just a couple of extra components -- but the same thing can be done with a CPU. In your case, however, at audio frequencies you're probably much better off just buying some little ADC chip with something like a serial interface that'll plug back into your 8032. > But then i thought that since Virtex is expensive, this is not a good > solution. I thought of SPARTAN II but then SRAM is out. You're correct, using a Virtex part just to get the 64KB of (block) RAM is a very expensive way to go. If you're bound and determined to use an FPGA, a Spartan with a small RISC CPU embedded, 64KB of external SRAM (one IC), an external codec containing an ADC, DAC, and companding circuitry, and a little bit of analog glue would get you going on the cheap. But this assumes you have the high volumes necessary to justify the development or purchase price of a CPU core. If you don't, the microcontroller alternative looks very attractive. If you're doing this on a small budget and need to do it reasonably rapidly (in a matter of months), the 8032 approach is definitely going to be a much lower risk approach than the FPGA one. You need to determine what your "time and money" constraints are to fully answer this question. ---Joel KolstadArticle: 22585
Anyone help me.!!! I'm a graduate school of keio univ. in japan. my home work is search, I am searching a market size of fpga and kasutamu ic. if anyone has a information. please help me. my e-mail;embargo1@mag.keio.ac.jpArticle: 22586
> shahzad2512@my-deja.com wrote:
>
> > I have to implement the following:
> > 1. 8032 microcontroller,
> > 2. 64kbytes SRAM,
> > 3. some 8 latches and two 3x8 decoders,
> > 4. 12kHz Generator
> > 5. 16kHz detection
> > 6. DTMF dialer.
> >
> > The above is the customized solution for a telephone set for some
> > telecom company.
Why SRAM?
No Non volatile memory?
Will you execute code from the SRAM?
If so , how much of the SRAM will be code and how much will be data.
Are You going to write in C?
If that is that is the case, then you might want to look at the Atmel
FPSLIC.
This has 40k FPGA gates + a high speed RISC processor.
YES! we do have first silicon nowadays!!!
The FPSLIC only has 36 kB of SRAM, but the code density is way superior
to the 8051 when you program in C so you might still win.
Check www.atmel.com for Programmable SLI.
If you can live with Flash instead of some of the SRAM,
I think there are better solutions though.
You can get an ARM based controller with
onchip Telephone oriented ADC/DAC = Combo circuit and SRAM
+ DSP doing what you want and more for less than an FPGA solution
would cost.
--
Best regards,
ulf at atmel dot com
Article: 22587"myself" <myself@magma.ca> wrote in message news:391c34b6.17313175@news.magma.ca... > All good points however I would be more interested to discuss if the > fpga can move from all digital to a mix of analog and digital with the > addition of a/d converters and configurable op-amps and comparators. Can be done today in ASIC! Send a Purchase Order :-) May be more expensive than discrete alternatives, since normally the pure CMOS process is available well in advanced of the mixed signal processes, but since you can integrate both FPGA blocks and analog blocks in ASIC, there is nothing technical to stop you from doing it. -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel SwedenArticle: 22588
shahzad2512@my-deja.com wrote:
> FPGAs will be used mainly for prototyping and educational environment.
No, but it might be safe to say that prototyping and education will be done
mainly with FPGAs. As will many scientific projects that require one-of-a-kind
custom processors and data acquisition.
> There is going to be a market saturation very soon for the businesses
> providing cores for FPGAs.
For two reasons:
1) More and more free cores will be available from chip vendors and hackers.
2) Tools will improve significantly, making it almost as easy to create custom
code as it is to buy and use cores.
My prediction:
Although I don't like to use buzzwords like "paradigm shift", circuit design
is long overdue for one. VHDL will bite the dust when someone comes up with a
sensible way of designing, simulating, and synthesizing FPGAs. (Preferably one
that doesn't mangle signal names :)
--
Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab Phone: 630-840-3668
Batavia, IL 60510 Fax: 630-840-5406
Article: 22589> Sharp wrote: > > > i'm newbie to this field > > > > what is the diff between an asic and fpga? I think it is a little bit more complex. ASIC stands for (As Ray mentions) Application Specific Integrated Circuit. Some people give it a further interpretation/restricting it to be a gate array. Others mean that ASICs are circuits which are designed by a customer for a specific purpose and if the semiconductor vendor designs the circuit it is either for a single customer and is then called CSP (Customer Specific Product) or for a few/many customers in which it is called an ASSP (Application Specific Standard Product). I personally think that if the word ASIC should have ANY practical use, this is the one I'd go for, regardless of the actual meaning of the words. I do not need a synonym for gate array, I'd rather just call it a gate array!!! Now when a customer can design a circuit for a specific purpose where one core part is an FPGA block allowing him some reconfigurability what do we call that? > > > > sharp > > -- -- Best regards, ulf at atmel dot com The contents of this message is intended to be my private opinion and may or may not be shared by my employer Atmel SwedenArticle: 22590
> Its true that FPGAs will never replace ASICs but will penetrate the > ASIC market in one way or the other. > This is wrong. When quatum dots or nanotube FET's come along there will be no more ASICS or processors or any kind of device that does logic with the exception of special I/O and power requirements other than reconfigurable (FPGA like) processors. Processors and digital subsystems will all be in the same reconfigurable devices because of bandwidth problems created by placing these things in seperate packages. Steve Casselman, President Virtual Computer CorporationArticle: 22591
All, We have 4 SRAMs hanging a Xilinx VirtexE 1000. We are investigating how to clock them. One possible solution gets DRC errors when we run through the tools and we don't understand why. Here is the scenario. We want to use a DLL to generate the clock, send the output of the DLL to a BUFG, and then the output of the BUFG to multiple OBUFs. These would be the clocks for the SRAMs. The feedback to the DLL, the CLKFB pin, would come back in from outside the chip, to an IBUFG, and then to the CLKBF pin of the DLL. This all works fine and is standard if we only send the output of the BUFG to "ONE" OBUF, but if we try to fan this out to multiple OBUFs it doesn't work....we get DRC errors......why. Also, if we use internal feedback, instead of going offchip, we can send the output of the BUFG to multiple OBUFs. I know this feedback is worthless, but we tried it just for the heck of it. Separatly, we can send the output of a BUFG to multiple OBUFs, and the output of a DLL can go to the input of a BUFG. Put these together and you get DRC errors. I understand that the feedback is supposed to be a delay compensator for your outside path and the DLL uses this to adjust the outgoing clock. If we assume that the outside traces and loads for these different clocks are the same (designed that way), then we should be able to take the feedback from one of these and hook it to CLKFB, but again, it doesn't work. Also, as we haven't gotten this through the tools, we don't know what the skew would be between the different OBUFs. We were assuming since the OBUFs are fed by the BUFG, there would be very little skew??? Any thoughts. If someone has designed a bank of 4 SRAMs off of a single FPGA it would be very helpful to see your sceme...both on the FPGA and at the board level. We are investigating other ways of doing this, but would like to understand why this doesn't work. Her is the error we get......anyone know how to get around the DRC error and how bad of an idea this is???? Probably not a good one. ERROR:DesignRules:365 - Blockcheck: Improper DLL feedback loop. Signal wclk100 is driving pin IN of comp bufg1. Since pin CLKFB of DLL clkdll2 is driving by an GCLKIOB, its output must drive the O pin of IOB. TomArticle: 22592
Hi John - A good general overview of ASIC prototyping boards using FPGAs can be found at: http://www.optimagic.com/boards.html I also would like to point you to Synplicity's Certify tool, which I am the marketing director for. Certify is a point tool specifically for transforming a single chip ASIC RTL (Verilog or VHDL) into multiple FPGAs for the purpose of prototyping, including prototype-level timing analysis and synthesis. You can check out Certify at our website (http://www.synplicity.com). If you contact me directly I can let you know about other people inside Motorola who are using Certify (johng@synplicity.com). Cheers, John John Fielden <john.fielden@abcmotorola.com> wrote in message news:8ffcfm$e9r$1@schbbs.mot.com... > I need a multi FPGA board to do ASIC verification. So far, I've looked at > WildStar (by Annapolis Micro) and RSPE (by Viasat). > > Can anyone reccomend another board I should look at? > > Thanks, > > John > >Article: 22593
On Fri, 12 May 2000 14:26:39 GMT, Ray Andraka <ray@andraka.com> wrote: >> After some initial study, i think that Virtex could give me solution. >> There is also an A/D converter(which i might need) in the Virtex and >> such a large memory could only be implemented in an Virtex. > >The A/D is news to me, unless you want to build a delta-sigma converter. Xilinx has been recruiting mixed-signal ASIC people for a long time - possibly an announcement on the way? EvanArticle: 22594
Was it always written so, or only when it represented the Dutch ij combination? I believe that I remember that Hilda Conrady Kingslake, in a biography of her father, implied that y-cum-umlaut was common only in words and names originally Dutch. Maybe I remember wrong. (I had a colleague at RCA whose name was Miiller. He said that the family name was originally Müller, but that some ignoramus at Ellis Island had read it wrong.) Jerry -- Engineering is the art of making what you want from things you can get. ----------------------------------------------------------------------- Herman wrote: > > In bygone days, the letter 'y' was written with an umlaut (German - > don't know the English for that one) which is two dots on the 'y', which > makes it look almost exactly like 'ij', and these characters were in > fact equivalent. > > Jerry Avins wrote: > > > > Johan Kwisthout wrote: > > > > > > ... > > > > > > It's Dijkstra (turn the i and j the other way around). ... > > > > > > >>Johan. > > > > I remember the order because it looks like the letter "y" (with two > > tittles) in script. The great British (later, US) optical designer > > Conrady was born Conradij in The Netherlands. > > > > JerryArticle: 22595
hello, just installed xilinx foundation tool... when i do a vhdl syntax check, no error report is generated, although there are errors ... Any idea what the problem might be? thank you fvds12@yahoo.comArticle: 22596
For my school project I need a few (5-10) ql16x24b-()pl84() parts. Does anybody know where I can buy those? I used WebASIC program, but I need to have a few blank parts. Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22597
--------------76A992EE203403ECE7446D70 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ray Andraka wrote: > William, > > I forgot to mention, there is a second way to keep it as registers without monkeying > with the reset: You can use the syn_keep attribute on the intermediate signals to > keep them from being collapsed into an SRL16. For example a 10 clock pipeline: > Only for us sensible people using Synplify. Do FPGA Express/Compiler & Spectrum have equivalent option flags ? --------------76A992EE203403ECE7446D70 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <p>Ray Andraka wrote: <blockquote TYPE=CITE>William, <p>I forgot to mention, there is a second way to keep it as registers without monkeying <br>with the reset: You can use the syn_keep attribute on the intermediate signals to <br>keep them from being collapsed into an SRL16. For example a 10 clock pipeline: <br><a href="http://www.fpga-guru.com"></a> </blockquote> Only for us sensible people using Synplify. Do FPGA Express/Compiler & Spectrum have equivalent option flags ? <br> </html> --------------76A992EE203403ECE7446D70--Article: 22598
(Note trimmed followups. This doesn't even belong there, except for the amount of stress-relief it seems to be giving us... :-) Jerry Avins (jya@ieee.org) wrote: : Was it always written so, or only when it represented the Dutch ij : combination? I believe that I remember that Hilda Conrady Kingslake, in : a biography of her father, implied that y-cum-umlaut was common only in : words and names originally Dutch. Maybe I remember wrong. (I had a : colleague at RCA whose name was Miiller. He said that the family name : was originally Müller, but that some ignoramus at Ellis Island had read : it wrong.) Is it not possible that the whole "y-umlaut" issue is the result of someone mistaking a _ligature_ for a _letter_? Printers often use ligatures (composite characters representing commonly occuring digraphs and trigraphs such as 'ff', 'ffl', etc.) An 'ij' ligature could look an awful lot like a y-umlaut to someone who was making up the PC character-set and had a few too many Cuba-Libre's at lunch... :-) ( I speak neither German nor Dutch, despite having ancestors from both, but I have never seen a "y-umlaut" that _wasn't_ a stand-in for 'ij' ) Compare and contrast to my Japanese teacher whose name could no longer be properly spelled because 'ye' had been dropped from the official hiragana :-) Mike : Jerry : -- : Engineering is the art of making what you want from things you can get. : ----------------------------------------------------------------------- : Herman wrote: : > : > In bygone days, the letter 'y' was written with an umlaut (German - : > don't know the English for that one) which is two dots on the 'y', which : > makes it look almost exactly like 'ij', and these characters were in : > fact equivalent. MikeArticle: 22599
I am not sure that I understand your clocking scheme as it is difficult to describe clearly. But it sounds like you are trying to generate a clock inside the FPGA and use the DLL to compensate for the delay getting the clock off of the chip and distributing it around the board. I am not sure, but I don't think the FPGA DLL is designed for that. My understanding of how it is intended to be used is to synchronize the clock inside the chip to one coming in from the outside. This is roughly opposite to how you are trying to do it, but unless you have some really long board traces it should work for you. If you have trouble with the clock delays in the traces on your board, you should add a multioutput PLL clock chip to the board so that a separate output feeds each chip clock pin. Keep all of the clock traces on the board the same length. This will minimize the clock skew on the board. Then use the FPGA DLL to minimize the clock skew between the board clock and the internal clock in the FPGA. That should take care of your skew problems. Tom McLaughlin wrote: > > All, > We have 4 SRAMs hanging a Xilinx VirtexE 1000. We are investigating how > to clock them. One possible solution gets DRC errors when we run > through the tools and we don't understand why. > > Here is the scenario. We want to use a DLL to generate the clock, send > the output of the DLL to a BUFG, and then the output of the BUFG to > multiple OBUFs. These would be the clocks for the SRAMs. The feedback > to the DLL, the CLKFB pin, would come back in from outside the chip, to > an IBUFG, and then to the CLKBF pin of the DLL. This all works fine and > is standard if we only send the output of the BUFG to "ONE" OBUF, but if > we try to fan this out to multiple OBUFs it doesn't work....we get DRC > errors......why. Also, if we use internal feedback, instead of going > offchip, we can send the output of the BUFG to multiple OBUFs. I know > this feedback is worthless, but we tried it just for the heck of it. > > Separatly, we can send the output of a BUFG to multiple OBUFs, and the > output of a DLL can go to the input of a BUFG. Put these together and > you get DRC errors. > > I understand that the feedback is supposed to be a delay compensator for > your outside path and the DLL uses this to adjust the outgoing clock. > If we assume that the outside traces and loads for these different > clocks are the same (designed that way), then we should be able to take > the feedback from one of these and hook it to CLKFB, but again, it > doesn't work. > > Also, as we haven't gotten this through the tools, we don't know what > the skew would be between the different OBUFs. We were assuming since > the OBUFs are fed by the BUFG, there would be very little skew??? > > Any thoughts. If someone has designed a bank of 4 SRAMs off of a single > FPGA it would be very helpful to see your sceme...both on the FPGA and > at the board level. > > We are investigating other ways of doing this, but would like to > understand why this doesn't work. > > Her is the error we get......anyone know how to get around the DRC error > and how bad of an idea this is???? Probably not a good one. > > ERROR:DesignRules:365 - Blockcheck: Improper DLL feedback loop. Signal > wclk100 is driving pin IN of comp bufg1. Since pin CLKFB of DLL clkdll2 > is > driving by an GCLKIOB, its output must drive the O pin of IOB. > > Tom -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.com
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