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
Gabor, Those ceramic packages had been contaminated in a bath of nitric acid that had been used to dissolve some lead, so it bathed them in the actinides, and plutonium decay isotopes...famous story. If manufactured from low, or ultra low alpha materials, ceramics can be as good as anything else. Basically, if it ever got close to lead, you have 4.5 billion years of decaying uranium and plutonium to deal with. If people smoke cigarettes, you have Polonium 210 in the fertilizer used, so the smoke is radioactive (one reason why people get cancer from smoking). Get that smoke into the chips, and you are in trouble...upset rates go up by a factor of ten (I have measured it). So, today, we buy laser separated lead for bumping (ultra low alpha lead), and epoxies, mold compounds, etc all of the highest purity. So does (most) everyone else who cares about alpha particles. Tested before the material is shipped, tested again before we use it. Assembled in a line that has no non-pure materials, only on their own dedicated machines, never used for a "regular" material assembly lot....and no smoking. There are lots of chips out there where the manufacturer doesn't care how they get manufactured/assembled, as the application has such buggy software, that soft errors are the least of their problems. The recent paper by google is pretty scary, and typical of this market (PC's). http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf So, bad signal integrity, poor design, is thousands of times more errors than alpha particles....but, maybe some of these are alphas? Regardless, there are those that do care, and we do spend a lot of effort to keep the bad isotopes at bay, and out of the process, but it is impossible to remove all of them altogether. As is typical of alpha contamination, NO ONE will confess to having the problem, and they bury their dead quickly, and quietly. But, the stories leak out: an ASSP this year (recall), an ASIC packaged wrongly (another recall), a 'bad' DRAM chip (another very quiet wholesale recall). Like I say, we "been there, done that" and have no intention of having that happen ever again. Honesty (still) is the best policy. Oh, and verify, test, qualify. AustinArticle: 144151
On Nov 13, 8:34=A0am, jay <heavenf...@gmail.com> wrote: > On Nov 13, 10:58=A0pm, johnp <jprovide...@yahoo.com> wrote: > > > > > On Nov 13, 6:19=A0am, jay <heavenf...@gmail.com> wrote: > > > > Hello, > > > > I have an ASIC design using internal tri-state multi-sources buses > > > like below: > > > assign tbus =3D a_en ? a : Hiz; > > > assign tbus =3D b_en ? b : Hiz; > > > > When implementing to FPGA, I found I can't strobe the right data from > > > the bus. After analyze the code, I think it's because the strobe > > > signal comes later than the enable signals for each source. For a rea= l > > > tri-state bus, the value can still float on the bus so the ASIC can > > > work. > > > > For the FPGA, I think I need convert the bus using latch to contain > > > the value when the enable signal has gone, so I designed the code lik= e > > > below: > > > always @(*) > > > begin > > > =A0 if (a_en) > > > =A0 =A0 tbus <=3D a; > > > =A0 else if (b_en) > > > =A0 =A0 tbus <=3D b; > > > end > > > > However the circuit doesn't work as I expected, I examined the > > > synthesis result, looks like my code is translated to a mux and a > > > latch like below: > > > assign temp =3D a_en ? a : b; > > > always @(*) > > > =A0 if (a_en | b_en) > > > =A0 =A0 tbus <=3D temp; > > > > It seems Verilog doesn't accept an incomplete Mux, so b is set as > > > default. > > > > Can anyone gives me some advise? > > > > Thanks > > > What is your setup/hold of the data and the enables? =A0You may need to > > code this as > > latches followed by a mux and not a mux followed by a latch. > > > always @(*) > > =A0 if (a_en | (a & a_hold) > > =A0 =A0 =A0a_hold =3D a; > > > always @(*) > > =A0 if (b_en | (b & b_hold) > > =A0 =A0 b_hold =3D b; > > > assign t_bus =3D a_en ? a_hold : b_hold; > > > Make sure that the synthesizer infers the latches properly, you may > > need to use the simpler: > > =A0 always @(&) > > =A0 =A0 =A0if (b_en) > > =A0 =A0 =A0 =A0 =A0b_hold =3D b; > > > Adding the extra term in the "if" solves a race condition when the > > latch enable is removed and you're > > making the latch out of discrete gates. =A0This is probably not needed > > since the latch inferred by synthesis > > should alreay take care of this. > > > I hope this helps! > > > John Providenza > > I haven't seen "always @(&)" before, a new syntax? No, a typo. It should have been always @(*) John PArticle: 144152
When I had to implement tri-state buffers onto FPGAs I've always used FPGA-specific gates, e.g., "tri" buffers on Altera. I could suggest you to look at the logic family you are using, probably they have a solution for your issue. Regards, mArticle: 144153
Am 13.11.2009 15:19, schrieb jay: > always @(*) > begin > if (a_en) > tbus <= a; > else if (b_en) > tbus <= b; > end This is a muxed latch. The latch-enable and the mux-selector are driven by the same signal. > assign temp = a_en ? a : b; > always @(*) > if (a_en | b_en) > tbus <= temp; You exactly have pointed out the problem with this alternative description. Nevertheless it does not solve the problem. To be more precise: Let's say a_en==1'b1 then signal a is selected and the latch is open. Now with the falling edge of a_en the mux may change it's output value AND the latch becomes inactive. No one can say witch one is faster. A hold time violation is the result in simulation and unpredictable results are the result in hardware. Don't use muxed latches! Don't do it in ASICS or in FPGAs. Find a new signal that drives the mux-selector! RalfArticle: 144154
[Please note, followups set to news.groups] The newsgroup comp.arch.hobbyist was created some years ago for the discussion of recreational hardware design. The activity when it was created was (for example) people wirewrapping their own microprocessor boards at home, but the scope in the charter (below) is a bit broader than that. It was created as a moderated group because the community previously inhabited alt.comp.hardware.homebuilt which was filled with off-topic posts like 'How do I plug in SIMMs to my PC?'. That was probably a mistake, as I'm not sure moderation was needed in comp.arch.* Anyway, for some years the moderator has been AWOL and as a result the group was been dead. So the Big 8 Management Board are currently seeing if there's any interest in replacing the moderator, or whether the group should be deleted. Is there any interest in a newsgroup for non-commercial electronics/hardware design? That might have a slightly different feel from, say, comp.arch.embedded where the emphasis is on commercial development. Hardware, software, FPGAs (and more) would be covered. It might not be a particularly high-traffic group, as long as there are some people interested in reading and posting. If there's interest, the group is already carried by many news servers so moderation just needs to be arranged - either on a simple automatic approval system or, if manpower is available, with human moderators. I'm willing to set this up if people think it's worthwhile. But I'm also happy for the group to be deleted if no-one is interested. So please followup to this posting (followup will go to news.groups not comp.arch.* or sci.electronics.*) if you have an opinion. Theo (original proponent of comp.arch.hobbyist 1997-8) Here's the official Moderator Vacancy Investigation posting (from news.groups.proposals): In news.announce.newgroups Alexander Bartolich <alexander.bartolich@gmx.at> wrote: > MODERATOR VACANCY INVESTIGATION (MVI) > moderated group comp.arch.hobbyist > > This is a formal Moderator Vacancy Investigation (MVI), begun because > moderated newsgroup comp.arch.hobbyist is not functioning, and may have > been abandoned by its moderator(s). > > This investigation will attempt to verify the reasons for non-function, > and may result in the removal of the group or the selection and instal- > lation of a new moderator. In practice, the Big-8 Management Board > considers the third alternative--changing the status of the group from > moderated to unmoderated--as likely to cause more harm than good. > > NEWSGROUPS LINE: > > comp.arch.hobbyist Homebrew digital electronics design. (Moderated) > > DISTRIBUTION: > > news.announce.newgroups > news.groups.proposals > comp.arch.hobbyist > > PROPONENT: > > Alexander Bartolich <alexander.bartolich@gmx.at> > > CHARTER OF COMP.ARCH.HOBBYIST > > A moderated forum to exchange ideas, techniques, problems, solutions, > and other information concerning the hobby of electronics design and > construction, specifically related to digital machines and their > peripherals. > > Commercial advertisements (except when non-repetitive and directly > relevant to the topic of the group) are expressly forbidden; it is up > to the moderation group to make individual exceptions. > > Binary postings in this group are unwelcome. No postings containing > 10K or more of binary content will be accepted. Postings containing > less than 10K of binary content should only be used where no other > reasonable method is available to convey the information they contain. > All postings containing binary content of more than 10 lines or 300 > bytes, whichever is the smaller, shall be forwarded to the daily > moderators for inspection in the same manner as articles from unknown > authors. > > Posters wishing to post binaries that do not fit the above criteria > should upload this data to an FTP or WWW site and instead post a > pointer to that site. The binary regulations do not apply to the > posting of ASCII schematics. > > A 'bot moderator will be used, which will reject articles by authors > who have not read the posting guidelines. Articles rejected by the > 'bot will be forwarded to a group of three daily moderators for > review. These daily moderators will be appointed by a moderation group > of at least eight and at most twelve members who will decide on > moderation policy in general and the workings of the 'bot in > particular. Moderation will follow the scheme outlined below: > > The 'bot: > > - auto-approves articles that match all of these: > - known author > OR keyword/phrase in article > OR reply to approved article to the same set of newsgroups > - article with less than 300 bytes or 10 lines of binary > content, whichever is the smaller > - plain text, without markup encoding > - mails notification of non-approval to original authors, > without an attempt to circumvent spamblocks > - notification message explains moderation system, > and points poster to relevant posting guidelines > - sends non-approved articles to the daily moderators > - uploads non-approved articles to a WWW site, and > regularly posts a pointer to them > - scans for forged approvals and cancels > > > The daily moderators: > - individually check articles the 'bot rejected; > - if at least one of the daily moderators think the > article is on-topic, it gets posted > - if it is reposted, the original author is notified > > The moderation group: > - appoints the daily moderators > - deals with group abuse that's not caught by the 'bot > - it has the power to bar persistent abusers by > unanimous decision for a period of up to > 30 days at a time > - deals with long-term moderation policy > - is obliged to post details of all moderation group > decisions to the newsgroup > - if a moderation group member does not express an opinion > on a matter, then their silence shall not be taken as > supporting either side of a decision > > Moderators of news.announce.newgroups and successor groups are > allowed blanket crossposting at their discretion. > > RATIONALE: > > Probe posts to this group resulted in bounces. > > <comp-arch-hobbyist@moderators.isc.org>: host > moderators.switch.ch[130.59.10.10] said: 550 Unrouteable address > (in reply to RCPT TO command) > > HISTORY OF THE GROUP: > > comp.arch.hobbyist is a moderated newsgroup which passed its vote for creation > by 199:15 as reported in news.announce.newgroups on 30 Jun 1998. > > PROCEDURE: > > Those who wish to comment on this moderator vacancy investigation should > subscribe to news.groups.proposals and participate in the relevant > threads in that newsgroup. > > To this end, the followup header of this RFD has been set to > news.groups.proposals. > > For more information on the MVI process, please see > > http://www.big-8.org/dokuwiki/doku.php?id=policies:mvi > > CHANGE HISTORY: > > 2009-10-29 Probe post bounced > 2009-11-01 Moderator Vacancy Investigation >Article: 144155
austin wrote:
> Those ceramic packages had been contaminated in a bath of nitric acid
> that had been used to dissolve some lead, so it bathed them in the
> actinides, and plutonium decay isotopes...famous story.
And there were white ceramic packages that let in light.
I once heard a story of product that worked on the
bench, but not in the box.
For rev 1.0 the workaround was a light bulb inside the box
near the custom chip in the white ceramic package.
-- Mike Treseler
Article: 144156Hi, I have an old project that was designed in EDK 7.1. Is there anywhere I can download old versions of EDK; the new one , EDK 11, failed to open the project stating incompatible cores.Article: 144157
In article <cc88c220-c479-403e-a0ff-7a21d5317d4c@y10g2000prg.googlegroups.com>, austin <austin@xilinx.com> wrote: >So, today, we buy laser separated lead for bumping (ultra low alpha >lead), and epoxies, mold compounds, etc all of the highest purity. Cool, I hadn't realised that was a commercial product. http://www.osti.gov/bridge/servlets/purl/231307-yFE5Be/webviewable/231307.pdf is a reprint of a (rather content-free) thirteen-year-old LLNL paper about setting up to make the stuff. >The recent paper by google is pretty scary, and typical of this market >(PC's). > >http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf That very explicitly says that hard errors are more common than soft errors; I've certainly had, of the couple of dozen RAM modules that I've bought, one on which a sense amp died and every 4096th bit started reading back as zero. Wish I'd figured out that this was what was happening before defragmenting a disc on that system! The big recent packaging embarrassment is nVidia's inadequate bumping in very hot graphics processors, which seems to have cost them a few hundred million dollars and a lot of goodwill with Apple. TomArticle: 144158
Mike Treseler <mtreseler@gmail.com> wrote: (snip) > And there were white ceramic packages that let in light. > I once heard a story of product that worked on the > bench, but not in the box. > For rev 1.0 the workaround was a light bulb inside the box > near the custom chip in the white ceramic package. One I heard some years ago (2708 days) was an EPROM that worked in the light, not in the dark. It was part of a movie camera controller that had to work in the dark. Debugging in the dark can be hard, though. -- glenArticle: 144159
Hi We have a problem with Altera Stratix IV GX FPGA Development Kit. Specifically, we build a PCI Express design based on Altera's own "hard" PCI-E core configured for Gen.1 x4 operation. The design works (more or less, but that's behind the scope of this message) when it is plugged into x8 mechanical/x4 electrical slot. However when plugged in x8 or x16 mechanical slots which are electrically x8 the design not only doesn't work but not even recognized by the host as valid PCI-E device. Exactly the same happens when we are trying to build x1 device. We validated (by plugging off-the-shelf x1 and x4 PCI-E cards) that it's not a host issue. My only PCI-E book (Mindshare "PCI Express System Architecture") tells virtually nothing about width negotiation so right now I am totally lost. Any ideas to help?Article: 144160
Hi. Is there any harm in connecting 3V3 LVDS transmitter to 2V5 Receiver..? I am using cyclonII fpga for a receiver in which LVDS inputs are connected to 2V5 powered bank. will the FPGA be damaged with such interconnection..? I am using these lines for clock (26MHz) interconnecting two boards separated by a distance of 6 inches thru mother board. Thank you in advance saiArticle: 144161
On 15 Nov., 14:37, "saijayram" <saijay...@gmail.com> wrote: > Hi. > Is there any harm in connecting 3V3 LVDS transmitter to 2V5 Receiver..? > I am using cyclonII fpga for a receiver in which LVDS inputs are connected > to 2V5 powered bank. > > will the FPGA be damaged with such interconnection..? > I am using these lines for clock (26MHz) interconnecting two boards > separated by a distance of 6 inches thru mother board. > > Thank you in advance > > sai shouldn't be a problem, lvds is lvds regardless of what supply voltage the reciever/transmitter is using -LasseArticle: 144162
On Nov 14, 1:38=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Mike Treseler <mtrese...@gmail.com> wrote: > > (snip) > > > And there were white ceramic packages that let in light. > > I once heard a story of product that worked on the > > bench, but not in the box. > > For rev 1.0 the workaround was a light bulb inside the box > > near the custom chip in the white ceramic package. > > One I heard some years ago (2708 days) was an EPROM that worked > in the light, not in the dark. =A0It was part of a movie camera > controller that had to work in the dark. =A0Debugging in the dark > can be hard, though. > > -- glen Getting a bit further off-topic, at my first job we made a LORAN receiver with planar-gas-discharge display (those bright orange seven- or fourteen-segment displays you probably saw on pinball machines). The first winter after product release we started getting calls from the field that the display would not come on on dark, cold nights. We finally reproduced the problem in the screen-room with all lights off. The instant the fluorescent lamps were turned on, the displays started up. Apparently the 900V or so was not enough to get the lamp started without some help from external radiation. The solution came from the PGD manufacturer: add a bit of radioactive Kr-85 to the gas in the tubes. Regards, GaborArticle: 144163
On Nov 15, 1:16=A0pm, Gabor <ga...@alacron.com> wrote: > On Nov 14, 1:38=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > > > Mike Treseler <mtrese...@gmail.com> wrote: > > > (snip) > > > > And there were white ceramic packages that let in light. > > > I once heard a story of product that worked on the > > > bench, but not in the box. > > > For rev 1.0 the workaround was a light bulb inside the box > > > near the custom chip in the white ceramic package. > > > One I heard some years ago (2708 days) was an EPROM that worked > > in the light, not in the dark. =A0It was part of a movie camera > > controller that had to work in the dark. =A0Debugging in the dark > > can be hard, though. > > > -- glen > > Getting a bit further off-topic, at my first job we made a LORAN > receiver with planar-gas-discharge display (those bright orange > seven- or fourteen-segment displays you probably saw on > pinball machines). =A0The first winter after product release we > started getting calls from the field that the display would not > come on on dark, cold nights. =A0We finally reproduced the > problem in the screen-room with all lights off. =A0The instant the > fluorescent lamps were turned on, the displays started up. > > Apparently the 900V or so was not enough to get the lamp > started without some help from external radiation. =A0The > solution came from the PGD manufacturer: =A0add a bit of > radioactive Kr-85 to the gas in the tubes. > > Regards, > Gabor Oops... that should have been 90V, not 900V...Article: 144164
who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA?Article: 144165
On Nov 16, 2:06=A0pm, water <water9...@yahoo.com> wrote: > who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA? oh no again the same topic! AnttiArticle: 144166
Sai, LVDS is a standard. The Vcco is immaterial (does not matter). Yes, they are designed to interconnect (3.3 to 2.5, 2.5 to 3.3). AustinArticle: 144167
On Nov 14, 10:16=A0am, Alexey <trenk...@gmail.com> wrote: > Hi, > > I have an old project that was designed in EDK 7.1. Is there anywhere > I can download old versions of EDK; the new one , EDK 11, failed to > open the project stating incompatible cores. ISE, yes. EDK, unknown. I found this post from about a year and a half ago: <http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/ e6e08f8679c3a5ce> ALArticle: 144168
On Nov 11, 11:38=A0am, Paragon <paragon.j...@gmail.com> wrote: > Hello all, > > I have having trouble figuring out how to properly define some timing > constraints for an interface between two Xilinx Virtex-4 LX100's. =A0If > anybody has any insight on the best way to solve this problem, it > would be appreciated. > > Here are the fixed system parameters (these cannot be changed no > matter how much easier it would make the design). > > 1) Each FPGA is provided with an identical 384 MHz clock. > 2) Inside of each FPGA, a PMCD divides the 384 MHz clock down to 96 > MHz. > 3) There are some control signals which need to be sent back and forth > between the FPGAs which are generated in the 96 MHz clock domain. > 4) Between the FPGAs there are pins which are connected directly, > including 2 pins in each direction which are capable of driving > differential clocks if needed. =A0All of these signals are in 2.5 V > banks. > 5) There is a worst case of 0.95 ns propagation time on the lines > between the two FPGAs. > > The problem is that due to the 96 MHz clock being derived in each > FPGA, there is not a defined phase relationship between the two 96 MHz > clocks (there could be any one of 4 relative phases), so data can not > just be sent back and forth as if it were synchronous. > > I have tried constraining with OFFSET IN and OFFSET OUT constraints > that can handle these 4 relative phases (basically constrain as if it > were a 384 MHz clock) but this appears to be too much for the FPGA to > handle. > > Here are the constraints I defined in this case: > > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; > TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; > > NET "outputData<*>" OFFSET =3D 0.6 ns AFTER "clk_384mhz_p"; > NET "inputData<*>" OFFSET =3D IN 1 ns VALID 1.6 ns BEFORE > "clk_384mhz_p"; > > Another idea I have tried is to use source synchronous design to > forward the 96 MHz clock (as a differential clock) with the data and > then use a FIFO to move it into the "receiving" 96 MHz clock domain > after clocking it in with the "originating" =A096 MHz. =A0Once again > though, the design has trouble meeting timing. > > Here are the constraints I defined in this case: > > NET "clk_384mhz_p" TNM_NET "clk_384mhz_p"; > TIMESPEC "TS_clk384mhz_p" =3D PERIOD "TS_clk384mhz_p" 10.4 ns HIGH 50%; > > NET "originatingClk_p" TNM_NET =3D"originatingClk_p"; > TIMESPEC "TS_originatingClk_p" =3D PERIOD "originatingClk_p" 10.4 ns > HIGH 50%; > > NET "outputData<*>" OFFSET =3D 5 ns AFTER "clk_384mhz_p"; > NET "inputData<*>" OFFSET =3D IN 4 ns VALID 4 ns BEFORE > "originatingClk_p"; > > Does anybody have any insight into the best way to solve this problem? > > Thanks! I would use the 384 MHz clock to move the data across the interface with a clock enable. This gives you the full 10.4 ns cycle of the 96 MHz clock to move the data across and only the enable signal needs to operate at the full 384 MHz rate. Inside the receiving chip the data then needs to be synchronized to the internal 96 MHz clock. Internally the sync circuit will need to operate at the full 384 MHz rate, but that shouldn't be a problem. The clock enable might want to be a differential signal. RickArticle: 144169
On Nov 11, 11:38=A0am, Paragon <paragon.j...@gmail.com> wrote: > Hello all, > > I have having trouble figuring out how to properly define some timing > constraints for an interface between two Xilinx Virtex-4 LX100's. =A0If > anybody has any insight on the best way to solve this problem, it > would be appreciated. > > > Does anybody have any insight into the best way to solve this problem? > Send identical 96 MHz clocks to each FPGA and multiply up internally to get the 384 MHz. KJArticle: 144170
On 11=D4=C216=C8=D5, =CF=C2=CE=E78=CA=B142=B7=D6, Antti <antti.luk...@googl= email.com> wrote: > On Nov 16, 2:06 pm, water <water9...@yahoo.com> wrote: > > > who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA? > > oh no again the same topic! > > Antti Can you help me write a wrapper? I can pay $$$.Article: 144171
On Mon, 16 Nov 2009 19:22:53 -0800 (PST), water <water9580@yahoo.com> wrote: >On 11??16??, ????8??42??, Antti <antti.luk...@googlemail.com> wrote: >> On Nov 16, 2:06 pm, water <water9...@yahoo.com> wrote: >> >> > who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA? >> >> oh no again the same topic! >> >> Antti > >Can you help me write a wrapper? > >I can pay $$$. What if someone develops the wrapper and licenses to you? -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144172
On 11=D4=C217=C8=D5, =CF=C2=CE=E71=CA=B100=B7=D6, Muzaffer Kal <k...@dspia.= com> wrote: > On Mon, 16 Nov 2009 19:22:53 -0800 (PST), water <water9...@yahoo.com> > wrote: > > >On 11??16??, ????8??42??, Antti <antti.luk...@googlemail.com> wrote: > >> On Nov 16, 2:06 pm, water <water9...@yahoo.com> wrote: > > >> > who have a usb3.0 pipe3 wrapper for xilinx V5/V6 FPGA? > > >> oh no again the same topic! > > >> Antti > > >Can you help me write a wrapper? > > >I can pay $$$. > > What if someone develops the wrapper and licenses to you? > -- > Muzaffer Kal > > DSPIA INC. > ASIC/FPGA Design Services > > http://www.dspia.com I can pay $$$.Article: 144173
5 minutes video http://www.youtube.com/watch?v=hnmSJJOD86A from vhdl to the programming files, and programming without actel programmer using DirecC and usb-jtag cable Antti PS i messed up alter-actel in the video a few times :(Article: 144174
Hello, I have an EDK 11.1 project with a single custom peripheral containing exterior ports. After assigning said ports in the .ucf file to buttons on my FPGA board (for debugging purposes), I can generate the netlist but I receive the following error when I try to generate the bitstream: "Error:Place:645 - A clock IOB clock component is not placed at an optimal clock IOB site. The clock IOB component <my_pin<0>> is placed at site <E7>. The clock IO site can use the fast path between the IO and the Clock buffer/GCLK if the IOB is placed in the master Clock IOB Site. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING and allow your design to continue. However, the use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design. A list of all the COMP.PINs used in the clock placement rule is listed below. These examples can be used directly in the .ucf file to override this clock rule. < NET "my_pin<0>" CLOCK_DEDICATED_ROUTE = FALSE; >." I get a similar message for my_pins<1>...<5> (I have 5 of such pins). The issue here is that the said ports are not clocks, and has nothing to do with a clock anywhere. Has anyone seen this before? Thanks.
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