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
>> incorrect ucf file had some other signals driving the pins? >> >> LEDs are installed backwards and there is also maybe a short? > > no. > no pin mapping problem, no LED connection problems. > if LED1 and LED 2 are driven from other signal they work properly. > keep thinking;) Are the IO bank VCCO's, IO types and LED drive levels properly matched up? Elsewhere in your code, is some_signal or blink_one_second ever assigned the value 'Z'?Article: 125026
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:1192462938.206319.120810@i13g2000prf.googlegroups.com... > > vhdl code > > LED1 <= some_signal; > LED2 <= blink_one_second; > > the LED1,2 are connected to LED's > blink_one_second is simple wire that drives LED2 and nothing else. > > now the code works in real FPGA with following behaviour: > > when some_signal = 0, then LED2 blinks. > when some_signal = 1, then both LEDs blink as full sync to each other. > > what can cause this? > Hi Antti, Later on in your code you wrote:- LED1 <= blink_one_second AND some_signal; Do I win £5? Cheers, Syms.Article: 125027
Antti wrote: > vhdl code > > LED1 <= some_signal; > LED2 <= blink_one_second; > > the LED1,2 are connected to LED's > blink_one_second is simple wire that drives LED2 and nothing else. > > now the code works in real FPGA with following behaviour: > > when some_signal = 0, then LED2 blinks. > when some_signal = 1, then both LEDs blink as full sync to each other. > > what can cause this? > > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply. > > eh, the solution to the problem was weird. but it does exist. sure I > assumed FPGA fabric faulty first as I had overstressed the FPGA with > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully > working, yet the weird behaviour exist. and this is actually correct > behaviour in the particular case. > > I wonder if somebody is able to quess the answer to the issue. happy > thinking! > > Antti > One of the LEDs was installed backwards?Article: 125028
Duane Clark wrote: > jacobusn@xilinx.com wrote: >> The newest version of MIG will support 32-bit Linux Red Hat Enterprise >> 4.0. The newest version (2.0) will be in IP Update 2 for ISE 9.2i and >> will be released on 10/17/2007. > > That is good to hear. > >> What device are you targeting? > > My immediate use was for a V2Pro device, so I probably will have to > stick to the old tool for that... Just for the sake of completeness, I discovered that in the user interface generated by that tool, some signals are clocked on the system clock, some on a 90 degree phase shifted clock, and some on a 180 degree phase shifted clock. Yikes! So much for an "easy" interface. So I guess I won't be using that.Article: 125029
Kees Bakker <spam@altium.nl> writes: > Wine??? There are very, very few applications that actually work under Wine. > And of those, the majority is of no interest for Linux users, because there > are perfect alternatives which are native Linux. Linear Technology LTSpice (also known as SwitcherCAD) works well with Wine, and LT even supports it! Xilinx used to support ISE on Wine, before they had a native Linux version.Article: 125030
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:1192473204.719381.50050@t8g2000prg.googlegroups.com... > > eh, but no one is getting closer to my issue. > another hint, no flip flip or any sync logic thing is causing this > problem. > its also not in any way some compiler or P&R weirdness at all. > I think you should explain how the LEDs are connected. I don't think what you are describing would be possible if the LEDs were connected through individual current-limiting resistors with their anodes to FPGA pins and with their cathodes to GND. Also, I assume no FPGA special-purpose pins are involved... /MikhailArticle: 125031
I generated a 32-bit by 1024 entry FIFO using the FIFO Generator. The FIFO is an independently-clocked BRAM that has a 39 MHz clock on the write side and a 100 MHz clock on the read side. I am writing one 32-bit entity to the FIFO from the write side. The empty flag takes > 50 clock cycles on the read side to deassert. I would think that the empty flag would go low much sooner. Again, the FIFO is implemented as independent read/write clocks and I am using the structural simulation file. I need empty to go low much sooner than this.Article: 125032
Antti wrote: (...) > > I wonder if somebody is able to quess the answer to the issue. happy > thinking! > > Antti > Hi Antti I would suggest an incorrect mapping between the physical pins and the VHDL top-level ports (bad or missing UCF file).Article: 125033
Antti wrote: > On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: > >>I had a somewhat similar puzzle quite a few years ago. The code had a >>flip-flop generating out1 and an async assignment out2 = not out1. The two >>outputs were driving external buffers. Somehow the outputs got enabled >>together and the buffers smoked. I traced the problem to the synthesizer >>setting, which created another flop for the out2 and moved negation to its >>input. I don't remember all the details now, but IIRC the clock was missing >>for whatever reason when I first powered the board... Apparently debugging >>that board was my first assignment at a new job. Imagine how I felt when it >>smoked :) >> >>/Mikhail > > > eh, but no one is getting closer to my issue. > another hint, no flip flip or any sync logic thing is causing this > problem. > its also not in any way some compiler or P&R weirdness at all. Candidates are * Post-Pin error - Verifiable by checking the PIN levels, and dual-mapping the outputs. * Config/Mapping error (eg terminator enabled by accident, really slow clock etc ) * Logic Error. If the FPGA is OK, and the Compile/P&R is also OK that leaves the classic 'Cockpit error' -jgArticle: 125034
On Oct 15, 1:22 am, backhus <n...@nirgends.xyz> wrote: > Hi, > Your transmitter is sending 640kbit/s, but your receiver is reading only > 480kbit/s. With a continous operation on both sides your fifo needs to > be infinite. > > Missing data: Are there gaps in the transmitted data stream or some sort > of handshake? > > The average transmitted data has to be below 480kbit/s. It depends on > the method that is used to reduce the transmitters data rate how to > calculate the fifo size. > > have a nice synthesis > Eilert > > vishnuprasa...@gmail.com schrieb: > > > > > I have doubt in calculating FIFO depth. > > Transmitter is writing 16 bit data with a frequency of 40 KHz. > > Receiver is reading 8 bit data with a frequency of 60 KHz. > > What is the depth of FIFO I need to use and how I need to calculate > > the FIFO depth?- Hide quoted text - > > - Show quoted text - I can't afford infinite fifo From invalid@dont.spam Mon Oct 15 21:39:02 2007 Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!nx01.iad01.newshosting.com!newshosting.com!130.81.64.211.MISMATCH!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny09.POSTED!933f7776!not-for-mail From: Phil Hays <invalid@dont.spam> Subject: Re: FPGA quiz: what can be wrong User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.10.16.04.38.56.754798@dont.spam> Newsgroups: comp.arch.fpga References: <1192462938.206319.120810@i13g2000prf.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 24 Date: Tue, 16 Oct 2007 04:39:02 GMT NNTP-Posting-Host: 71.113.113.13 X-Complaints-To: abuse@verizon.net X-Trace: trndny09 1192509542 71.113.113.13 (Tue, 16 Oct 2007 00:39:02 EDT) NNTP-Posting-Date: Tue, 16 Oct 2007 00:39:02 EDT Xref: prodigy.net comp.arch.fpga:137017 Antti wrote: > > vhdl code > > LED1 <= some_signal; > LED2 <= blink_one_second; > > the LED1,2 are connected to LED's > blink_one_second is simple wire that drives LED2 and nothing else. > > now the code works in real FPGA with following behaviour: > > when some_signal = 0, then LED2 blinks. when some_signal = 1, then both > LEDs blink as full sync to each other. > > what can cause this? DCI. -- Phil HaysArticle: 125035
weak/no internal pull-up/down on LED1? Drive current?Article: 125036
On 16 Okt., 01:56, Jeff Cunningham <j...@sover.net> wrote: > >> incorrect ucf file had some other signals driving the pins? > > >> LEDs are installed backwards and there is also maybe a short? > > > no. > > no pin mapping problem, no LED connection problems. > > if LED1 and LED 2 are driven from other signal they work properly. > > keep thinking;) > > Are the IO bank VCCO's, IO types and LED drive levels properly matched up? > > Elsewhere in your code, is some_signal or blink_one_second ever assigned > the value 'Z'? all IO types OK no Z involvedArticle: 125037
On 16 Okt., 04:04, Matthieu <m.a.t.t.h.i.e.u.m.i.c.h....@laposte.net> wrote: > Antti wrote: > > (...) > > > > > I wonder if somebody is able to quess the answer to the issue. happy > > thinking! > > > Antti > > Hi Antti > > I would suggest an incorrect mapping between the physical pins and the > VHDL top-level ports (bad or missing UCF file). noArticle: 125038
On 16 Okt., 02:38, Ray Andraka <r...@andraka.com> wrote: > Antti wrote: > > vhdl code > > > LED1 <= some_signal; > > LED2 <= blink_one_second; > > > the LED1,2 are connected to LED's > > blink_one_second is simple wire that drives LED2 and nothing else. > > > now the code works in real FPGA with following behaviour: > > > when some_signal = 0, then LED2 blinks. > > when some_signal = 1, then both LEDs blink as full sync to each other. > > > what can cause this? > > > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply. > > > eh, the solution to the problem was weird. but it does exist. sure I > > assumed FPGA fabric faulty first as I had overstressed the FPGA with > > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully > > working, yet the weird behaviour exist. and this is actually correct > > behaviour in the particular case. > > > I wonder if somebody is able to quess the answer to the issue. happy > > thinking! > > > Antti > > One of the LEDs was installed backwards?- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - NO. both LEDs are OKArticle: 125039
On 16 Okt., 05:01, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: > > >>I had a somewhat similar puzzle quite a few years ago. The code had a > >>flip-flop generating out1 and an async assignment out2 = not out1. The two > >>outputs were driving external buffers. Somehow the outputs got enabled > >>together and the buffers smoked. I traced the problem to the synthesizer > >>setting, which created another flop for the out2 and moved negation to its > >>input. I don't remember all the details now, but IIRC the clock was missing > >>for whatever reason when I first powered the board... Apparently debugging > >>that board was my first assignment at a new job. Imagine how I felt when it > >>smoked :) > > >>/Mikhail > > > eh, but no one is getting closer to my issue. > > another hint, no flip flip or any sync logic thing is causing this > > problem. > > its also not in any way some compiler or P&R weirdness at all. > > Candidates are > * Post-Pin error - Verifiable by checking the PIN levels, and > dual-mapping the outputs. > * Config/Mapping error (eg terminator enabled by accident, really slow > clock etc ) > * Logic Error. If the FPGA is OK, and the Compile/P&R is also OK > that leaves the classic 'Cockpit error' > > -jg- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - NO NO NO all FPGA tools did exact and correct and proper job. no fuzz. in the matter of fact IF the LED behaviour would have been any different then that would have been an ERROR. so the described behaviour of the signals named LED1 and LED2 was CORRECT behavior. question is why? and yes it is solveable, and yes there is explanation. AnttiArticle: 125040
On 16 Okt., 01:59, "Symon" <symon_bre...@hotmail.com> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:1192462938.206319.120810@i13g2000prf.googlegroups.com... > > > > > > > vhdl code > > > LED1 <=3D some_signal; > > LED2 <=3D blink_one_second; > > > the LED1,2 are connected to LED's > > blink_one_second is simple wire that drives LED2 and nothing else. > > > now the code works in real FPGA with following behaviour: > > > when some_signal =3D 0, then LED2 blinks. > > when some_signal =3D 1, then both LEDs blink as full sync to each other. > > > what can cause this? > > Hi Antti, > Later on in your code you wrote:- > > LED1 <=3D blink_one_second AND some_signal; > > Do I win =A35? > Cheers, Syms.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - NO you do not - this is wrong suggestion. the VHDL code was checked many times by different people. there really isnt anything wrong with the VHDL, the led_blink signal has no route into the LED1 pathArticle: 125041
On 16 Okt., 03:45, "MM" <mb...@yahoo.com> wrote: > "Antti" <Antti.Luk...@googlemail.com> wrote in message > > news:1192473204.719381.50050@t8g2000prg.googlegroups.com... > > > > > eh, but no one is getting closer to my issue. > > another hint, no flip flip or any sync logic thing is causing this > > problem. > > its also not in any way some compiler or P&R weirdness at all. > > I think you should explain how the LEDs are connected. I don't think what > you are describing would be possible if the LEDs were connected through > individual current-limiting resistors with their anodes to FPGA pins and > with their cathodes to GND. Also, I assume no FPGA special-purpose pins are > involved... > > /Mikhail FPGA_pin - RESISTOR - LED - GND but as said the LED connection really had nothing todo with the issueArticle: 125042
On 16 Okt., 06:39, Phil Hays <inva...@dont.spam> wrote: > Antti wrote: > > > vhdl code > > > LED1 <= some_signal; > > LED2 <= blink_one_second; > > > the LED1,2 are connected to LED's > > blink_one_second is simple wire that drives LED2 and nothing else. > > > now the code works in real FPGA with following behaviour: > > > when some_signal = 0, then LED2 blinks. when some_signal = 1, then both > > LEDs blink as full sync to each other. > > > what can cause this? > > DCI. > > -- > Phil Hays- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - this is GOOD answer, wau. well its wrong but was good guess. really. if something is wrong then you should question ANY thing that can cause it. AnttiArticle: 125043
Antti wrote:
> when some_signal = 0, then LED2 blinks.
> when some_signal = 1, then both LEDs blink as full sync to each other.
>
> what can cause this?
Is LED1 blue?
-- Mike Treseler
Article: 125044On Oct 15, 10:44 am, vishnuprasa...@gmail.com wrote: > I have doubt in calculating FIFO depth. > Transmitter is writing 16 bit data with a frequency of 40 KHz. > Receiver is reading 8 bit data with a frequency of 60 KHz. > What is the depth of FIFO I need to use and how I need to calculate > the FIFO depth? follow this link http://www.asic-world.com/tidbits/fifo_depth.htmlArticle: 125045
On 16 Okt., 08:20, Mike Treseler <mike_trese...@comcast.net> wrote: > Antti wrote: > > when some_signal = 0, then LED2 blinks. > > when some_signal = 1, then both LEDs blink as full sync to each other. > > > what can cause this? > > Is LED1 blue? > > -- Mike Treseler ROTFL, another good answer! well no it isnt.Article: 125046
MM wrote: (snip on FPGA and LEDs) > I think you should explain how the LEDs are connected. I don't think what > you are describing would be possible if the LEDs were connected through > individual current-limiting resistors with their anodes to FPGA pins and > with their cathodes to GND. Also, I assume no FPGA special-purpose pins are > involved... With TTL it is usual to wire LEDs from Vcc to resistor to LED to output pin, as the outputs sink better than they source. I would expect that to be true for FPGAs, and even more with a 3.3V power source. The forward voltage of most LEDs is 1.6V or more (more for larger band gap). OP says when some_signal is 0 only LED2 blinks, so it seems that it is using the FPGA as a current source. No comment on current limiting resistor, though. -- glenArticle: 125047
Hi folks, the answers the first quiz have made some smile to my face, so I decided to make it more interesting and am actually offering prizes for the first correct answer, prizes will be FPGA miniconsole from www.xiltendo.com for first answer that is correct (to each quiz posted by me to C.A.F.), or for first question that requires me to answer in way that solution is obvious. the first quiz was the 2 LED one, already posted on C.A.F. so here comes the second (this is much much simpler) Xilinx Spartan3A on custom PCB. was working ok was stressed VCCINT=1.8V (regulator IC current limit 150ma) it does configure ok from external configuration memory JTAG scan returns JTAGID from Virtex-II family. what is wrong? Antti PS the prizes will be sent to the winner free of charge from first production batch. (and thats all public info til that time)Article: 125048
Hi,in a previous post i asked about an easy way to have my fpga self programmed at power on Xapp 974 shows how to program a SPI Flash with Impact 9.1.,it looks like a very simple method http://direct.xilinx.com/bvdocs/appnotes/xapp974.pdf My freeware Ise is finally stable,i would like it to stay there. Is it possible to download and install only the newest Impact version? Thanks once more DiegoArticle: 125049
Why don't you show a more meanngful code snippet? ---Matthew Hicks > On 16 Okt., 03:45, "MM" <mb...@yahoo.com> wrote: > >> "Antti" <Antti.Luk...@googlemail.com> wrote in message >> >> news:1192473204.719381.50050@t8g2000prg.googlegroups.com... >> >>> eh, but no one is getting closer to my issue. >>> another hint, no flip flip or any sync logic thing is causing this >>> problem. >>> its also not in any way some compiler or P&R weirdness at all. >> I think you should explain how the LEDs are connected. I don't think >> what you are describing would be possible if the LEDs were connected >> through individual current-limiting resistors with their anodes to >> FPGA pins and with their cathodes to GND. Also, I assume no FPGA >> special-purpose pins are involved... >> >> /Mikhail >> > FPGA_pin - RESISTOR - LED - GND > > but as said the LED connection really had nothing todo with the issue >
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