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
Peter Alfke wrote: > > in spite of (or because of) your nasty tone, > Please explain exactly what it was you found "nasty" about my post? I described my own experiences with documentation WebCases, and suggested that if you've never filed one, you should give it a try sometime, for a problem you've been involved with, to see for yourself what users find so frustrating. > > I will on Monday submit this to the responsible group > in Xilinx support. > I mentioned the flag bug not as an example of something that needed documenting, but merely as an example of something, with which you were familiar, to try opening a Webcase. I haven't looked for this information in the V4 datasheets, but Answer Record 22462 has a well written description of the flag problem. BrianArticle: 111126
Brian, we may have different definitions of the word "nasty", but you can be sure that all of your lines will find their way to the responsible parties in Xilinx. And I know that they are sensitive and sensible. I wish these problems could be ventilated in a less aggressive tone, but that may be a question of personal taste. Peter Alfke, who is interested in solving problems, not having them linger and cause frustration. ==================== On Oct 29, 7:17 pm, "Brian Davis" <brimda...@aol.com> wrote: > Peter Alfke wrote: > > > in spite of (or because of) your nasty tone, Please explain exactly what it was you found "nasty" > about my post? > > I described my own experiences with documentation WebCases, > and suggested that if you've never filed one, you should give > it a try sometime, for a problem you've been involved with, to see > for yourself what users find so frustrating. > > > > > I will on Monday submit this to the responsible group > > in Xilinx support. I mentioned the flag bug not as an example of something > that needed documenting, but merely as an example of something, > with which you were familiar, to try opening a Webcase. > > I haven't looked for this information in the V4 datasheets, > but Answer Record 22462 has a well written description of the > flag problem. > > BrianArticle: 111127
On 29 Oct 2006 09:43:10 -0800, "Guru" <ales.gorkic@email.si> wrote: >I am having about the same experience. >I upgraded my computer to EDK/ISE 8.2 > >1. I upgraded my GSRD2 (PPC, MPMC2, TEMAC) design to v8.2. There were >actually no problems detected until I used the flashwriter.tcl script. >I does not work at all. OK, minor thing to remedy. > >2. I upgraded my PPC CoreConnect project to 8.2. First the XMD connect >failure (wrong processor version 0x00000000). Then I connected >secesfully using "connect ppc hw", but the design does not work at all >- probably some hw error. The sw crashes when setting interrupt >controller (working nice in 8.1). > >Fu.. that 8.2 and hope for the SP2 to remedy the problems. > >Cheers, > >Guru I am jus wondering if ther problem lies: 1. Either in the target selected (some problem with Syn/Xlat/Map/Par): I am using an Spartan 3: 3S400 2. Or in the Computer: I am using an AthlonX2, both in the dual 8.1/8.2 installation, and in a clean 8.2 installation on a bran new laptop, that also fails. Antti? Guru? Do you see any recurrence here? ZaraArticle: 111128
They didn't give a lot of options on this board as far as I can see. The serial port driver is not rated up to the speed you need so is not likely to be of much use. You also don't appear to have Ethernet or USB which would be the obvious choices. What you do have is parallel I/O which could be used to communicate with the board but will need some kind of supporting card, or interface, either to add a Ethernet/USB interface or simply to provide some kind of simplier interface that can transfer the data to the PC. Once inside the PC the 1MBit/s should not be a major issue. If want some more direct assistance on an interface contact our University Access Program (UAP) team. Email and UAP details can be found on our webpage http://www.enterpoint.co.uk/uap/uap.html. John Adair Enterpoint Ltd. bartzenbeggar@gmail.com wrote: > Hi, I am an undergrad student attempting to build a software defined > radio device on a Stratix EP1S80 DSP Development Board, and am hoping > to do most of the signal processing on a PC. I therefore need to > transfer data to the PC at a rate of about 1 MBps (twice the AM IF > frequency of 455 kHz at 8 bit signal resolution) - is this possible? > What is the best way of establishing communication between the PC and > FPGA at such high speeds? Any suggestions are much appreciated, thank > you.Article: 111129
krishna.janumanchi@gmail.com schrieb: > This is clearly Metastabilty issue. Thomas is correct. > I was also having such kind of problem. > There is an interesting article in cadence on Metastability & Cross > Clock domain. > If you have time, go through it > http://www.cadence.com/whitepapers/cdc_wp.pdf Just to be clearl I expect this to be _no_ metastability problem. APA at 8 MHz needs extrem curios HW to have any issue regarding metastability. As a rule of thumb which is valid for any actual devices from Actel (and which I would also use for any other Fpgas), you could say that 1 ns settling time is enough to say that this device will have no more than _one_ effect due to metastability before it crumbles to dust. The problem is a timing issue regarding asynchronous inputs. The only point I said, is that a circuitry removing this timing issue for sure also removes the problem of metastability [1]. In fact it is enough to guarantee that each input feeds only one FF, but as some synthesiser uses register doubling for load balancing, it is not enough to have only one FF in rtl, so it is safe to use 2-3 serial FF in rtl to be safe against doubling of the FF at the input. bye Thomas [1] To be precise it can't be fully removed, but i consider MTBF >10^100 years as safe enough to use the term "removed" under any reasonable circumstances.Article: 111130
If you are using Simulink then you can purchase the HDL Coder add-on which will generate synthesisable HDL for some of your blocks. If you use m-code then there is a very powerful product called Catalytic MCS which converts m-code into Catapult (Mentor's C synthesiser) compatible C code, for these 2 products you do need a healthy EDA budget :-) http://www.mathworks.com/products/slhdlcoder/ http://www.catalyticinc.com/ Hans www.ht-lab.com <lerbacattivanonmuoremai@gmail.com> wrote in message news:1162161643.411233.256720@i42g2000cwa.googlegroups.com... > hi to all, > I'm developing a filter for imaging with matlab. In few days the code > will be completed but I don't understood if is possible to compile it > directly to vhdl, without rewrite all the stuff from scratch... > > Any experience or suggestion about it? > > Thanks! >Article: 111131
I took the plunge and built up a 2nd PC using a Core2Duo. Here are the specs: Old PC: P4 3GHz HT, 2GB DDR2-533 RAM, Gigabyte GA81915 mobo, stock cooler New PC: Core2Duo E6600, 2GB DDR2-800 RAM, ASUS P5B Mobo, ArcticFreezer7 cooler Using a Spartan3 design running clean from scratch in ISE 8.2.3i Old PC: 82mins New PC: 35mins New PC (overclocked to 3.2GHz): 25mins I'm really pleased with the Core2Duo and would recommend it. MarcArticle: 111132
i have got a problem while i am generating bit file using xilinx ise 7.1i for spartan 3E device i am getting warining as warning: Bitgen:26 - bitgen only supports DRC on this device. Error: bitgen failed Reason: Process "Generate Programming File" did not complete. i am using xilinx webpack what the cause of the problem for this warning as a result i am unable to generate the bit file which is used for downloading to the kit. what kind of possible mistakes may result this kind of errors. or else i need to update the software IP downloads .......... give me some sort of suggestion................... if at all to update bitgen how can i proceed since i am beginner i need some guidence thanks and regards, srikArticle: 111133
bartzenbeggar@gmail.com wrote: > Hi, I am an undergrad student attempting to build a software defined > radio device on a Stratix EP1S80 DSP Development Board, and am hoping > to do most of the signal processing on a PC. I therefore need to > transfer data to the PC at a rate of about 1 MBps (twice the AM IF > frequency of 455 kHz at 8 bit signal resolution) - is this possible? Why do you want to do the signal processing on a PC? Maybe you need a digital filter and a demodulator, which should fit inside the FPGA. Then you can generate the audio signal with the D/A converter on your board. The 7 segment display can display the frequency, the pushbuttons can be used to implement a automatic scanning receiver etc. No need for a PC. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 111134
Hi I am trying to infer a Xilinx dual port block ram with different address and data widths. I want to infer it in my code and then get Synplify to recognise it. I can do this if the address and data are the same but dont know how if they are different. Thanks JArticle: 111135
Peter Alfke wrote: > we may have different definitions of the word "nasty" <snip> > I wish these problems could be ventilated in a less aggressive tone, > but that may be a question of personal taste. Since you continue to refer to my original post as "nasty" and now "agressive", I ask you once again to explain exactly what part of that post you found offensive. I am hardly the first person on the newsgroup to express exactly these same opinions about the usefulness of WebCases, and your documentation system's handling of both customer feedback and long-known, yet poorly documented, problems. My comments are based on 20 years of experience using Xilinx parts; during that time I have attempted to have Xilinx correct serious flaws in their documentation and/or software on several occasions, with no success, as described in my original post. BrianArticle: 111136
Hi, I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke the Virtex-II series they now offer the possibility to route various clock signals to several domains on the FPGA and select them locally by specific clock multiplexer inputs. Because of the restricted amount of available pins on the device I selected (Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input on each side of the FPGA, thereby saving clock multiplexer inputs which I can use as normal GPIOs, and use an external clock multiplexer instead for my 3 clocks. Has anyone made experience with such or similar solution? Has anyone used an external clock multiplexer device for frequencies up to 500 MHz, yet? Is there any recommendation which chip I could use for this application in terms of jitter, etc.? And by the way... is my approach advisable, at all? Any comments are appreciated. Regards ElmoArticle: 111137
thanks both for your input, Thomas's 2-stage shift register seems to have fixed the jumping problem :)Article: 111138
I've written a program to calculate the CRC of Virtex-II Pro bit stream and I'm having trouble validating my results. Testing it against an existing bit stream, I do not get the right CRC result but I'm not sure if it's my calculations or how I am choosing which data is incorporate into the CRC. I've based my code on the Virtex Series Configuration Architecture Users Guide (XAPP151) and the Virtex-II Pro and Virtex-II Pro X FPGA Users Guide (UG012). There are a few other posts in the forum regarding Xilinx CRC calculations. They suggest that I check bit order, reset the CRC at the proper times, and include the register address as part of the word that is feed into the CRC calculation. I've double checked and believe that I'm doing all of these correctly. Does anyone know of some test data that I can use to test my CRC calculation? If I could test 1 or 2 calculations and validate that my CRC calculation are correct, I could eliminate the calculation as the cause of the problem. I know that there are a couple of CRC-16 calculators online, but I do not get the same results as they produce. I'm not sure if they are not designed to handle a 36 bit input, or if my calculations are wrong. Any help or suggestions would be greatly appreciated. Thanks, DavidArticle: 111139
Wmaxascent wrote: > Hi I am trying to infer a Xilinx dual port block ram with different > address and data widths. I want to infer it in my code and then get > Synplify to recognise it. I can do this if the address and data are the > same but dont know how if they are different. > > Thanks > > J When I recently asked the Synplicity folks if there was *any* appropriate syntax to imply different widths for Synplify inferred memories, I was told there was none.Article: 111140
I am implementing an extremely old logic design (circa 1965!) on a Xilinx Virtex 4 (XC4VLX25). For those interested - it is the logic for the computer that flew to the moon and back! The design is based on approximately 5,000 3-input NOR gates and not a flip flop in sight! For the circuit diagrams see website 'http://klabs.org/history/ech/agc_schematics/index.htm'. I have implemented the timer and scaler modules that divide the input 2.048 MHz clock signal. The logic works beautifully in the ModelSim environment (after having implemented some delays and initial conditions for signals that form a bistable latch made from the NOR gates) but I am having fun and games with synthesising the logic. My biggest problem is the time that XST takes to synthesise the logic. ISE just grinds to a halt after reporting the combinatorial loops with the message: Optimizing unit <AGC> ... I have left it for over two hours like this... I still haven't ever managed to synthesis the complete timer and scaler modules! I have cut down the scaler module to one or two divider sections and this does synthesise OK. I don't really want to change the logic to suite the tool as I am trying to be as true to the original design as I can be. I have coded the logic up in a similar manner to the following: subtype AGCBIT is STD_LOGIC; -- etc. etc. etc. etc. constant INI_HI : AGCBIT := '1'; constant INI_LO : AGCBIT := '0'; constant gate_delay : time := 1 ps; -- etc. etc. etc. etc. signal \37101\ : AGCBIT := INI_LO; signal \37102\ : AGCBIT := INI_HI; signal \37103\ : AGCBIT := INI_LO; signal \37104\ : AGCBIT := INI_HI; -- etc. etc. etc. etc. \37101\ <= not( \37105\ or \37102\ ); \37102\ <= not( \37101\ or CLOCK or \37103\ ) after gate_delay; \37103\ <= not( \37102\ or CLOCK or \37104\ ); \37104\ <= not( \37103\ or \37106\ ); PHS2 <= \37104\; -- etc. etc. etc. etc. Each of the existing logic gate has a 'number' on the original circuit diagrams (e.g. 37101). I have converted all of these to signals and entered the logic in VHDL by hand-transcribing from the original circuit diagrams. Does anyone have any ideas as to why ISE is taking soooooo long to optimise the design (apart from trying all possible combinations/permutations of logic layout) and (more importantly) how to speed it up? Any help gratefully received...Article: 111141
krishna.janumanchi@gmail.com wrote: > This is clearly Metastabilty issue. Thomas is correct. > I was also having such kind of problem. > There is an interesting article in cadence on Metastability & Cross > Clock domain. > If you have time, go through it > http://www.cadence.com/whitepapers/cdc_wp.pdf > > Regards, > Krishna Janumanchi > > > Helen wrote: > >>Thanks Thomas - I will try this! > > No, in fact I'd say clearly not a metastability problem, rather a race condition caused by an async input going to more than one flip-flop. The only way to get metastability to consistently show up is to force the issue by having a synchronous system with a delay between flip-flops that is exactly adjusted to land the output transition of the first flip flop right at the very small metastability window of the second flip-flop. In a system with a matastability problem at an input or otherwise crossing clock domains, using modern FPGAs, you are likely not going to see any evidence of a metastability in the lab, and even if you do, you are not likely to repeat it sufficiently frequently to observe it. The problem is surely a synchronization issue. If you have an asynchronous input to a synchronous machine feeding more than one flip-flop in the machine, unless the delay from the input to every flip-flop, as well as the delay of the clock to each flip-flop it feeds is precisely matched (impossible to do), then there is some point where a change in the input is detected on different clock cycles by the two flip-flops. For example, consider a simple system where an async signal is just fed to the D inputs of two flip-flops. The flip flops are clocked by a clock signal with a period of 10ns. Assume the clocks arrive at both flip-flops at the same instant. The delay from the input to the first flip flop is 4ns, and the delay from the async input to the second flip-flop is 6ns. If the input changes within 4ns before or after the clock edge, both flip-flops will register the change on the same clock. However, if the input changes 5ns after the clock edge, it will arrive at the first flip-flop just before the next clock edge, but will arrive at the second flip-flop just AFTER the next clock edge. The result is the first flip-flop changes a clock ahead of the second flip-flop. The same effect happens if the input delays are identical but the clock is delayed to one of the flip-flops relative to the other. For an asynchronous input, there is no set relationship of the arrival of the input change to the timing of the clock pulse, so eventually you will have a case like the one described above where two flip-flops sense the same input event on different clock edges. The only way to avoid that is to ensure that any asynchronous event is sensed by one, and only one flip-flop in the design. The usual approach is to synchronize the event using a flip-flop and then distributing that synchronized event rather than the event itself to the rest of the design. Special care has to be taken with asynchronous inputs that are more than one bit wide, as such an input feeds more than one flip flop by definition. In that case, you need to use hold the data stable while a strobe signal is used to signal the arrival of good data to the system and then transfer that latched good data.Article: 111142
Does anyone know how to simulate the picoblaze processor in modelsimXE(xilinx specific version) Is it possible?Article: 111143
daver2 wrote > I don't really want to change the logic to suite the tool as I am > trying to be as true to the original design as I can be. I have coded > the logic up in a similar manner to the following: ... ... > \37101\ <= not( \37105\ or \37102\ ); > \37102\ <= not( \37101\ or CLOCK or \37103\ ) after gate_delay; > \37103\ <= not( \37102\ or CLOCK or \37104\ ); > \37104\ <= not( \37103\ or \37106\ ); PHS2 <= \37104\; Can you write a Perl script to whizz through the code and extract the flops and latches?Article: 111144
David wrote: > I've written a program to calculate the CRC of Virtex-II Pro bit stream > and I'm having trouble validating my results. Testing it against an > existing bit stream, I do not get the right CRC result but I'm not sure > if it's my calculations or how I am choosing which data is incorporate > into the CRC. I've based my code on the Virtex Series Configuration > Architecture Users Guide (XAPP151) and the Virtex-II Pro and Virtex-II > Pro X FPGA Users Guide (UG012). > > There are a few other posts in the forum regarding Xilinx CRC > calculations. They suggest that I check bit order, reset the CRC at > the proper times, and include the register address as part of the word > that is feed into the CRC calculation. I've double checked and believe > that I'm doing all of these correctly. > > Does anyone know of some test data that I can use to test my CRC > calculation? If I could test 1 or 2 calculations and validate that my > CRC calculation are correct, I could eliminate the calculation as the > cause of the problem. I know that there are a couple of CRC-16 > calculators online, but I do not get the same results as they produce. > I'm not sure if they are not designed to handle a 36 bit input, or if > my calculations are wrong. > > Any help or suggestions would be greatly appreciated. > > Thanks, > > David I was able to determine what my problem was, so I thought I would share my solution: XAPP151 is written for the Virtex series which have 4-bit register addresses. The code in XAPP151 performed the CRC calculation with a loop that iterates over 36 bits of incoming data (4 address bits plus 32 bit word). The Virtex-II Pro has a 5-bit address register so the input to the CRC calculation is 37 bits. The loop in XAPP151 must changed to loop 37 times for it to work on the Virtex-II Pro. I hope this saves someone some frustration. - DavidArticle: 111145
Hello, I want to buy a new PC and I will use it mainly for Xilinx ISE. What is the best configuration? Does Xilinx ISE support Intel Core Duo or AMD Athlon 64 processors? Regards.Article: 111146
>I want to buy a new PC and I will use it mainly for Xilinx ISE. What is >the best configuration? Does Xilinx ISE support Intel Core Duo or AMD >Athlon 64 processors? Get a cpu with as much as possible L1 and secondarly L2 cache. Lot's of ordinary DRAM helps too ofcourse. What I've read SMP doesn't make any huge difference. (Maybe one could produce some makefile that splits the process in parallell pieces?)Article: 111147
Frai wrote: > Hello, > > I want to buy a new PC and I will use it mainly for Xilinx ISE. What is > the best configuration? Does Xilinx ISE support Intel Core Duo or AMD > Athlon 64 processors? > > Regards. If you are using xilinx ise modelsim and Impact(programming the fpga).make sure u have plenty of RAM ~1GB.Article: 111148
hi i have a micorblaze projet on a spartan 3 wit 8 k instruction an data cache linked with the ddr ram. the memory test and the peripheral test works fine. now i started to write my own applicatin using xilkernel and lwip. my problem now is the my application does not work. it compiles fine but whe i try to download it via the debugger i get a "programm received a SIGABRT" message. do i have to enable the cache in my application the same way as in the test programms? or do i have to do anything else. a small sample programm or some hints would be very welcome. thanks urbanArticle: 111149
I agree with Ray, and since I had just posted a longish explanation of the same subject, please allow me to copy it here: To paraphrase Karl Marx: A spectre is haunting this newsgroup, the spectre of metastability. Whenever something works unreliably, metastability gets the blame. But the problem is usually elsewhere. Metastability causes a non-deterministic extra output delay, when a flip-flop's D input changes asynchronously, and happens to change within an extremely narrow capture window (a tiny fraction of a femtosecond !). This capture window is located at an unknown (and unstable) point somewhere within the set-up time window specified in the data sheet. The capture window is billions of times smaller than the specified set-up time window. The likelihood of a flip-flop going metastable is thus extremely small. The likelihood of a metastable delay longer than 3 ns is even less. As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz clock, causes an extra 3 ns delay statistically once every billion years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs ten times more often, once every 100 million years. But a 2.5 ns delay happens a million times more often ! See the Xilinx application note XAPP094 You should worry about metastability only when the clock frequency is so high that a few ns of extra delay out of the synchronizer flip-flop might causes failure. The recommended standard procedure, double-synchronizing in two close-by flip-flops, solves those cases. Try to avoid clocking synchronizers at 500 MHz or more... So much about metastability. The real cause of problems is often the typical mistake, when a designer feeds an asynchronous input signal to more than one synchronizer flip-flop in parallel, (or an asynchronous byte to a register, without additional handshake) in the mistaken believe that all these flip-flops will synchronize the input on the same identical clock edge. This might work occasionally, but sooner or later subtle difference in routing delay or set-up times will make one flip-flop use one clock edge, and another flip-flop use the next clock edge. Depending on the specific design, this might cause a severe malfunction. Rule #1: Never feed an asynchronous input into more than one synchronizer flip-flop. Never ever. Peter Alfke ============================== On Oct 30, 7:45 am, Ray Andraka <r...@andraka.com> wrote: > krishna.januman...@gmail.com wrote: > > This is clearly Metastabilty issue. Thomas is correct. > > I was also having such kind of problem. > > There is an interesting article in cadence on Metastability & Cross > > Clock domain. > > If you have time, go through it > >http://www.cadence.com/whitepapers/cdc_wp.pdf > > > Regards, > > Krishna Janumanchi > > > Helen wrote: > > >>Thanks Thomas - I will try this!No, in fact I'd say clearly not a metastability problem, rather a race > condition caused by an async input going to more than one flip-flop. > The only way to get metastability to consistently show up is to force > the issue by having a synchronous system with a delay between flip-flops > that is exactly adjusted to land the output transition of the first flip > flop right at the very small metastability window of the second > flip-flop. In a system with a matastability problem at an input or > otherwise crossing clock domains, using modern FPGAs, you are likely not > going to see any evidence of a metastability in the lab, and even if you > do, you are not likely to repeat it sufficiently frequently to observe it. > > The problem is surely a synchronization issue. If you have an > asynchronous input to a synchronous machine feeding more than one > flip-flop in the machine, unless the delay from the input to every > flip-flop, as well as the delay of the clock to each flip-flop it feeds > is precisely matched (impossible to do), then there is some point where > a change in the input is detected on different clock cycles by the two > flip-flops. > > For example, consider a simple system where an async signal is just fed > to the D inputs of two flip-flops. The flip flops are clocked by a > clock signal with a period of 10ns. Assume the clocks arrive at both > flip-flops at the same instant. The delay from the input to the first > flip flop is 4ns, and the delay from the async input to the second > flip-flop is 6ns. If the input changes within 4ns before or after the > clock edge, both flip-flops will register the change on the same clock. > However, if the input changes 5ns after the clock edge, it will arrive > at the first flip-flop just before the next clock edge, but will arrive > at the second flip-flop just AFTER the next clock edge. The result is > the first flip-flop changes a clock ahead of the second flip-flop. The > same effect happens if the input delays are identical but the clock is > delayed to one of the flip-flops relative to the other. > > For an asynchronous input, there is no set relationship of the arrival > of the input change to the timing of the clock pulse, so eventually you > will have a case like the one described above where two flip-flops sense > the same input event on different clock edges. The only way to avoid > that is to ensure that any asynchronous event is sensed by one, and only > one flip-flop in the design. The usual approach is to synchronize the > event using a flip-flop and then distributing that synchronized event > rather than the event itself to the rest of the design. > > Special care has to be taken with asynchronous inputs that are more than > one bit wide, as such an input feeds more than one flip flop by > definition. In that case, you need to use hold the data stable while a > strobe signal is used to signal the arrival of good data to the system > and then transfer that latched good data.
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