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 13 Aug., 11:51, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > quote from Xilinx webpage: "Xilinx is upgrading its forum software. > > These forums, along all their content, will be retired on August 30th, > > 2007. Starting August 13th, you will be given an opportunity to move > > existing threads to our new forums. Thank you." > > > today is 13th, I expected at least today that there will be more > > information about how to use the "new forums" - but unfortunatly > > NOTHING, is the new opportunity really only "for selected members of > > the community" who have received special invitations? Looks like. > > > Xilinx I will not beg for this opportunity. I was just wondering, and > > wanted to check if Xilinx this time keeps the promise (use of new > > forums starting from 13th August 2007). Well 13th is not yet over > > there are a few hours left, even in Japan, so maybe the webmaster will > > open the access still today. > > > Antti Lukats > > Hi Antti, > Whilst you are strictly correct, expecting to time a company like > Xilinx, with a stopwatch, has to be the definition of optimism! :) > > -jg- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - you found one! (an optimist) AnttiArticle: 122976
> [root@localhost uClinux-dist]# make dep ~~~~~ yes, look at it.Article: 122977
August 13th US TimeArticle: 122978
"jacobusn@xilinx.com" <naude.jaco@gmail.com> wrote in message news:1187003706.627529.321720@b79g2000hse.googlegroups.com... > August 13th US Time > Dang, is the entire US on one time zone now? ;) KJArticle: 122979
Help, where is the new xilinx forum ? DavidArticle: 122980
On 13 Aug., 14:58, "David Binnie" <td.bin...@blueyonder.co.uk> wrote: > Help, where is the new xilinx forum ? > > David that what I wanna know too ;) I assume some secret info about it was sent to selected people's emails. as far as I can see there is no info beyond what was in those bulk- emails hm... and today is 13th and help what time is it in Hawaii? ..it still belongs to the US? ok, let the westcoast to wake up, maybe it all clears up when xilinx webmaster arrives at his work place AnttiArticle: 122981
ekavirsrikanth@gmail.com wrote: > hi all, > > i have got one problem: > > i have designed sonet sts-3c framer/deframer where it works at 155mhz > freq which i am getting it form the optics card whrere CDR(clock data > recovery circuit outside the board). form that circuit i am getting > the differential data and differetial clock as inputs and i am > processing for output (differential data). which iam sending it to > optics card which will convert the electrical diff data into optical > signal and it is recongniged in the OmniBer (performace analyzer). my > problem is as i am getting the data and the clock i have a problem in > detecting the output on OMNIBER but my logic looks quiet ok. > > i am using virtex - 2pro fpga which can support 155mhz clock....... <snip> > plz i need feedback from u guys > > > regards > srik FPGAs are not precision analog components. The jitter produced by an FPGA will be large compared to SONET jitter specifications. If your "omniber" is not tolerant to this excessive jitter, your results may not be what you want. Please clarify: if pass the data from the omniber to the FPGA and back to the omniber, are your results fine? That wasn't clear. Is your problem that the loopback data *is* fine but your own frame logic is not? Do you know what portion of the frame and payload is scrambled and what is not?Article: 122982
Antti wrote: > On 8 Aug., 03:30, austin <aus...@xilinx.com> wrote: >> Symon, >> >> Well, all I can say, is that this is an attempt to improve our service. >> > Austin, > > please try todo something, so that "attempts" do not remain as > "attempt" but lead somewhere too. > > Xilinx webpage reads that from 13th of august the messages from old > forums can be moved to the new forums. > > This is not the case, I just posted on Xilinx old forums, and was not > able to move the topic to the new forum. > > So the 13th August thing, (an attempt to impove service ?) - is at > least delaying, or so it looks from the public web presence. > > It makes no sense to announce that something will happen on 13th, and > then not do this this on the date promised. > > To me it seems like the attempt to launch the new forums on 13th have > failed. > > Or maybe they are super secret ones? > > Antti Lukats In the west coast time zone (PDT) many of us are barely awake on this Monday morning, much less at work being productive. If there are about 17 calendar days to move threads between forums, give it a day. It's a new week. Honestly, I'm surprised your so eager! - John_HArticle: 122983
On 13 Aug., 15:19, John_H <newsgr...@johnhandwork.com> wrote: > Antti wrote: > > On 8 Aug., 03:30, austin <aus...@xilinx.com> wrote: > >> Symon, > > >> Well, all I can say, is that this is an attempt to improve our service. > > > Austin, > > > please try todo something, so that "attempts" do not remain as > > "attempt" but lead somewhere too. > > > Xilinx webpage reads that from 13th of august the messages from old > > forums can be moved to the new forums. > > > This is not the case, I just posted on Xilinx old forums, and was not > > able to move the topic to the new forum. > > > So the 13th August thing, (an attempt to impove service ?) - is at > > least delaying, or so it looks from the public web presence. > > > It makes no sense to announce that something will happen on 13th, and > > then not do this this on the date promised. > > > To me it seems like the attempt to launch the new forums on 13th have > > failed. > > > Or maybe they are super secret ones? > > > Antti Lukats > > In the west coast time zone (PDT) many of us are barely awake on this > Monday morning, much less at work being productive. If there are about > 17 calendar days to move threads between forums, give it a day. It's a > new week. > > Honestly, I'm surprised your so eager! > > - John_H- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - well, should they get started at least ? oh, ok let the webmaster to wake up and get productive. AnttiArticle: 122984
On 13 Aug., 14:58, "David Binnie" <td.bin...@blueyonder.co.uk> wrote: > Help, where is the new xilinx forum ? > > David well, I found it ;) assume it will be found by the others too soon AnttiArticle: 122985
On Aug 13, 5:35 am, "KJ" <kkjenni...@sbcglobal.net> wrote: > "jacob...@xilinx.com" <naude.j...@gmail.com> wrote in message > > news:1187003706.627529.321720@b79g2000hse.googlegroups.com...> August 13th US Time > > Dang, is the entire US on one time zone now? ;) > > KJ Xilinx headquarters is on Pacific Daylight (saving) Time. It is not yet 8:00 in the morning. I just woke up. Give us a break, folks.. Peter AlfkeArticle: 122986
Antti, I suppose 8 AM PDT is the magic time ... Austin Antti wrote: > On 13 Aug., 14:58, "David Binnie" <td.bin...@blueyonder.co.uk> wrote: >> Help, where is the new xilinx forum ? >> >> David > > well, I found it ;) > assume it will be found by the others too soon > > Antti >Article: 122987
On 13 Aug., 16:47, Peter Alfke <al...@sbcglobal.net> wrote: > On Aug 13, 5:35 am, "KJ" <kkjenni...@sbcglobal.net> wrote: > > > "jacob...@xilinx.com" <naude.j...@gmail.com> wrote in message > > >news:1187003706.627529.321720@b79g2000hse.googlegroups.com...> August 13th US Time > > > Dang, is the entire US on one time zone now? ;) > > > KJ > > Xilinx headquarters is on Pacific Daylight (saving) Time. It is not > yet 8:00 in the morning. I just woke up. > Give us a break, folks.. > Peter Alfke Hi Peter, ok, point taken, and maybe its time for me to look for a new "favorite t-shit" the last one I really liked did read No Limits No Mercy but this was long time ago Antti Lukats http://www.antti-brain.com PS, if somebody cares to look then there are some posts from me on the new forums already ;)Article: 122988
On Aug 10, 10:37 am, pgw <"SwietyMikolaj["@]poczta.onet.pl> wrote: > Hi > > I want to use in my project (with Spartan3 or Cyclone2) a DDR/DDR2 DIMM > module. I have chosen DDR because is avaiable and cheaper than SDR. > I have no experience with memory controllers and not to big with FPGA, > that's why I don't know which design solution to choose. > I don't need fast data rate (least possible is enough to me) > As DDR /DDR2 is a pipelined burst memory then you have to be aware of the effect of this on your design. Depending on your data source, you may need another controller to packetise the data into appropriate bursts. If you have a low data throughput requirement, then it might be easiest to do this in a FPGA based micro core. Certainly Xilinx has DDR 1/2 controllers available that plug onto their micro cores. This would be less error prone than hacking around with a MIG design, unless producing a controller is the main part of your academic project. Can you tell us any more details about your applciation?Article: 122989
Hi there,
I've been using the Xilinx University Program Virtex-II Pro development
board and I'm having great trouble writing code to interface to the
SystemACE compactflash system.
I expect my program (attached below) to open one file, read two bytes,
and close it; then open another file for writing, write two bytes to it,
and close that.
However, the output shows that main() is starting again, despite there
being no looping or recursive calls to induce this. (Some
experimentation showed that moving the location of the sysace_fclose()
calls changed the point at which main() restarted.)
The problem disappears if I change both file accesses to read mode "r"
(and the corresponding sysace_fwrite() calls to sysace_fread()).
Is it simply not possible to read and write from different files within
the same program?
The xilfatfs settings in the system.mss file are the following;
BEGIN LIBRARY
PARAMETER LIBRARY_NAME = xilfatfs
PARAMETER LIBRARY_VER = 1.00.a
PARAMETER PROC_INSTANCE = microblaze_0
PARAMETER CONFIG_WRITE = true
END
---8<-- begin broken.c ---------
#include <stdio.h>
#include <stdlib.h>
#include <sysace_stdio.h>
int main(void)
{
SYSACE_FILE *bmpfile, *txtfile;
char *bmpfilename, *txtfilename;
unsigned char magic[3] = "xx";
bmpfilename = "image.bmp";
txtfilename = "test1.txt";
xil_printf("Entering main(), compiled "__DATE__" "__TIME__"\n");
// open BMP file
// expecting "BM"
xil_printf("Trying to open %s\n",bmpfilename);
bmpfile = sysace_fopen(bmpfilename,"r");
if(bmpfile==NULL) {
xil_printf("Error opening %s\n",bmpfilename);
exit(1);
}
sysace_fread(magic,1,2,bmpfile);
xil_printf("Bytes are:%s\n",magic);
sysace_fclose(bmpfile);
// open and close text file
// write the bytes from the BMP file
xil_printf("Trying to open %s\n",txtfilename);
txtfile = sysace_fopen(txtfilename,"w");
if(txtfile==NULL) {
xil_printf("Error opening %s\n",txtfilename);
exit(1);
}
// write bytes from BMP file to text file
sysace_fwrite(magic,1,2,txtfile);
xil_printf("Bytes written are:%s\n",magic);
sysace_fclose(txtfile);
xil_printf("Exiting main()\n");
return 0;
}
----8<---- output ------------
Entering main(), compiled Aug 13 2007 14:32:43
Trying to open image.bmp
Bytes are:BM
Trying to open test1.txt
Bytes written are:BM
Entering main(), compiled Aug 13 2007 14:32:43
Trying to open image.bmp
Bytes are:BM
Trying to open test1.txt
Bytes written are:BM
Entering main(), compiled Aug 13 2007 14:32:43
Trying to open image.bmp
Bytes are:BM
Trying to open test1.txt
Bytes written are:BM
....etc etc ad infinitum
Article: 122990Patents are often difficult to follow, I suggest you use something (like google http://www.google.com/patents) to search for what you are asking about. After spending a few hours, you should be able to see what Xilinx has claimed as what they 'own', and what others claim they 'own.' Generally speaking, if a designer needs to provide a feature, and that feature is patented by their competitor, there are usually ways to not infringe. The implementation may not be optimal, or the least costly, or the best performance, but often it is adequate, and meets the design goals. Since Lattice bought up the ORCA(tm Lucent) products, and Lucent and Xilinx had cross-licenses in place (this was during the "second source days"), there also may still be agreements that survive to this day (I just do not know, however). As Peter suggests, unless you are interested in a career in law, this is best left to the lawyers. AustinArticle: 122991
> > However, the output shows that main() is starting again, despite there > being no looping or recursive calls to induce this. (Some > experimentation showed that moving the location of the sysace_fclose() > calls changed the point at which main() restarted.) > > The problem disappears if I change both file accesses to read mode "r" > (and the corresponding sysace_fwrite() calls to sysace_fread()). > > Is it simply not possible to read and write from different files within > the same program? > Should be possible. You might want to increase your stack size and make sure you are don't have a stack overflow condition.Article: 122992
Siva Velusamy wrote: >> >> However, the output shows that main() is starting again, despite there >> being no looping or recursive calls to induce this. (Some >> experimentation showed that moving the location of the sysace_fclose() >> calls changed the point at which main() restarted.) >> >> The problem disappears if I change both file accesses to read mode "r" >> (and the corresponding sysace_fwrite() calls to sysace_fread()). >> >> Is it simply not possible to read and write from different files >> within the same program? > > Should be possible. You might want to increase your stack size and make > sure you are don't have a stack overflow condition. Yes, you're right - I increased stack size to 0x1000 and the problem stopped. What techniques are there for detecting and dealing with stack overflows? PhilArticle: 122993
Hello everyone, I have encountered a rather strange behavior in one of my FPGA Designs. i have a DDR2 RAM controller (generated partly with the Memory Interface Generator) in a Xilinx Virtex-4 FX60. After startup it sends out some dummy patterns and reads them back to adjust the delay between issuing a command to the RAM and the execution. When I don't probe exactly these signals in the FPGA with Chipscope then this procedure is only executed sporadically, i.e. most times after configuration or a global reset the RAM controller never finishes its init-procedure (even when using an identical bit-file the success of the initialization can differ when configuring the FPGA another time). When I do use Chipscope however, it is executed everytime, so the use of it definitely influences the design. So the question is now, what could be the reason for it? Could it be a placement issue of the IODELAY elements used for the interface to the RAM or any other FPGA primitives that interface to it? If anyone had any guesses or ideas what could be the main influence I'd be happy to hear them, as I obviously would like to have the design running stably without needing Chipscope included. Cheers, MichaelArticle: 122994
Andrew Burnside wrote: > Certainly Xilinx has DDR 1/2 controllers available that plug onto > their micro cores. I can not find them, are you sure? > This would be less error prone than hacking around with a MIG design, > unless producing a controller is the main part of your academic > project. > > Can you tell us any more details about your applciation? DDR1/2 is not the main part of this project. In my project I want to be able to read two data word (64bits each) form one place in memory and two words from oder place. And similarly at writing. Also with DDR I can use burst 2. Actually a word has 48 bits but I can sacrifice 1/4 of memory to make it easier. And I can use only Spartan3 or Cyclone2 because in oder case using DDR will be not profitable. PGWArticle: 122995
Hi, I would like to know if anyone has experience with connecting an external CDR or CPA to a Virtex RocketIO MGT. I am using the Virtex-II Pro MGTs in an optical CDMA application where the receiver does not have the luxury of a constant flow of data. In this application, the data arrives in irregular bursts and the rest of the time there is no signal. The CDR built into the MGTs does not achieve lock quickly enough to capture the data in each burst, so I am planning to use an external clock phase aligner (CPA) such as the MAX3634 to produce the recovered data clock. The RocketIO Transceiver User Guide (UG024) mentions on page 109 that the MGT CDR can "accept an external precision clock, REFCLK, which either acts to clock incoming data or to assist in synchronizing the derived RXRECCLK". This suggests to me that I could simply connect the clock signal generated by the CPA as a reference clock and it could be used to sample the incoming data. My problem is, I can't find any information on how to select an external clock as a sampling clock for the incoming data. There does not seem to be much information on the built-in CDR, what parameters it has or how to change them. I would very much appreciate some advice on this matter. Thank you. JeffArticle: 122996
Peter, Austin Many thanks for your replys. I was just curious :) Kind RegardsArticle: 122997
Peter Alfke <alfke@sbcglobal.net> writes: > Eric, nobody wanted to prevent or sabotage this. I was being (mostly) facetious, as might have been indicated by the reference to the "B Ark" from Hitchhiker's Guide to the Galaxy. I certainly appreciate your efforts at resolving these sorts of problems. However, it is still annoying that there's no longer a way to easily buy parts in small quantities for prototyping, e.g., XC3S200A-4FTG256CES: Avnet: no stock, minimum order quantity 17 NuHorizons: in stock, "call for information" (not orderable online) That was just one part I've tried to get recently, but the situation for many other Spartan 3E, 3A, and 3AN parts is the same. Somehow other semiconductor vendors manage to do a better job of this. For example, I generally don't have any trouble getting small quantities of TI parts, even for the more obscure, specialized, or recently introduced parts. The Xilinx Online Store appeared to be an attempt at solving this problem. It was not 100% successful (parts were often out of stock), but it was better than the current situation. If it's not possible to bring back the online store, perhaps Xilinx could work more closely with Digikey to get them to stock recent parts (e.g., Spartan 3E, 3A, 3AN series). Unlike Avent and NuHorizons, Digikey and Mouser don't mind dealing with small orders. Thanks, EricArticle: 122998
I have a design where I use a 40MHz input clock to create a 40MHz, 80MHz, and two variable-frequency output clocks. The variable- frequencies are 80/120, 40/60, 20/30, 10/15, 5/7.5, and 2.5/3.75 respectively. The major design utilization is as follows: 9 BUFGMUX_VIRTEX4, 2 BUFG, 1 DCM_ADV, 3 PMCD. When attempting to integrate this clock generation block into our existing design, I receive a warning #438 during routing. I found Xilinx answer record 23873, which seems to be a problem similar to what I'm seeing. I'm just somewhat wary of the proposed solution, which is using 4 BUFGMUX's as 2:1 clock muxes and then a final 4:1 output mux based on regular logic. Has anyone else had this problem, and, if so, was this proposed fix used to solve it?Article: 122999
Mike Treseler wrote: > Andreas Schwarz wrote: > >> Has anyone found a workaround to use fixed_pkg with ISE? > > I haven't even tried since the > author of the package reported: > > "After fixing everything, it gave me the error: > > INTERNAL_ERROR:Xst:cmain.c:3111:1.8.6.1 - To resolve this error, please > consult the Answers Database and other online resources at > http://support.xilinx.com > > This is a "use at your own risk" one I guess. I would > recommend Synplicity, which seems to work much better." I am the author. Xilinx said that they were going to fix this in 9.3. I have not had a chance to check it out yet, but I would try that first.
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