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
Hello Bijoy, There is (unfortunately) an enormous number of things that could cause this type of behavior -- most of which are not related to the IP core itself. If you have not already done so, I highly recommend that you submit a case to the Xilinx support team. They can help you debug the issue. The support team can be of most assistance if you are able to provide the schematics for your board and detailed information about what IP core product/version you are using. Eric "bijoy" <pbijoy@rediffmail.com> wrote in message news:ee9d6b3.-1@webx.sUN8CHnE... > Hello all, > > We have made a PCI board using Xilinx PCI core. with master and target capabilities. It works well with intel PCs, but with AMD PCs if i plug the card the PC will not boot. > > Does any one had similar expereince ? Any pointers for the cause will be helpful for me > > Thank you bijoyArticle: 106101
rickman wrote: > KJ wrote: > > > For example, if the statements in > > > case 2 and 3 were swapped, it would still be covered, but produce a > > > wrong result. Is there a way to verify that the wrong result will be > > > caught? > > > > If it doesn't, then this implies that either there was no 'assert' > > to check that the design was working under those conditions or that the > > testbench didn't exercise things adequately to uncover the inadvertant > > 'case swap' or (somewhat unlikely) that cases 2 and 3 really are not > > distinct and really are the same thing to the extent that they cause no > > observable misbehaviour of the design. > > That is what I am referring to. The fact that the statements were > "exercised" is not the same thing as saying they were "tested" to work > correctly. That's correct. The whole point of the assertion statements that get added to the design code and the testbench code are to embed the knowledge of what is 'correct' behaviour. > If a tool can tell you if a statement was exercised under > "all conditions", what exactly does that mean, "all conditions"? I > would assume it means all combinations of the signals that are inputs > to the statement. > With Modelsim's Code Coverage the coverage options you get are: - Statement coverage - Branch coverage - Condition coverage - Expression coverage - Finite state machine coverage - 0/1 Toggle Coverage - 0/1/Z Toggle Coverage That is still somewhat short of 'all conditions' but I'd wager that it would be darn difficult but probably not impossible to get 100% coverage on all of those items and have assertion checking on all of the outputs and still slip a bug through. > I think it is still up to the test designer to determine if the test > distinguishes failures in the code from working code. I agree but I think assertion checking and code coverage (meaning more along the lines of most or all of the above list not just 'statement coverage') are pretty powerful tools at the disposal of the designer to beat pretty heavily on the design without requiring the 'sharp eyes' or the 'smart guy' to get the job reasonably done. Not that such resources shouldn't also be brought in when available though. The things that then get left on the table unchecked are the units of measure that end up crashing probes on to the surface of Mars (at least I thought that was the root cause of that little mishap). Until someone comes up with an automagic way to convert a design specification in to some sort of testbench I would agree with you....which I'm guessing will be until my last dying breath. KJArticle: 106102
ZHI wrote:
> Thanks Mike Treseler
> I am not reading a vhdl netlist. I am reading a uart application
> codes.
Maybe it is a vendor-specific example.
Here is a generic uart example that will work for any device:
http://home.comcast.net/~mike_treseler/uart.vhd
> For example, the input signal (RXD signal) of FPGA firstly
> go through a IBUF then a BUFG. What's the uses of them respectively?
You could use them to sell devices
to customers who don't know synthesis.
> Why need use these buffers? When need use them?
I would never use them directly.
Let synthesis do its job.
> Or we actually don't need to care these buffers at all.
That's it.
-- Mike Treseler
Article: 106103Gurus just talk, I like DO-ers: One guy from Germany: who could that be? Two from Sweden (kind of): Gaisler, Bilsky One dude from UK, his first name is Ken. US: Is Jean Nicolle American? In any case, he is on my list for makeing FPGAs fun! And the guy at Lattice who wrote Mico8 and released it under GPL. Oh, Cliff almost made it into the list... -Bruns Tony Burch wrote: > Hi all, > > I was just pondering the idea of "gurus" & I thought the following questions > may hopefully make some interesting & entertaining discussion. > > Including people in this newsgroup & others working in the field, whom do > you consider to be the present-day "gurus" in FPGA system design? ...I mean > the people who are well known & highly respected for their work & > contributions in this field. > > Who is your favourite guru & why? > > :) TonyArticle: 106104
As to which language will cause less issues with the Xilinx tools, I'm not sure, but my gut tells me that (if there is any difference) they may handle VHDL better because VHDL tends to be more used for FPGAs (at least in the past, but verilog may be catching up?). I remember a Mentor Graphics presentation at an HDL conference 4-5 years ago, and VHDL was the most used HDL for FPGA design, by a wide margin; Verilog was third, behind PALASM! Things have certainly changed since then, but I don't know by how much. But if you don't already know VHDL and the traps within it, perhaps you'd be better off with verilog (depending on how well you know it)? Whether you use VHDL or Verilog, you are probably just as likely to encounter problems because of whichever one you choose! Another thing to consider may be what IP you may be using, and what language it is written in (synthesis and/or simulation), if any. Most synthesis tools can handle mixed languages at the module level, but simulators that can do so may be more expensive. Andy Xesium wrote: > Hi, > > All this information is very interesting. I didn't want to make a new > thread for my question but I was wondering which of these languages can > be used more error-freely while using Xilinx CAD tools ISE and EDK. > Because I already know some Verilog however thinking that VHDL is a > more widely used language!!, I didn't actually dare to use Verilog for > my designs to do simulation or other things that I had to deal with low > level HDL in the tools. I really prefer to use Verilog as I'm more > comfortable with it and I don't want to spend much time learning VHDL > at this time. But I'm afraid that I have to deal with some errors in > EDK or ISE or in my simulation because Verilog is not strongly > supported by Xilinx tools. Do you have any idea about that? > Will I probably face problems just because I'm using Verilog. > > Thanks, > > Amir > > Nicolas Matringe wrote: > > I can't remember who in this newsgroup who knows both and, whichever > > he's using at any given moment, always regrets he doesn't use the other > > language. > > > > NicolasArticle: 106105
Thomas Entner wrote: > > There is no such thing as DDR2 SRAM which implies that the original > > post had a typo. > > Look at this: http://www.necel.com/memory/en/products/sram/ddr-18m.html ;-) > > Thomas I stand corrected. Although I must admit that if all we're talking about is a synchronous SRAM controller then that is almost trivial to put together for oneself....to the point that I wouldn't let the lack of an Altera MegaCore function deter me from using the part if that's what one has in mind. Take an hour or two and write the code. KJArticle: 106106
johnp schrieb: > If your concern is how well Xilinx XST supports Verilog, > I'd have to say it's pretty good. I've been using the > Xilinx tools with Verilog for a number of years now and > it works fine. > > I'd say that picking VHDL or Verilog is not dependant > on the tool support. The tools usually will work fine > with either language. The choice should be made on > which language will work best for YOU, not based > on the Xilinx tools. > > John Providenza > yes, Xilinx verilog support has improved a great deal. for ISE projects its almost no difference - for EDK systems its still a little easier to deal with VHDL - the way EDK propagates params down the hierachy seems to work better for VHDL, also if you are trying to create EDK peripherals where top-levels are in VHDL and those include modules below that are imported from other projects written in verilog, then if those verilog modules use some includes then the all thing doesnt want to compile so nicely any more. the way EDK handles modules and directories - the all verilog define and include concept doesnt play nicely with it. If the EDK ip cores are written in verilog for EDK (and use no includes) then they work ok, also with parameter passing between VHDL and verilog modules AnttiArticle: 106107
Ignore my previous post...I re-read the original post...time to stop and put brain back in. KJArticle: 106108
Thomas Entner wrote: >>There is no such thing as DDR2 SRAM which implies that the original >>post had a typo. > > Look at this: http://www.necel.com/memory/en/products/sram/ddr-18m.html ;-) > > Thomas > and at this [http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=215&gid=5&fid=39&category=QDR-II%2B&showall=false]Article: 106109
"KJ" <Kevin.Jennings@Unisys.com> schrieb im Newsbeitrag news:1154983253.794449.237460@m79g2000cwm.googlegroups.com... > Ignore my previous post...I re-read the original post...time to stop > and put brain back in. Now I have re-read the original post again, too ;-) Maybe one conclusion could be, that "no demand" is quite plausible, as you did not even believe they exist. Regarding the bus-turnaround-time, which was one of the concerns of the OP, I think, I would recommend following: Make a test-cirucit with the bi-dir DDR-IO-registers in Quartus and look what the timing-analyzer reports. I suppose that you will need 1 or 2 "wait-states" for bus turn-around. ThomasArticle: 106110
OK, I see. Thank you , Mike Treseler. By the way, I am using the Xilinx Virtex-II Pro board now. Could you introuduce a good way to learn how to design FPGA? Is this a correct way to read through the Virtex-II Pro and Virtex-II X FPGA User Guide? Many thanks! Zhi Mike Treseler wrote: > ZHI wrote: > > Thanks Mike Treseler > > I am not reading a vhdl netlist. I am reading a uart application > > codes. > > Maybe it is a vendor-specific example. > Here is a generic uart example that will work for any device: > http://home.comcast.net/~mike_treseler/uart.vhd > > > For example, the input signal (RXD signal) of FPGA firstly > > go through a IBUF then a BUFG. What's the uses of them respectively? > > You could use them to sell devices > to customers who don't know synthesis. > > > Why need use these buffers? When need use them? > > I would never use them directly. > Let synthesis do its job. > > > Or we actually don't need to care these buffers at all. > > That's it. > > -- Mike TreselerArticle: 106111
To Andy & Frank,
I forgot some of the properties of the variable statement and
appreciate the feedback. In fact this is exactly what I was trying to
remember as this helped solve the problem. Thank you to both of you.
I've managed to change the signal assignments to variables and also
modified my reset condition so that one of the variable assignments
starts at "start_address - 1" instead of "start_address". During the
first clock cycle it seemed that the variable was updated right away
and therefore caused my comparator to react and for the assertion of
the status flags earlier than I wanted it.
Cheers
Pino
Andy wrote:
> Frank Buss wrote:
> > pinod01@sympatico.ca wrote:
> >
> > > The section that is not functioning according to my description is the
> > > section in the VHDL code that has the IF statement that compares
> > > "updated_addr = comp_addr". Can someone correct the piece of VHDL
> > > code below?
> >
> > I didn't analyze your code in detail, but if you change a signal in a
> > process, it will be not changed until the end of the process. Use
> > variables, if you need some sequential order.
> >
> > --
> > Frank Buss, fb@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de
>
> What Frank said, but with some additional info:
>
> Signal updates are postponed until the assigning process suspends,
> either at an explicit wait statement, or at the bottom of the process.
> Any signal assigned inside the clock-edge if/then clause in a clocked
> process infers a register. Any reference to that signal is a reference
> to the output of the inferred register, no matter when/where it occurs
> relative to any assignment.
>
> Variables update immediately upon assigment. A variable reference
> infers storage (i.e. a register in a clocked process) if the variable
> is read before it is written in a given execution of the process, in
> which case it must "remember" the state from the previous execution. If
> a reference to a variable executes after an assignment to it, then that
> reference infers a combinatorial path instead of a registered one.
>
> Andy
Article: 106112rickman wrote: > I don't follow this at all. I am pretty sure that putting NULL in a > when others clause will create a latch, no? NULL is saying to do > nothing which means hold your present state, ergo a latch. Latches only happen in a combinatorial process! I don't use those. I only use clocked processes (aka single process description) for FSMs (this is one of the main reasons why). In a clocked process, a null would be implemented as a clock-disable, assuming it determined the state was reachable in the first place. On the other hand, they had their restrictions on ada code for SW; I'm the one considering it for VHDL and HW, which has other issues to consider (one of which is your issue in a combinatorial process) > Only if the tool can determine that the condition is not "possible". > Often the condition is a function of how a design is used rather than > how it is built. Given the constraints on the inputs, a condition may > be "impossible" with no way for the tool to know that. Naturally, there are cases where any input condition can happen (i.e. a CPU can access any address within the range binarily represented by the number of bits), but most sythesis tools do simple reachability analysis on state machines and even on counters. With constrained integer types, it is possible to tell them such information explicitly (i.e. natural range 0 to 5 excludes possible 3 bit values for 6 and 7, such that an equality comparison with 5 only takes two inputs, not three), no matter where the info came from (i.e. an external 3 bit port). To what extent they use this depends on the tool provider. You raise a very good point about unconstrained, loosely coupled inputs. You may know that two input conditions are mutually exclusive, but telling that to the tool is usually nontrivial. One application I have found is to make use of a tri-state bus type description, and then tell the synthesis tool to convert tristates to muxes. They automatically assume that tristate enables are mutually exclusive (otherwise the original circuit would not have worked). I wish we had a standard mutex function that we could call in an assertion statement, and the synthesis tool would pick up on it and realize that the inputs to the mutex function were in fact mutually exclusive. AndyArticle: 106113
burn.sir@gmail.com wrote: > And the guy at Lattice who wrote Mico8 and released it under GPL. > -Bruns Do you have more input on open source IP's for FPGAs? Gordon Hands from Lattice is looking for just that type of feedback on his blog. Gordon was heavily involved in the Open IP cores licensing agreement and is looking for more feedback... Gordon writes: "I would be interested in reading comments from users on this topic. Does it make sense to have Open Source IPs for FPGAs? Should Lattice be doing more of this?" here's the link to his blog: http://latticeblogs.typepad.com/frontier/author_gordon_hands/index.html Regards, Bart Borosky, LatticeArticle: 106114
ZHI wrote:
> By the way, I am using the Xilinx Virtex-II Pro board now. Could you
> introuduce a good way to learn how to design FPGA? Is this a correct
> way to read through the Virtex-II Pro and Virtex-II X FPGA User Guide?
You only really need an editor and simulator to get started.
Once you know how to write and simulate HDL code for
synthesis, you can try the design in hardware.
Until then, all you can do with the board
is run the canned demos and flash the LEDs.
-- Mike Treseler
Article: 106115I've written a Xilinx JTAG programmer. It runs on Win32 and Linux Following cables are supported: Parallel III Digilent USB (on Linux it needs libusb, Win32 needs the original driver from digilent, utilizes full USB transfer speed!) Following chips are implemented: Spartan-3 Family XCF Family Virtex-II Pro family If it seems people are interested I'll clean up the code and put it up on sourceforge.net. The most interesting part is the Digilent USB driver. It could be used in other applications too :)Article: 106116
fpgakid@gmail.com wrote: > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux > > If it seems people are interested I'll clean up the code and put it up > on sourceforge.net. > The most interesting part is the Digilent USB driver. It could be used > in other applications too :) Yes - definitely interested! EricArticle: 106117
larwe wrote: > Antti Lukats wrote: > > >>>Goddamn, I hate Xilinx's software. Nowhere - NOWHERE in the >>>documentation with the ML403 does it state that the license is limited >>>to one year. >>> >>>Is the ISE installation similarly limited? >>> >> >>ISE is also sold as 'time based license' yes. > > > This is rampant bullshit, and it is PRECISELY why proprietary > development tools are so dangerous. It is not disclosed anywhere on the > purchasing/specifications page for the ML403 EDK bundle that all this > software is time-limited crippleware. Likewise, it is not disclosed > anywhere in the software or any installed documentation. It is ONLY > mentioned on the web site in an unrelated and semi-buried page. > > In this case it isn't much money - $500 per year isn't a whole lot, and > it's tax deductible. But how much is EDK? And where do they disclose > this information about the price, or is it a case of "if you have to > ask, you can't afford it"? > > I'm emailing Altera and Xilinx simultaneously; whichever one offers the > better deal for someone who's going to write about their products and > never field a design, that's the one that goes into my next book. > Fortunately I wasn't working on this section of it yet! I've crossposted this, so someone in Xilinx can comment on the Details. The link Antti gave does not mention webpack, or Microblaze, and I believe the webpack does not expire ? I would expect MB to be a one-time license, "solely for use in developing designs for Xilinx Programmable devices." You should also note that Xilinx's have 'separated from the pack' in that their latest webpack (free) does NOT support any of their newest V5 devices, as a matter of policy. -jgArticle: 106118
On Mon, 07 Aug 2006 16:26:36 -0700, fpgakid@gmail.com wrote: > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux > > Following cables are supported: > > Parallel III > Digilent USB (on Linux it needs libusb, Win32 needs the original driver > from digilent, utilizes full USB transfer speed!) > Could it support the FTDI-2232? Peter WallaceArticle: 106119
ZHI wrote: > Thanks Mike Treseler > I am not reading a vhdl netlist. I am reading a uart application > codes. For example, the input signal (RXD signal) of FPGA firstly > go through a IBUF then a BUFG. What's the uses of them respectively? > Why need use these buffers? When need use them? > Or we actually don't need to care these buffers at all. BUFG is a buffer which drives a global clock network. IBUF is a buffer from the input pin. IBUF->BUFG would typically be used when an external pin is used to drive a clock signal and the pin is NOT a dedicated clock input. Ideally a synthesizer would handle this automatically. Sometimes the tool is not smart enough. Instantiating BUFG directly forces it to route the signal on a global clock net. Having said that, treating a UART RXD signal as a global clock sounds rather bizarre. -JeffArticle: 106120
Hi, The board details are as follows. PCI-32 bit 33 MHz (so M66 is connected to GND) Master/Target functionality. The device does work along with other PCI devices. ( TV tuner card, PCI NIC card etc) Only memory space enabled. Only 1 BAR enabled. Decode speed : medium Clock : PCI clock going to dedicated GCLK pin. FPGA : XC3S200-144TQFP, with XCF01 (1 M flash) (PROM configuration speed is default (6MHz) ) What is this PDE ? Also what do you mean by BIOS speed contrary... ? i belive PCI decode speed is not settable in BIOS. The exact symptoms are : Intel motherboards -> works fine (845, 865, 915 etc) VIA motherboard A7VBX-MX (AMD) -> PC does not even give the "all ok" single beep at power on. monitor, keyboard, mouse all appear dead. CPU fan keeps whirring but PC does not boot. looks like we will have to open a webcase. Thanks -BijoyArticle: 106121
JJ wrote: > Myself I vote for the one that begins with V. > > Now if the C language would pick up some major extensions the likes of > which we see in HDLs such as open ended bit sizes and the same notion > of concurrency and nested modules I could probably do most everthing in > a HDL C combined with regular C. If the compiler would spit out HDL for > regular synthesis and allow HDL code to be simulated at C speeds, that > would be neat. Most of the C based HDLs offer some means to assign arbitrary bit widths to objects, frequently in ways that break ANSI C compatability. Bit fields do however existing in the language, and in ways that are actually pretty useful for most applications. Still, one of my nits in doing FpgaC is to carry a proposal to the ANSI committee to allow bit fields that are larger than the native type, forcing the compiler to handle a 200 bit or 64 bit object the same on both an 8bit micro and a 128 bit super computer. In FpgaC, I'm not sure there is a limit on the width of an object, other than constants, which is something I'm already working toward fixing. As for concurrency, that is something that hardware guys miss understand completely. Every compiler is free to shuffle/reschedule the code produced, as long as the results have the expected serial symantics. Out of order execution and multiple issue pipelines, ARE concurrency. As are threads, pipes, processes, and many other concurrent abstracts in what appears a sequential language. In FpgaC everything in a statement group is completely concurrent. Other C based HDLs offer other concurrency rules, from statement level clock timing, to explict construction of parallelism using hardware HDL semantics. Synthesis in FpgaC is becoming better, actually better than VHDL/Verilog, as I'm working on better technology mapping. My current development copy of FpgaC does optimizations effectively, that VHDL/Verilog can not do. The difference, is that with VHDL/Verilog you describe the circuits that must be built, and the HDL is pretty much obligated to build the circuits that are described. In high level languages, the programmer describes the result wanted, and the compiler is free to implement those results in the best way possible. In the old days, you wrote in assembler to get exactly the code you wanted executed, just as you write VHDL/Verilog to get exactly the hardware you want. While some folks think this is "advanced" over schematic designs, it's only advanced as assemblers are over programming directly in binary. Because of the extensive timing and instantiation control in the languages, the VHDL/Verilog synthesis tools are obligated to implement the circuits as described ... and this will forever be a handy cap. With higher level languages, which avoid specific details about the instantiation, then the compiler becomes free to choose whatever hardware that will produce the described results, and optimize out everything else that doesn't matter. Vhdl/Verilog really lack that freedom, when the design description is as precise as what clock edge, and what logic level, every object is at. In my testing some new tech mapping a few months back, I described a very very elaborate demo system that instantiated a very complex control system filter combining 60 inputs which produced a single bit output controlling a PWM driver. The synthesis result I thought was in error, as none of the multipliers, adders, comparitors, or feedback in the filter existed in the four term sum of products result .... four 30 variable AND terms OR'd togather, in just over 120 LUTs. However, the optimized circuit simulated to the expected test vecors, just as did the previous version of the design that was over 3,100 LUTs produced by the stock Beta-2 release. The combinatorial depth of the original synthesis was 47 LUTs deep which would have required extensive pipelining and retiming, and only 6 deep after optimization. Another crypto demonstration program is even better, which I will describe in a paper this fall, as the results shatter expectations about the strengths of certain cyphers, especially when large FPGA super computers are available. There are simplifications and optimizations available to bit structured machines, which are simply not possible for most sequential word machine architectures, and from that comes a different reality than "normally assumed" today. While my interest in FpgaC is to build useful FPGA super computers in the future, it's a love of both hardware design, and software design, that enables that vision. That is not a reasonable vision, while the only tools to program fpga designs, and at the bit and clock edge level. I suspect, that just as assembler, and even 'low level" C is no longer in favor for complex designs today ... there will be an evolution where high level HDL tools move away from detailed hardware description at the clock and signal level detail, and move up so that system level specification which includes the interface descriptions and leaves the internal hardware description clearly to the tools to optimize and produce. I'm not the brighest tool designer on the planet ... actually just a wet eared newbie ... so if I can get FpgaC to do these things with a little magic, I'm certain the better guys on the planet that do this for a living will blow some socks off with system level C languages. I'm actually looking foward to a SystemC tool based on C++ sematics that has really good synthesis ... maybe a few years from now?Article: 106122
fpgakid@gmail.com <fpgakid@gmail.com> wrote: > I've written a Xilinx JTAG programmer. It runs on Win32 and Linux > Following cables are supported: > Parallel III > Digilent USB (on Linux it needs libusb, Win32 needs the original driver > from digilent, utilizes full USB transfer speed!) > Following chips are implemented: > Spartan-3 Family > XCF Family > Virtex-II Pro family > If it seems people are interested I'll clean up the code and put it up > on sourceforge.net. > The most interesting part is the Digilent USB driver. It could be used > in other applications too :) Is is related to XC3Sprogs? The sourceforge site of xc3sprog has seen some traffic now. Perhasp some things could be shared? How did you derive the Virtex-II Pro family programming algorithms? Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 106123
I'm surprised no-one's mentioned Ray Andraka, he who mixes the black arts (DSP stuff) with FPGAs and seems to know what he's talking about ;-) He and Peter Alfke would be my two nominations. NialArticle: 106124
Thank you all. I have a strange thing now. I implemented one algorithm into FPGA board. I sent data generated by Matlab from PC to FPGA board. And the results are sent back to Matlab. Becuause I need caculate the bit error rate, I tried it many times. I set the number of trials is 10000. It did work in some trials at first but stopped at a random trial. The Matlab always show busy but not continue to next trial. I have to close Matlab and try again. The phenomenon happens every time. Is this the problem of my vhdl codes=EF=BC=9F But how can it successuflly work for some trials (even reached 9883 trial)? How to fix it? Jeff Cunningham wrote: > ZHI wrote: > > Thanks Mike Treseler > > I am not reading a vhdl netlist. I am reading a uart application > > codes. For example, the input signal (RXD signal) of FPGA firstly > > go through a IBUF then a BUFG. What's the uses of them respectively? > > Why need use these buffers? When need use them? > > Or we actually don't need to care these buffers at all. > > BUFG is a buffer which drives a global clock network. > IBUF is a buffer from the input pin. > > IBUF->BUFG would typically be used when an external pin is used to drive > a clock signal and the pin is NOT a dedicated clock input. > > Ideally a synthesizer would handle this automatically. Sometimes the > tool is not smart enough. Instantiating BUFG directly forces it to route > the signal on a global clock net. > > Having said that, treating a UART RXD signal as a global clock sounds > rather bizarre. >=20 > -Jeff
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