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
Hi, LED's sinking current capacity is in uA. so tie Anode of LED to port pin of CPLD & Cathode of LED to gnd. If u do this kind of connection then CPLD will be in sourcing mode.so to avoid sourcing of CPLD,u can tie Vdc to LED Anode through current limiting resistor,& cathode of LED should be directly connected to CPLD port pin.in this case CPLD will be in sinking mode. I have tried this kind of thing,it woks fine.Article: 101501
John Larkin wrote:
> On 24 Apr 2006 09:27:02 -0700, "rickman" <spamgoeshere4@yahoo.com>
> wrote:
>
>
>> I found this sentance to be especially unenlightening...
>>
>> "The Dedicated configuration pins (CCLK, DONE, PROG_B, M2, M1, M0,
>> HSWAP_EN) and the JTAG pins (TDI, TMS, TCK, and TDO) always have a
>> pull-up resistor to HSWAP_EN during configuration, regardless of the
>> value on the HSWAP_EN pin."
>
>
> It's stunning how bad IC documentation is, and not just Xilinx. The
> use of the passive voice ("the enable input, when asserted..." Who
> the hell pulls it high, or maybe low, me or the chip?) and the
> persistant refusal to distinguish between levels and edges are two
> especially annoying lapses. The guys who do mixed-level stuff, like
> serial ADCs, are extra bad.
>
> Who *writes* this stuff?
>
> John
>
At least it was written in the one language, rather than being
translated. The worst documentation I came across was for an ASIC made
in Germany. The original German datasheet was very poor, and had been
translated into English by someone who seemed to have little knowledge
of either German or English, and no knowledge at all of the electronics
involved. One entire chapter (the one containing all the register
settings - kind of important) was translated to the single sentence
"original German unclear".
Article: 101502Subroto Datta <sdatta@altera.com> wrote: >Quartus files can be stored in any source code control system. All source >files needed to create and compile a project are text files. We have >customers and internal users who have versioned Quartus projects with CVS, >Clearcase, Perforce, RCS.... The only binary file is the .qws (workspace >file) files that contains the locations of the window settings when the >Quartus UI executable (quartus.exe) is closed..The .qws file is not needed >for compilation. One can use uuencode the .qws file to get it into a source code control system. Btw, why is there no webpack linux offering like xilinx have?Article: 101503
Ashu, you have to ask the wizard of OZ Aurash ashutoshkaushik@gmail.com wrote: > hi all! > > what hapens when i send a code written in vhdl through jtag to the > fpga? > if anyone can tell me in detail the process..or suggest some good links > for the same. > regards > > ashu >Article: 101504
Hi Roger, I think output databus resolution is dependent mainly on the other components you have on the board...eg it may be a serial ADC or 12 bit wide. Roger Bourne wrote: > Hello all, > > Does anyone know of a link/web page/article/ that gives the equations > to calculating the output databus bit resolution of a digital filter. > > I imagine the following factors should be somewhere in the equations: > 1. input databus resolution of the digital filter > 2. scaling factor of the coeffciients to their binary equivalents > 3. DCgain of the FF coeffcicients (if it is an IIR) > 4. order of filter, type of filter, number of taps/coeffcients .... > 5. Maximum amplification that the filter will allow, for any given > frequency > > Please advise > -RogerArticle: 101505
"Antti Lukats" <antti@openchip.org> escribió en el mensaje news:e31q3u$s6d$1@online.de... > Hi all > > I am looking for ideas for: "FPGA Single LED Demos", The requirements for > the demo Application are following: > Pseudo random LED blinking using LFSRs at a very low frequency Josep DuránArticle: 101506
pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote: > Subroto Datta <sdatta@altera.com> wrote: >> Quartus files can be stored in any source code control system. All source >> files needed to create and compile a project are text files. We have >> customers and internal users who have versioned Quartus projects with CVS, >> Clearcase, Perforce, RCS.... The only binary file is the .qws (workspace >> file) files that contains the locations of the window settings when the >> Quartus UI executable (quartus.exe) is closed..The .qws file is not needed >> for compilation. > > One can use uuencode the .qws file to get it into a source code control system. > Can't you just store the binary in the source code control? Obviously you can't compare versions in the same way as for text files, but you couldn't do that with uuencoded files anyway. Certainly subversion should have no problem storing binary qws files - I don't know about any other systems. > Btw, why is there no webpack linux offering like xilinx have? >Article: 101507
Antti Lukats wrote: > Hi all > > I am looking for ideas for: "FPGA Single LED Demos", The requirements for > the demo Application are following: > > * Display visible 'sign of live' or 'self-test passed' message > * Impemented in FPGA Vendor neutral HDL > * <= 3000 LUT > * <= 4KB of Block RAM > * uncalibrated (+-50%) high frequency oscillator > * 1 user LED for display > > The Demo application should have some sort of LED visible 'message' to > indicate the demo is working or has passed internal self test code. There is > no user interface byeound one single LED. > > Current list of Applications > ================== > 1) LED Blink (MSB of counter) - VHDL > 2) LED Blink (MSB of counter) - Verilog > 3) LED Blink (MSB of counter) - MyHDL (Python) > 4) LED Fade with PWM (waveform from counter bits) > 5) LED Fade with Delta-Sigma DAC (waveform from counter bits) > 6) LED Fade with DDS and Delta-Sigma (waveform from ROM Table) > 7) PacoBlaze LED Blink with Assembler Program > 8) PacoBlaze LED Blink with C Program > 9) SPoC(bit-serial-processor) LED Blink with Assembler Program > 8) AVR like MCU LED Blink with Basic Program > 10) PIC like MCU LED Blink with Assembler Program > 11) C16 (16 Bit CPU) LED Blink with C Program > 12) LED Blink with 32-bit Programmable Micro-Sequencer > 13) Frequency Measurement demo (use stop watch and calculator) > 14) ? your idea ? > > The above is my current list of demo applications, I am considering some > more soft-core CPU's, but all those demos would be very similar to the > existing soft-core demos. So any ideas to demo some other functionality are > welcome. > > Best ideas can be rewarded with an FPGA evaluation board (with your idea > pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not count. > > Antti Just blink the led quickly 5(say) times with a small pause between the next 5. To indicate that section 3 has failed extend the length of blink 3 by 3 or 4 times. colinArticle: 101508
Hi all, I have the following problem: I have a Virtex-4 Board (ML403). The Virtex-4 is ES. To use the DCM I have to add the following line to the UCF file : CONFIG STEPPING = "ES"; The problem is that if I do this the simulation doesn't work (the DCM never locks). CheersArticle: 101509
For clarification purposes, I did not say that the .qws file should not be versioned, or cannot be stored in a source code control system. It was important to point out that you will need to take some steps to preserve its integrity if you store it in a version control system. - Subroto Datta Altera Corp. "David Brown" <david@westcontrol.removethisbit.com> wrote in message news:44574c78$1@news.wineasy.se... > pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote: >> Subroto Datta <sdatta@altera.com> wrote: >>> Quartus files can be stored in any source code control system. All >>> source files needed to create and compile a project are text files. We >>> have customers and internal users who have versioned Quartus projects >>> with CVS, Clearcase, Perforce, RCS.... The only binary file is the .qws >>> (workspace file) files that contains the locations of the window >>> settings when the Quartus UI executable (quartus.exe) is closed..The >>> .qws file is not needed for compilation. >> >> One can use uuencode the .qws file to get it into a source code control >> system. >> > > Can't you just store the binary in the source code control? Obviously you > can't compare versions in the same way as for text files, but you couldn't > do that with uuencoded files anyway. Certainly subversion should have no > problem storing binary qws files - I don't know about any other systems. > >> Btw, why is there no webpack linux offering like xilinx have? >>Article: 101510
I, for one, am very pleased to see the changes. The push to take care of the nitty gritty details that really do matter is sincerely appreciated. I saw great stuff with the Spartan3E design notes in the data sheet and now the clarification of trivial (i.e. rudamentary) information here in the Spartan3. Thanks from me to the Xilinx folks that for pushed the changes. - John Handwork Austin Lesea wrote: > Rick, > > I have just checked the Spartan 3 changes, and I am pleased to see what > I think you need. > > http://direct.xilinx.com/bvdocs/publications/ds099.pdf > > page 56, Table 32 has the ranges of pullup currents, and their > equivalent ranges in ohms. > > page 97, Table 68 through page 100 Table 69 has the definitions of the > pins, with a statement of when the pullups are active, and when it matters. > > page 109, Table 74 reinforces the definition of the pins, and the pullups. > > Do you agree? > > My only complaints are that 'pullup' and 'pull-up' are both used, so > searching for "strength" needed 'pull-up' and searching for "definition" > needed 'pullup.' And W is used instead of omega (for ohms) in four > places (describing pullup for DONE, etc.). > > I hope this will allow everyone to go back to work, now that they have > the pull-up (pullup) resistors fully specified for 1.14 to 3.45 volts > (as active devices, their strength varies with supply voltage). > > If anyone at your place of work is still unhappy/uncomfortable with your > design choices, I would be happy to remind them (in writing) that the > data sheet (product specification, combined with the encrypted spice > models, IBIS models, and speeds files) are the controlling documents, > and that what may be suggested by the hotline, or by a FAE (or even by > me!) may not be the most optimal solution (anything that is not in > writing and approved by Xilinx may have been subject to > mis-interpretation, or may be in error), and that good engineering > judgement combined with observance of the data sheet and other > specifications I have listed above is what actually matters (in a > practical and legal sense). > > AustinArticle: 101511
Hi group, Are there any problems with chaining multiple instances of the clock doubler from this link together? http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_six_easy (http://tinyurl.com/aqk9f) (see section 6) Clock rate variations preclude the use of DCMs (even in low frequency mode using CLKFX only). Many thanks for your time.Article: 101512
The two versions of the Jungo windrvr drivers I was trying were: http://www.jungo.com/download/WD801LN.tgz and http://www.jungo.com/download/WD702LN.tgz Has anyone gotten these to compile under 2.6.16 or later? It appears that Jungo is behind on their Linux support - windrvr does not compile nicely for 2.6.16... it compiled fine in 2.6.15. The root of the problem is the dynamic nature of the Linux kernel - things change rapidly within the kernel source from release to release that break drivers that are not an integral part of the kernel. I think that if Jungo got their windrvr source (which they give away anyhow) accepted into the Linux kernel, such maintenance headaches would disappear. I imagine there are other licensing problems with that, however... Thanks, -Chris -- /> Christopher Cole <\ <\ << Cole Design and Development \\ email: cole@coledd.com \\ \\ Computer Networking & Embedded Electronics \\ web: http://coledd.com >> \> \> </Article: 101513
Dave a écrit : > Hi group, > > Are there any problems with chaining multiple instances of the clock > doubler from this link together? [...] > Clock rate variations preclude the use of DCMs (even in low frequency > mode using CLKFX only). Hello Look at the output waveform: this circuit generates a *pulse* on each transition of the input signal. If you chain a second circuit, it will generate pairs of pulses (about 2ns apart, from the circuit description) on each transition of the input signal, and so on. Your average output frequency will actually be 2**n (n being the number of pseudo-doublers in your chain) but your duty cycle will be almost random. Read "unusable" NicolasArticle: 101514
NO !! Do not cascade that frequency double circuit. As a single instant, the circuit is (or can be made to be) safe and reliable, but a cascade would generate garbage. Peter AlfkeArticle: 101515
CMOS outputs are fairly symmetrical, they can source or sink similar amounts of current. But perhaps the sink capability of the n-channel output is slightly higher than the source capability of the p-channel pull-up.. The difference is less than 2 : 1 Peter Alfke, Xilinx, from home.Article: 101516
OK. Many thanks for the quick answers. I knew it couldn't be so easy...Article: 101517
Dave- > Clock rate variations preclude the use of DCMs (even in low frequency > mode using CLKFX only). With freq variations or even complete clock stop, you can still use DCMs, and use an sm based on an independent, reliable clock to measure the actual DCM output (not the LOCKED signal, which I found to be unreliable). If it locks up or starts producing bogus duty cycle, then follow the procedures for Reset. I've had good luck with this approach. -JeffArticle: 101518
Update: Well, I have gotten past the SDRAM execution issue! The board still does not function correctly, but it appears that this is related to our code and just needs more time to debug. I got the development board up and running the same code from the same location and compared this to our board (we have our own PLB memory controller because we have a 16-bit SDRAM interface instead of the 32-bit used by the Xilinx memory controller). I noticed that our Sl_ssize was set incorrectly (not sure why). Changing this to specify a 64-bit bus width results in a code exectuation out of SDRAM. Thanks for everyone's input - if I learn anything else from this issue, I'll post under this topic.Article: 101519
Eli- > So, if I cant use // or /* */, what can I use for commenting? By "line comments" I thought you meant C++ style comments. I've not had trouble with /* ... */ in 7.1, only with //. My apologies for answer that was not helpful. -JeffArticle: 101520
Hi, Is it possible to do SystemC design using the Spartan 3/3E starter kits? I was wondering if the DK design suite and PDK can be used to write microblaze design for these kits? How difficult it is to add PSL support for these kits? Thanks NiravArticle: 101521
Something is wrong. I still get Ver 2.0. I am pretty sure I was able to see ver 2.1 last night from home. But I am getting the old version still here at work. Austin Lesea wrote: > Rick, > > I have just checked the Spartan 3 changes, and I am pleased to see what > I think you need. > > http://direct.xilinx.com/bvdocs/publications/ds099.pdf > > page 56, Table 32 has the ranges of pullup currents, and their > equivalent ranges in ohms. > > page 97, Table 68 through page 100 Table 69 has the definitions of the > pins, with a statement of when the pullups are active, and when it matters. > > page 109, Table 74 reinforces the definition of the pins, and the pullups. > > Do you agree? > > My only complaints are that 'pullup' and 'pull-up' are both used, so > searching for "strength" needed 'pull-up' and searching for "definition" > needed 'pullup.' And W is used instead of omega (for ohms) in four > places (describing pullup for DONE, etc.). > > I hope this will allow everyone to go back to work, now that they have > the pull-up (pullup) resistors fully specified for 1.14 to 3.45 volts > (as active devices, their strength varies with supply voltage). > > If anyone at your place of work is still unhappy/uncomfortable with your > design choices, I would be happy to remind them (in writing) that the > data sheet (product specification, combined with the encrypted spice > models, IBIS models, and speeds files) are the controlling documents, > and that what may be suggested by the hotline, or by a FAE (or even by > me!) may not be the most optimal solution (anything that is not in > writing and approved by Xilinx may have been subject to > mis-interpretation, or may be in error), and that good engineering > judgement combined with observance of the data sheet and other > specifications I have listed above is what actually matters (in a > practical and legal sense). > > AustinArticle: 101522
Hi, I was wondering if it is possible to use the ESL approach for building applications on Spartan 3/3# starter kits? There is a special kit by XIlinx that can be used for ESL and DK /PDK suite from Celoxica. Is it possible to add PSL/PAL support for the Spartan 3/3Estarter kits so that Handel-C can be used to build and debug microblaze? Thanks NiravArticle: 101523
"Symon" <symon_brewer@hotmail.com> wrote in message news:4457270c$0$15789$14726298@news.sunsite.dk... > "Fred" <fred@nowhere.com> wrote in message > news:4456098b$0$203$db0fefd9@news.zen.co.uk... >> >> It does however depend on general working practices within the company >> such as is the occasional use of phones allowed for private use etc. >> Whether lawful would include contractual and normal practice within the >> company. If a clause in your contract is openly abused, known and >> accepted by management they cannot, on an ad-hoc basis, enforce it. >> >> > Hi Fred, > On a related note, did you see this in the Times yesterday? > http://business.timesonline.co.uk/article/0,,16849-2159286.html > HMRC might start taxing people to use work computers for personal email > and browsing. According to the article, the tax would appear to be based > on the cost of the computer. I guess you could just give everyone an old > £20 PC to use for email! > Cheers, Syms. > Yes I saw that and I find it amusing that the Treasury are running at odds to the DTI. In fact the DTI weren't aware until just before the last budget that the tax incentive of free home computers for employees was to stop. Also other government department were about to get schemes up and running and had to shelve them. The DTI are trying to promote computer use and the Treasury are trying to stifle it. In essence the Treasury are trying every way they can to increase revenue by the odd million or so. Good old stealth - tax by the back door. It's still laughable that HMRC overpaid Tax Credits by more than a £billion! In practice there will be a definition of "significant use" which stifle use rather bring any income to the Treasury.Article: 101524
Perhaps your pdf got cached at work? A fresh load comes up with 2.1 on all four modules here. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:1146583726.942714.21550@g10g2000cwb.googlegroups.com... > Something is wrong. I still get Ver 2.0. I am pretty sure I was able > to see ver 2.1 last night from home. But I am getting the old version > still here at work. > > > Austin Lesea wrote: >> Rick, >> >> I have just checked the Spartan 3 changes, and I am pleased to see what >> I think you need. >> >> http://direct.xilinx.com/bvdocs/publications/ds099.pdf >> >> page 56, Table 32 has the ranges of pullup currents, and their >> equivalent ranges in ohms. >> >> page 97, Table 68 through page 100 Table 69 has the definitions of the >> pins, with a statement of when the pullups are active, and when it >> matters. >> >> page 109, Table 74 reinforces the definition of the pins, and the >> pullups. >> >> Do you agree? >> >> My only complaints are that 'pullup' and 'pull-up' are both used, so >> searching for "strength" needed 'pull-up' and searching for "definition" >> needed 'pullup.' And W is used instead of omega (for ohms) in four >> places (describing pullup for DONE, etc.). >> >> I hope this will allow everyone to go back to work, now that they have >> the pull-up (pullup) resistors fully specified for 1.14 to 3.45 volts >> (as active devices, their strength varies with supply voltage). >> >> If anyone at your place of work is still unhappy/uncomfortable with your >> design choices, I would be happy to remind them (in writing) that the >> data sheet (product specification, combined with the encrypted spice >> models, IBIS models, and speeds files) are the controlling documents, >> and that what may be suggested by the hotline, or by a FAE (or even by >> me!) may not be the most optimal solution (anything that is not in >> writing and approved by Xilinx may have been subject to >> mis-interpretation, or may be in error), and that good engineering >> judgement combined with observance of the data sheet and other >> specifications I have listed above is what actually matters (in a >> practical and legal sense). >> >> Austin >
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