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 Fri, 28 Apr 2006 13:01:57 +0100, "Ben Jones" <ben.jones@xilinx.com> wrote: >Hi Brian, > >"Brian Drummond" <brian_drummond@btconnect.com> wrote in message >news:reu352d73g90urns1j9k3j88ie8ahk0qcm@4ax.com... >> IMO this limitation COULD have been more clearly documented, as well as >> trapped by the tools... > >Good point. As far as documentation goes it took me a while to find where >this is explained (PowerPC Processor Reference Guide, Chapter 7 "Exceptions >and Interrupts", section "Interrupt-Handling Registers", EVPR, page ~204, >and also mentioned in the OS and Libraries Documentation, Standalone PowerPC >BSP section). :-) Do you have a suggestion as to where else you think this >should be mentioned, to make it more obvious? I confess I haven't been through every page of documentation ... I'd have to think to recreate the places I looked unsuccessfully. XAPP778 page 14 was where I found it. It took a while searching the support site on things like "PPC interrupts". >The EDK tools do the Right Thing when generating the default linker script - >and Base System Builder will notify you if you don't have room for the >vector table in your project due to this limitation (e.g. you have < 64KB of >BRAM). Good to hear ... 7.1 didn't (at least, not in my hands). I had a 32K plb_bram at ffff8000, and a 16k one at ffff4000. I inherited the project (so no BSB phase), and in ignorance, moved the lower from ffff0000 to make them contiguous, and wrongly assigned segments in "Generate Linker Script". This dialog could warn; but that wouldn't cover hand edited scripts. > I guess the linker could be modified to check what it's being asked >to do with the "vectors" section and barf (or at least issue a warning) if >the alignment is wrong, but this would be a bit of an ugly "special case"... IMO it *is* an ugly special case already. I don't believe telling the user about it is uglier than linking non-functional code. - BrianArticle: 101351
jaxato@gmail.com wrote: > I was wondering what's the tariff classification of an FPGA development > board. > Searching through some documentations, I ended up thinking that it may > be this: > > 8542.70.00 or Electronic microassembly. > > Any person around here knows what it might be. This call specially goes > to ppl who are exporting to the EU. I let my stuff be shipped under 8537. None ever cared. I guess they have certain triggers on agriculture, fishery, iron, you name them. Where subsidies protect closed markets. The rest is not worth checking except for value, the VAT value. I once wanted to get an export paper for stuff I transported by car and thus sent a piece of alu sheet metal with a tag and a part number as dummy. Together with valid invoice and customs papers. They, the customs, called me and complained that the stated 600$ for this alu were not real. And I replied that they don't have to care as long as the customer pays for it. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 101352
John, I have no issues with Rick - I understand his frustration, and I share it. Please do not think poorly of him. Xilinx did not do him a service, and he feels compelled to share his experience here. OK. At least Steve got it, and fixed it (which is what counts). For every verbal complaint, there are at least ten others too busy to complain (a basic rule of customer support). I am actively working every day to improve Xilinx communications to our customers because it is just darned good business to do so: faster it works, faster we get orders. Just that simple. But, let us go back to history... Napoleon was a great leader, and a visionary. Parks, forests, roads, and many other things people take for granted in Europe were done by his command. The fact that he lost his last battle has left him judged rather poorly by the English dominated history books. If he would have won, the books would vilify the losers! History is written by the winners. A good historian recognizes this, and attempts to place themselves in the loser's shoes, and read all original accounts, and tries to feret out what facts they can. To accuse me of being as arrogant as Napoleon was obviously designed to tweak my nose - I know that. But in the Zen tradition, I thank Rick for his gift of Napoleon, and appreciate it all the more for its wisdom. Merci beaucoup M. Rickman, je vous remercie pour votre compliment. Reflecting on world history, AustinArticle: 101353
Hi Hans, Thank you. I will try vcd2wlf first because I have access to ModelSim. WengArticle: 101354
Austin Lesea wrote: > John, > > I have no issues with Rick - I understand his frustration, and I share > it. Please do not think poorly of him. Xilinx did not do him a > service, and he feels compelled to share his experience here. OK. At > least Steve got it, and fixed it (which is what counts). For every > verbal complaint, there are at least ten others too busy to complain (a > basic rule of customer support). > > I am actively working every day to improve Xilinx communications to our > customers because it is just darned good business to do so: faster it > works, faster we get orders. Just that simple. > > But, let us go back to history... > > Napoleon was a great leader, and a visionary. Parks, forests, roads, > and many other things people take for granted in Europe were done by his > command. The fact that he lost his last battle has left him judged > rather poorly by the English dominated history books. If he would have > won, the books would vilify the losers! > > History is written by the winners. A good historian recognizes this, > and attempts to place themselves in the loser's shoes, and read all > original accounts, and tries to feret out what facts they can. > "History will treat me kindly, for I intend to write it" Winston Churchill. But I'm not sure the vilification of the loser was unjust that time.Article: 101355
Hello all, I'm interested in implementing a source control system (Subversion) in the company I work. We do mostly Altera FPGA designs, so our main tool is Quartus. I would like to know if anyone has done that before, and how. The main problem with Quartus is that it has no "source file list", but rather it searches dynamically for files (mostly true for old design entry methods like AHDL and schematic). Does anyone know of a tool (maybe a TCL script) that takes a projects and generate a list of all source files included? I would be happy to hear about any experience of this kind. Thanks, AvishayArticle: 101356
JJ (johnjakson@gmail.com) wrote: : > One of the posibilities that interest me is a V4 module sitting in a 940 : > socket with some MGTs wired up (space is tight - I realise that!) - if : > you happen to be dealing in high speed data aquisition and processing on : > the bit/word and (large) frame level then a tightly coupled : > FPGA/commodity CPU system is really quite exciting. : > : Takes one back to when you could interface 68000s or whatever to your : custom logic or even wire wrap your own mobo, its been along time since : one could "touch" a processor. I hate to say it, but that's before my time other than tinkering with the CPU bus sticking out the back of an old Amstrad CPC... There are various things now bringing high end commodity CPUs (as opposed to specialist DSP hardware) and FPGAs close together - offerings from Cray, SGI, this new opteron socketed thingie etc. Most of the fuss is around their use in reconfigurable computing so the offerings tend to be lacking for raw serial IO... : Whats you acquisition area? Starlight - astronomical adaptive optics. Potentially you can be talking about multiple CCDs of many thosands of pixels framing at over 1KHz... cdsArticle: 101357
"Antti Lukats" <antti@openchip.org> writes: > nops - even vendor generated ASCII SVF/STAPL are not compatible :( Are you saying that they aren't actually compliant with the standard? If so, it seems like submitting bug reports to the vendors to get this fixed would be a good idea.Article: 101358
Hi Rene, Thanks for the tip, 8537.10.10 Jacques Rene Tschaggelar wrote: > jaxato@gmail.com wrote: > > > I was wondering what's the tariff classification of an FPGA development > > board. > > Searching through some documentations, I ended up thinking that it may > > be this: > > > > 8542.70.00 or Electronic microassembly. > > > > Any person around here knows what it might be. This call specially goes > > to ppl who are exporting to the EU. > > I let my stuff be shipped under 8537. None ever > cared. I guess they have certain triggers on > agriculture, fishery, iron, you name them. Where > subsidies protect closed markets. The rest is > not worth checking except for value, the VAT value. > > I once wanted to get an export paper for stuff I > transported by car and thus sent a piece of alu > sheet metal with a tag and a part number as dummy. > Together with valid invoice and customs papers. > They, the customs, called me and complained that > the stated 600$ for this alu were not real. And > I replied that they don't have to care as long > as the customer pays for it. > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > & commercial newsgroups - http://www.talkto.netArticle: 101359
Rene Tschaggelar wrote: > > I let my stuff be shipped under 8537. None ever > cared. I guess they have certain triggers on > agriculture, fishery, iron, you name them. Where > subsidies protect closed markets. The rest is > not worth checking except for value, the VAT value. I just got a shipment from digikey. Some TTL-ICs, PICs, Flash, resistors, capacitors, etc... I only had to pay the VAT on everything except the ceramic oscillators. There was 3.7% tariff on the oscillators. That was a shipment from the USA to the EU a few weks ago. PhilippArticle: 101360
"Eric Smith" <eric@brouhaha.com> schrieb im Newsbeitrag news:qhhd4cky6l.fsf@ruckus.brouhaha.com... > "Antti Lukats" <antti@openchip.org> writes: >> nops - even vendor generated ASCII SVF/STAPL are not compatible :( > > Are you saying that they aren't actually compliant with the standard? > > If so, it seems like submitting bug reports to the vendors to get this > fixed would be a good idea. that would not help. SVF is not complete standard, and some things that are needed to program flash devices, serial proms, plds, just arent so much doable with pure SVF as per SVF specification, this is where the vendors step away to use files that can work on their silicon. as of ram-fpga there are almost no issues using pure generic SVF but with anything that has non-volatile its not so nice anymore. same thing goes for STAPL what is an actual standard - if you use Actel flavor of STAPL that was downloadable at the time PA3 was released, then voila - there was release notes saying the STAPL player supports PA+ devices only. when I tried it with Actel generatedPA3 STAPL files then I got parsing errors! After fixing the STAPL player to not fail on parsing the Actel STAPL (that is JAM) player reported succes in programming and verifying an PA3 device using a STAPL file generated by Actel software. There was one gotcha - the silicon was programmed and player reported verify succes, but the silicon did not work (fpga did not get configured) - using the same STAPL file with actel new programmed yielded the silicon being programmed and configured. similar things can be expected when working with Xilinx config memories or PLD's using SVF files, or when trying to program lattice devices using too old and incompatible version of their VME player (they use SVF -> VME -> VMEplayer) So there is no point of reporting issues - all the vendors are going to reply: use the methods that are intended for the programming eg XSVFplayer in case of Xilinx or ispVME in case of Lattice or correct version of STAPL player in case of Actel or correnct version of JAM player in case of Altera none of the vendors will add an magic option: "generate valid generic SVF for all our silicon devices" to their software - for one simple reason - they can not. So no point of asking the impossible. Please note that with RAM based FPGA there are almost no (or shouldnt be) any issues using plain generic SVF, there are some seldom exceptions - as example there are cases where Xilinx Impact software can not configure S3e over JTAG but software from Xilant Technologies still works - this is because of some errata with mode pins - our software uses a board specific workaround that use NOR Flash CFI interface to place the ext flash in Query ID mode for the time of JTAG configuration that prevents the FPGA to see valid bitstream header (that prevent Impact from from proper configuration) - this is an extreme case, but ther are really cases where generic JTAG tools (like Impact) fail in 'native' eg not SVF mode, so if in such case an SVF is generated then it would also fail. Sure in this example our software could generate plain vanilla SVF that uses the CFI trick, and theoretically could impact do that too - but it doesnt. Asking Xilinx to fix that - they will not do (and for good reason - they fixed the silicon). To my knowledge this issue should not happen any more with actual S3e production silicon, but there is still some ES silicon around that under some circumstances requires that CFI trick (or change of mode pins as xilinx suggest as workaround). Antti PS folks belive me, I know what I am talking, I have been struggling with in-system flash programming for very long time, some links to my early works can still be found with google search: "PIP02 programming software" it supported many different programmer (most of what I have never seen) and in many cases worked with them better than the original software from the programmer vendors. I am using the same low level hardware abstraction layer PINAPI(tm) in our current JTAG software, what again is thanks to that completly separated from the 'cable driver' that is all of our software would work with any jtag cable given there is a very simple low level driver (basically pin bit-bang driver) PPS the JTAG programming should be plain simple and always work, but there are many cases where strange things are observed - like S3 board that will get configured with either Cable IV (original) or Platform cable. However when platform flash config is enabled then the S3 starts up with bad bitstream - done=1 but impact gives verify error, also when platform is erased, but only when using the Cable IV !! when using the USB Cable it all works. The S3 is not bad the thing can be observed any several boards. If impact fails with Cable IV and succeeds with USB cable then SVF player would fail, or at least would not guaranteed to succeed. This issues is not related to bad board or JTAG signal quality. Similary there is 'minimum clock requirement' for some revision of platform flash, as SVF player that is standard compliant doesnt have to maintain any minimum TCK then those config memories would never get programmed using SVF.Article: 101361
"avishay" <avishorp@yahoo.com> writes:
> I'm interested in implementing a source control system (Subversion) in
> the company I work. We do mostly Altera FPGA designs, so our main tool
> is Quartus. I would like to know if anyone has done that before, and
Most of my designes are under CVS. They are are a mix of ASIC, Altera,
and Xilinx designs. Some of the designs have even an implementation
for all the above. However, I rarely use the GUI tools, except for
floorplanners, memory/ip-builder and waveform viewers. To generate a
new implementation I usually do:
cvs checkout designname
cd designname/impl/somefpgadevicename
make
In the Altera case make will run quartus_sh.
> how. The main problem with Quartus is that it has no "source file
> list", but rather it searches dynamically for files (mostly true for
> old design entry methods like AHDL and schematic). Does anyone know of
> a tool (maybe a TCL script) that takes a projects and generate a list
> of all source files included?
I usually explicitly list my source files:
foreach f designfile1.v designfile2.v designfile3.v {
set_global_assignment -name VERILOG_FILE $f
}
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Article: 101362
Jim Granville wrote:
> rickman wrote:
>
> > People here are driving me crazy insisting that the Xilinx factory has
> > told them that you *MUST* tie the mode pins to either Vaux or GND.
> > After finding all the info in the data sheet and talking with support,
> > it looks pretty clear to me that the S3 parts have a very stiff
> > internal pull up and there is no need for an external pull up of any
> > kind, resistor or direct connection to Vaux.
> >
> > Am I misunderstanding? Why did the factory tell us before that the
> > mode pins *MUST* be tied to Vaux? Did we misunderstand what they were
> > saying?
> >
> > I promise this is the last time I will ask about this. I am totally
> > sick of going around this loop with everyone here.
>
> Design the PCB with options for SMD resistors, that can also be
> 0-Ohm shunts, and say 'define in production for valid logic levels'.
> That gets you past the design review, and closes the case :)
I started the design review process with pullups and pull downs of 10
kohms and was told I had to use direct connections. Of course they
could have been replaced with 0 ohm resistors at any time if needed.
Once I had researched the issue, I thought I had an FAE's blessing of
4.7 kohm resistors. I had found that the pull up resistors were rather
strong in the S3 parts, but did not find any indication that there were
internal pullups on those pins. Turns out I had missed the sentance
that told about them. Once I found that, it all started to make sense.
With internal pullups of 1-3 kohms I can see where a pull down
resistor would have to be low enough that there would not be much point
of using a value larger than 0 ohms. Being very cramped for space,
especially in the area of the mode pins, I removed the pullups all
together and am relying on the internal pullups. But some people here
("here" my work, not "here" the newsgroup) just won't let go of the
bone. They are insisting that the pins must be connected to Vaux
directly because of what they were told a year ago.
I don't want to put parts on the board that aren't required. It seems
pretty durn clear to me that pullup resistors are not needed on the
mode pins at any time, under any circumstances. The board is due to
come out of layout in a couple of days and I don't want to interrupt
progress. I don't understand why I can't get a clear answer to this
question. Peter replied, but didn't answer the question. I honestly
do not trust the support phone line (because I don't actually talk to
the person who gives the answer, just the gopher who relays the
message) and can't document what I am told verbally. I can't get an
account to work to get support by email. So I guess I'll have to
resort to working with the FAE who has already given me bad advice.
Article: 101363
Jim Granville wrote:
> rickman wrote:
>
> > People here are driving me crazy insisting that the Xilinx factory has
> > told them that you *MUST* tie the mode pins to either Vaux or GND.
> > After finding all the info in the data sheet and talking with support,
> > it looks pretty clear to me that the S3 parts have a very stiff
> > internal pull up and there is no need for an external pull up of any
> > kind, resistor or direct connection to Vaux.
> >
> > Am I misunderstanding? Why did the factory tell us before that the
> > mode pins *MUST* be tied to Vaux? Did we misunderstand what they were
> > saying?
> >
> > I promise this is the last time I will ask about this. I am totally
> > sick of going around this loop with everyone here.
>
> Design the PCB with options for SMD resistors, that can also be
> 0-Ohm shunts, and say 'define in production for valid logic levels'.
> That gets you past the design review, and closes the case :)
I started the design review process with pullups and pull downs of 10
kohms and was told I had to use direct connections. Of course they
could have been replaced with 0 ohm resistors at any time if needed.
Once I had researched the issue, I thought I had an FAE's blessing of
4.7 kohm resistors. I had found that the pull up resistors were rather
strong in the S3 parts, but did not find any indication that there were
internal pullups on those pins. Turns out I had missed the sentance
that told about them. Once I found that, it all started to make sense.
With internal pullups of 1-3 kohms I can see where a pull down
resistor would have to be low enough that there would not be much point
of using a value larger than 0 ohms. Being very cramped for space,
especially in the area of the mode pins, I removed the pullups all
together and am relying on the internal pullups. But some people here
("here" my work, not "here" the newsgroup) just won't let go of the
bone. They are insisting that the pins must be connected to Vaux
directly because of what they were told a year ago.
I don't want to put parts on the board that aren't required. It seems
pretty durn clear to me that pullup resistors are not needed on the
mode pins at any time, under any circumstances. The board is due to
come out of layout in a couple of days and I don't want to interrupt
progress. I don't understand why I can't get a clear answer to this
question. Peter replied, but didn't answer the question. I honestly
do not trust the support phone line (because I don't actually talk to
the person who gives the answer, just the gopher who relays the
message) and can't document what I am told verbally. I can't get an
account to work to get support by email. So I guess I'll have to
resort to working with the FAE who has already given me bad advice.
Article: 101364Hi Philipp, >From what i've read, a VAT price would already include tariff, but the oscillators might be VAT exempted, but still with tariff. Was it written explicitly on the invoice that tariff was applied? JacquesArticle: 101365
Hi, is it possible to program the XC3190A with the tools in the book: The Practical Xilinx Designer Lab Book: Version 1.5 Are there any restrictions? Thank you!Article: 101366
jaxato@gmail.com wrote: > Hi Philipp, > >>From what i've read, a VAT price would already include tariff, but the > oscillators might be VAT exempted, but still with tariff. Was it > written explicitly on the invoice that tariff was applied? > > Jacques > I got the components first, a few days later I received an invoide from customs. It says they estimated the value (invoice value - estimated fraction of shipment costs) of the oscillators to be 41.45 €. On this value there was a tariff of 3.7%. It says the value for VAT calculation (invoice value + tariff) is 48.38 €. On this value there was a VAT of 16%. So I had to pay both tariff and VAT for the oscillators, but VAT only for the rest. PhilippArticle: 101367
What a timely post. I was just looking into this on Friday (but with CVS). I've been used to Xilinx where I just archived my .npl an .ucf files to capture the project settings for the Synthesis/P&R.. I believe in Quartus you need to archive the .qpf and .qsf files (as well as your HDL code, of course). Does anyone know of other Quartus specific files that need archived to be able to restore the Synthesis/P&R project? John ProvidenzaArticle: 101368
For crying out loud, do not make a federal case out of this! If the documentation asks for a short circuit, then do it! If your gut feel says there is no need for any external pull-up at all, then measure the internal pull-up impedance the way I suggested, and if it is below 3 kilohm, then connect nothing. If the FAE suggests an external resistor, so use one. This may be a question of belts or suspenders or both or neither... But remember: If you want to establish a logical Low level, you must definitely be cautious and measure whether you are fighting an internal pull-up. I much rather spend 10 minutes with a multi-meter than indulge in contankerous debates in the newsgroup. We are all engineers and not scribes, aren't we? Peter Alfke, obviously somewhat irritated... Like Austin, I am human, too. Even though we always wear the Xilinx badge, we are still allowed to voice an opinion...Article: 101369
Regarding Napoelon: France loves him, although he caused misery and the death of hundreds of thousands of her sons. The Germans hate him for beating their armies, although he also terminated the Middle Ages and laid the beginning of the foundation of the modern German state and its secular laws. For better or worse, Napoleon left an enormous, and largely positive heritage. (I grew up in a house that Napoleon rode by on his way to Moscow... History is everywhere in Europe.) Peter AlfkeArticle: 101370
The list of all source files compiled can be found in the Report file under Analysis and Synthesis->Source Files Read. You can right click in this window and save the panel out to a text file. Take every file which says User Entered, every file which is not under the Quartus installation directory and add it to your source code control system. Then follow Petter's instructions. The process of discovery only works in the cases where there is 1-1 relationship between filename and entity name. This is true for BDF's (schematics) and TDF's(AHDL), but does not hold true for HDL's like VHDL and Verilog. You are required to add the list of HDL files in your project. I recommend that you archive your design, and restore it in a separate directory. This should contain the list of files that Quartus needs to recreate your project. Never archive the db directory. To learn how to generate a Quartus Project from scratch each time if you only have the HDL files take a look at the Tcl file generated by the Project->Generate Tcl file for Project command. Hope this helps, Subroto Datta Altera Corp. "avishay" <avishorp@yahoo.com> wrote in message news:1146329623.963661.11530@j73g2000cwa.googlegroups.com... > Hello all, > I'm interested in implementing a source control system (Subversion) in > the company I work. We do mostly Altera FPGA designs, so our main tool > is Quartus. I would like to know if anyone has done that before, and > how. The main problem with Quartus is that it has no "source file > list", but rather it searches dynamically for files (mostly true for > old design entry methods like AHDL and schematic). Does anyone know of > a tool (maybe a TCL script) that takes a projects and generate a list > of all source files included? > I would be happy to hear about any experience of this kind. > > Thanks, > Avishay >Article: 101371
The XC3190A was introduced 15 years ago, which makes it hopelessly obsolete. Even if you find the hardware sufficient (no on-chip RAM!), the software is so antiquated that nobody should be forced to use it. Get yourself a modern chip of Spartan or Virtex caliber and of 2003+ vintage. The hardware is cheap, and the software is free, and both are very competent. Happy designing with 21st century stuff! Peter Alfke, XilinxArticle: 101372
The documentation DOESN'T say to strap unless you think a schematic in an app note is definitive direction on how to treat those pins. The engineers are bugging rickman because of app notes they saw that showed direct connects. The documentation does not clearly state the condition of the pullups for dedicated inputs like the JTAG lines that I couldn't get to work in a chain for the life of me a few months ago. There have been repeated attempts to clarify the datasheet information on this board without a clear answer - it's clear that he needs to email Steve Knapp directly but that certainly won't help me without follow up here. This is not a federal case and I have been impressed with the civility demonstrated by rickman and Austin. Steve Knapp hasn't appeared to answer the question most explicitly posed by Rickman as a clarifying question. Gut feels do not work when an engineer has to submit to a design review process that doesn't allow "gut feel" for a documented follow up to a design review action item. The FAE suggested a resistor which isn't compatible with the Spartan-3 configuration. Multimeters work for one part, not for a production design. ____________ I may be asked to consider a Spartan3 as opposed to the 2 big Spartan3Es on my one board - if I have to go that route I'll be facing the same documentation and the knowledge that there hasn't been a clear answer here in these threads. All that's desired is a straight answer - is that so much to ask? Peter Alfke wrote: > For crying out loud, do not make a federal case out of this! > > If the documentation asks for a short circuit, then do it! > If your gut feel says there is no need for any external pull-up at all, > then measure the internal pull-up impedance the way I suggested, and if > it is below 3 kilohm, then connect nothing. > If the FAE suggests an external resistor, so use one. > This may be a question of belts or suspenders or both or neither... > > But remember: If you want to establish a logical Low level, you must > definitely be cautious and measure whether you are fighting an internal > pull-up. > > I much rather spend 10 minutes with a multi-meter than indulge in > contankerous debates in the newsgroup. > We are all engineers and not scribes, aren't we? > > Peter Alfke, obviously somewhat irritated... > Like Austin, I am human, too. > Even though we always wear the Xilinx badge, we are still allowed to > voice an opinion...Article: 101373
John, this is analog territory, and there is NOT just ONE right answer. Obviously, a short circuit will always work, if you never need the pin for any other purpose. But we will not force you to do that, since you may have reasons not to like it. It's a free country! There is no mystery here, the purpose is only to establish a High logic level. Nothing more, nothing less. Obviously, a built-in pull-up resistor will establish a High logic level, but it might be sensitive to crosstalk coming from your pc-board.. Obviously, any external resistor reduces the pull-up impedance, and improves the situation. Obviously an external pull-down resistor must be low enough in value to overcome the internal pull-up resistance. And I still favor a multimeter for getting a grip on fundamentals. I am all for clear documentation, but it never hurts to keep the engineering mind alive. Compared to multi-gigabit receiver issues, this mode-pin level debate is really a trivial subject. Peter AlfkeArticle: 101374
Hi, What is the difference between Asynchronous and Synchronous reset. When do you want to use one of them. I am desging a state machine how would i figure out which one i want to use. How would it impact the hardware??? 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