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
Direct Digital Synthesis (a.k.a. phase accumulator) can generate the desired average frequency, but at excesive and unacceptable jitter. Assume a 500 MHz accumulator clock: It will generate more than 1 ns of jitter. Let's look at the desired frequency shift in the time domain, 1 MHz = 1 microsecond = 1,000,000 picoseconds 1 MHz - 5 Hz = 1,000,005 picoseconds. That means, the clock period of 1 microsecond must be nudged gently in steps that are much smaller than 5 picoseconds.So we are talking femtoseconds here. I do not see how this can be done with purely digital means. I could imagine a 5 Hz linear ramp added to the 1 MHz clock, so that the input threshold moves the frequency in the desired way, but you are still facing random noise and unavoidable jitter. I think our analog friend are better at this. They play with modulators and crystal filters, and are more comfortable in the frequency domain. Digital circuits work inherently in the time domain. There may even be a mechanical solution (something spinning at 5 Hz)... Maybe someone else has more constructive thoughts. Peter AlfkeArticle: 94851
Direct Digital Synthesis (a.k.a. phase accumulator) can generate the desired average frequency, but at excesive and unacceptable jitter. Assume a 500 MHz accumulator clock: It will generate more than 1 ns of jitter. Let's look at the desired frequency shift in the time domain, 1 MHz = 1 microsecond = 1,000,000 picoseconds 1 MHz - 5 Hz = 1,000,005 picoseconds. That means, the clock period of 1 microsecond must be nudged gently in steps that are much smaller than 5 picoseconds.So we are talking femtoseconds here. I do not see how this can be done with purely digital means. I could imagine a 5 Hz linear ramp added to the 1 MHz clock, so that the input threshold moves the frequency in the desired way, but you are still facing random noise and unavoidable jitter. I think our analog friend are better at this. They play with modulators and crystal filters, and are more comfortable in the frequency domain. Digital circuits work inherently in the time domain. There may even be a mechanical solution (something spinning at 5 Hz)... Maybe someone else has more constructive thoughts. Peter AlfkeArticle: 94852
I think Xilinx's stand is if you sell a core that targets a Xilinx FPGA or CPLD fabric they don't care. Xilinx is in the business of selling parts not microblaze or Picoblaze IP. And since without major modification the Microblaze and Picoblaze are a Xilinx only core, you have nothing to worry about. EricArticle: 94853
Antti, Do you know about the speedprint utility? I don't know if it's part of WebPack but it certainly is part of the mainstream tools. On my unix platform, all I need is a "speedprint xc3s50" and I get the results for the faster speed grade device. I can select a -4 speed grade with the -s switch adding -s4 to the command line: "speedprint -s4 xc3s50" (if there is a -4 in this Spartan3 size). I like being able to get the piece-parts to some of my "best case" timing values on critical logic without running through a full compile. I can look at different implementations (carry chain? MUXF5?) for critical logic without too much confusion. At first glance the value names may be a little confusing but there are ways to get some description on what they mean. - John_H "Antti Lukats" <antti@openchip.org> wrote in message news:dqkscg$7jo$03$1@news.t-online.com... > "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com> > schrieb im Newsbeitrag > news:1137548042.068052.289380@g44g2000cwa.googlegroups.com... >> >> Antti Lukats wrote: >>> Hi >>> >>> I wonder if anyone (Xilinx?) has actual information on Spartan3e fabric >>> speeds? >> >> Over a broad range of applications, a Spartan-3E FPGA is _in general_ >> the same performance or mildly faster than a Spartan-3 FPGA using the >> slowest speed grade for both. These tests were done using worst-case >> speed file numbers, which are more pessimistic than actual silicon. >> >> Hopefully, this shouldn't be too surprising as Spartan-3 and Spartan-3E >> FPGA are built on the same 90 nm process technology using the same >> manufacturing facility. >> >>> I have done some actual measurements and as far of the results the >>> LUT propagation delay seems to be about 10% bigger than in S3? >> >> I would expect some variation comparing actual silicon on two different >> devices. The data sheet tells you the slowest silicon we're allowed to >> ship, but the actual device likely is faster, especially at room >> temperature and nominal voltage. >> >> That said, if you compare the Tilo specification for the Spartan-3 and >> Spartan-3E families in their respective data sheets, you will see about >> 150 ps of delay difference. >> >> Spartan-3: Tilo on a -4 device = 0.61 ns >> http://www.xilinx.com/bvdocs/publications/ds099.pdf [Page 79] >> >> Spartan-3E: Tilo on a -4 device = 0.76 ns >> http://www.xilinx.com/bvdocs/publications/ds312.pdf [Page 133] >> >> I wouldn't focus on a specific parameter per se, as your path delay >> will include other timing parameters as well. For example, Spartan-3E >> generally has faster flip-flop clock-to-output delays and faster >> interconnect. In the wash, Spartan-3E _generally_ is at or about the >> same performance. >> --------------------------------- >> Steven K. Knapp >> Applications Manager, Xilinx Inc. >> General Products Division >> Spartan-3/-3E FPGAs >> http://www.xilinx.com/spartan3e >> --------------------------------- >> The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs. >> > > Hi Steve, > > it was really my fault - I have downloaded DS312.PDF zillion times and > this > time when I was now looking for timing data I happened to open DS312.PDF > dated May 2005 so in that outdated version there was no timing data. > > my measurements includes delay of 2 LUT, eg 2x Tilo + 2x interconnect > within the same switchbox (no routing only switchbox), the result of that > measurement indicated the Tilo increase exactly to the amount as as it > is stated in the datasheet. Actually a little less, so the interconnect > (swithcbox) > may really be a little faster. > > would I have had the latest datasheet open when looking at timing data > I would not have been surprised, my mistake, in the feature I will try > to use only fresh Xilinx datasheets to avoid using outdated versions. > > -- > Antti Lukats > http://www.xilant.com > > > > > > > > > >Article: 94854
I've looked into doing this several times but never found a working solution. I ended up creating my own HDL for the memory that instantiates BRAM primitives and wrote a corresponding bmm file as decribed in the documentation. That's worked fine even if it is a little more hassle. Paul langwadt@ieee.org wrote: > > Hi, > > Does anyone have a hint on how to get data2bram and coregen memory to > work together? > > I have an SoC with some 32bit memory made up of four 8bit memories > generated with coregen, I've made a bmm file that defines the memory. > I can run data2bram with the bmm file and an .elf file and if I set the > output to verilog the init strings look resonable. > If I run the same bmm and .elf file on my bit file and use the updated > bit file to configure an FPGA DONE doesn't go high so I assume the bit > file is corrupt. > > Is there a trick I should know about ? > > data2bram does give me a warning the the memory is not LOC'ed, is there > a simple way to > get that info when the memory is generated with coregen? > > (xc2v3000 and ISE5.1) > > -LasseArticle: 94855
Phil Tomson wrote: > Where can one find more info on NCD and XDL file formats (and what the > acronymns stand for)? Are you implying that if one has this NCD file that one > can figure out the bitstream format? If I recall correctly, the NCD format came from Neocad, a company whose P&R tools were better than Xilinx' own. So Xilinx bought 'em. This was back when the XC3000s were the bleeding edge. -aArticle: 94856
Eric, Correct. We want you to sell lots of silicon (that we provide). That is why many (most, almost all) of the Xilinx IP has a 'license once, use as much as you like in a product' agreement. There are some fine points: (d) “Licensed Project” means a project using the Licensed Materials to create (i) a single bitstream (using one or more instances of the Licensed Materials) for use in one or more printed circuit boards; or (ii) one or more bitstreams (using one or more instances of the Licensed Materials) for use in a single printed circuit board. Derivative or follow-on projects, with the exception of bug fixes to remedy errors in Licensed Products, are not part of the Licensed Project as defined herein. So, we do like to see some revenue from you using the core again in another pcb or project...seems fair? All of the details: http://www.xilinx.com/ipcenter/signonce.htm Austin Eric wrote: > I think Xilinx's stand is if you sell a core that targets a Xilinx FPGA > or CPLD fabric they don't care. > > Xilinx is in the business of selling parts not microblaze or Picoblaze > IP. > > And since without major modification the Microblaze and Picoblaze are a > Xilinx only core, you have nothing to worry about. > > Eric >Article: 94857
I used xilmfs once...
Did you use the mfsgen utility to make your file system? If so you
probably need to use mfs_init_genimage instead of mfs_init_fs.
Essentially they vary by adjusting some pointer a byte or two (or four
or whatever). I used mfsgen and then downloaded like you mentioned and
then did this in my main:
/* Set up the file system and cd to correct dir */
mfs_init_genimage(53200, (char *) MFS_BASE_ADDRESS, MFS_INIT_TYPE);
xilmfs_result = mfs_change_dir("my_fs");
xilmfs_result = mfs_get_current_dir_name(dirname);
if(xilmfs_result == 0) {
printf("Couldn't get current_dir_name.\r\n");
printf("Exiting...\n");
exit(1);
}
I don't recall if the 53200 is the value I got directly from mfsgen or
not... maybe have to adjust it a little? Like it could have been 53204
or something (again with the pointer adjustment). Sorry if I am a
little vague, it was a while ago that I set this up. The moral of this
story is try mfs_init_genimage.
Joey
Article: 94858<newsmailcomp5@gustad.com> schrieb im Newsbeitrag news:kjuwtgxefpt.fsf@shardlow.dolphinics.no... > "Antti Lukats" <antti@openchip.org> writes: > >> you can connect Cable III to the JTAG and use impact, or I could > > Can you play SVF files with impact? How? > yes you can play SVF files with impact, just add them :) anttiArticle: 94859
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:__uzf.1084$wk5.575@news02.roc.ny... > Antti, > > Do you know about the speedprint utility? I don't know if it's part of > WebPack but it certainly is part of the mainstream tools. On my unix > platform, all I need is a "speedprint xc3s50" and I get the results for > the faster speed grade device. I can select a -4 speed grade with the -s > switch adding -s4 to the command line: "speedprint -s4 xc3s50" (if there > is a -4 in this Spartan3 size). > > I like being able to get the piece-parts to some of my "best case" timing > values on critical logic without running through a full compile. I can > look at different implementations (carry chain? MUXF5?) for critical > logic without too much confusion. At first glance the value names may be > a little confusing but there are ways to get some description on what they > mean. > > - John_H Hi John I dont trust any speed reports 100% so I am actually measuring actual silicon and comparing the measurements. Sure for academic comparison I could use timing report values too anttiArticle: 94860
Very clever. Let's see if I get it. Delay first access till required_wait_time is met. Then read as fast as possible untill burst length is completed. Repeat till done. I need to look at last address accessed and apply rules for burst transferrs. Thanks GeorgeArticle: 94861
Hi all, I tried to find the information in Xilinx documentation and Internet with no luck. I come here as my last resort. My design fails to meet all constraints, and throws the following message: "WARNING:Route - CLK Net:dsp_clk_a_IBUFG may have excessive skew because 685 CLK pins and 1 NON_CLK pins failed to route using a CLK template." As far as I am concerned, this can be due to the clock signal (dsp_clk_a) feeding a non-clk input. The problem is that I cannot find the non-clk element. The only one I can figure out is a BUFGMUX with 2 inputs: dsp_clk_a and GND, and it's output to an output PAD of the FPGA. This BUFGMUX is supposed to export a clock signal only when desired, leaving the clock inactive when not. Can anyone tell me if this BUFGMUX can be the problem, or how can I find the non-clk element? Thanks a lot. JL.Article: 94862
JL, The BUFGMUX is what's causing the warning. Try using the double data rate (DDR) registers in the IOBs to send the clock out instead. D0 <= '1', D1 <= '0', C0 <= clk, C1 <= not(clk) Disable it with the clock enable. FDDRCPE. Or, easier still, ignore the warning! HTH, Syms.Article: 94863
In case it helps anyone, you can get the list of pins driven by a net just selecting the net and clicking Edit->Properties of Selected Items. You can even view the delay from the net to each pin. Now my problem is that I only find 2 non-clk nets: C15.I, reported as an "output", which is the driver pin where dsp_clk_a comes from, and BUFGMUX3P.I0 which is the clock that I export to an output pad of the Virtex-2. I don't see why ISE complains about a non-clk net, can anyone explain me if I'm using BUFGMUX in a wrong way? Thanks. JL.Article: 94864
Hi Peter, John and all others ! Thanks a lot for your answers! In analog technics, I already thought of using a VCTCXO with the desired amount of frequency variation, driven by a DAC ! But if there are other pure digital methods: please keep on posting them ! Thanks, bye BEN Peter Alfke wrote: > Direct Digital Synthesis (a.k.a. phase accumulator) can generate the > desired average frequency, but at excesive and unacceptable jitter. > Assume a 500 MHz accumulator clock: It will generate more than 1 ns of > jitter. > > Let's look at the desired frequency shift in the time domain, > 1 MHz = 1 microsecond = 1,000,000 picoseconds > 1 MHz - 5 Hz = 1,000,005 picoseconds. > > That means, the clock period of 1 microsecond must be nudged gently in > steps that are much smaller than 5 picoseconds.So we are talking > femtoseconds here. > I do not see how this can be done with purely digital means. > > I could imagine a 5 Hz linear ramp added to the 1 MHz clock, so that > the input threshold moves the frequency in the desired way, but you are > still facing random noise and unavoidable jitter. > I think our analog friend are better at this. They play with modulators > and crystal filters, and are more comfortable in the frequency domain. > Digital circuits work inherently in the time domain. > There may even be a mechanical solution (something spinning at 5 Hz)... > Maybe someone else has more constructive thoughts. > > Peter Alfke >Article: 94865
In article <uzmltkjm9.fsf@trw.com>, Martin Thompson <martin.j.thompson@trw.com> wrote: >ptkwt@aracnet.com (Phil Tomson) writes: > >> >> Where can one find more info on NCD and XDL file formats (and what the >> acronymns stand for)? Are you implying that if one has this NCD file that one >> can figure out the bitstream format? >> >> Phil > > >As I understand it, the XDL is a textual representation of NCD. The >NCD is the native circuit database, which has pretty much everything >required to make a bitstream (logic, placement, routing, startup >values, BRAM contents etc). If you run "xdl -ncd2xdl" you can get the >XDL equivalent, hack it about and then regenerate the NCD from the XDL >and from there go to a bitstream... You can also get a list of all >the resources in the device using the -report mode of "xdl". > >Presumably you could create various small designs in XDL, NCD them and >then convert to bitstreams and by diffing the bitstream figure out >what was going on. In theory you could also automoate this... > So xdl come with the webpack? PhilArticle: 94866
In article <slrndssicn.8hn.ehliar-nospam@sabor.isy.liu.se>, Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: >I just installed ISE 8.1 on Linux and these are my first >impressions: > >* Project Navigator finally feels like a native Linux > program. Previous versions often felt unresponsive and > slow. With this version I no longer feel an immediate > urge to build everything with Makefiles. This is great! > >* Impact does not work out of the box with kernel > version 2.6.15.1. I had to download linuxdrivers2.6.tar.gz > and compile it. Furthermore, I had to edit the configure > script in windrvr and make sure that UDEV was not used. > (The udev interface seems to have changed in later 2.6.x > series. The relevant symbols are also GPL-only now, so I don't > think a binary only module can be distributed using UDEV in later > 2.6.x kernels.) > I also had to install fxload to download the firmware to the > programming cable and make sure /proc/bus/usb was mounted. > > All in all, I got it to work, but I really wish that Xilinx > could remove the dependence on windriver. It is a real nuisance > if you have to upgrade your kernel for whatever reason since you > will need to recompile the kernel module in that case. If you > happen to use parallel cable III or IV you can use XC3Sprog instead. > You have to modify the program somewhat if you want to use it with > Virtex-II FPGA:s. (You have to make sure that it recognizes the FPGA.) > I haven't tested V2P or V4 FPGA:s with it though. > > >* Test benches seem to be handled much more sanely in Project > Navigator. You can now for each source file decide if it should > be used for simulation, synthesis or both. > Thanks for the info. what Linux distro are you running? The drivers you referred to: linuxdrivers2.6.tar.gz was that something you had to download from Xilinx's site? PhilArticle: 94867
Thanks Syms, it actually helped. This warning could not be ignored because it led my dsp_clk_a clock signal to be implemented as a local net, instead of a dedicated clock net. This induced a huge skew in the circuit. Now it works as expected (well, with other errors not related to this one...) :) Thanks again. JL.Article: 94868
No, BUFGMUX is the component to the clock "enter" a global clock distribution line. Do you feed any output pin?Article: 94869
Phil Tomson wrote: > It looks like JBits is a University-developed tool. why wouldn't the source > code be available? If it really was developed at a university, the university probably signed an NDA with Xilinx to get the bitstream details.Article: 94870
Steve Knapp wrote: > It also > demonstrates that a Spartan-3E FPGA can configure from standard > commodity parallel NOR Flash. Furthermore, it demonstrates the > Spartan-3E FPGA's MutliBoot feature, which allows you to dynamically > switch between two different configuration images stored in Flash. Does the multiboot feature work with serial flash memory, or only with parallel? I want to have a protected configuration image in case a user-initiated update fails, so the user can switch a jumper to get the write-protected image. For a serial flash, I thought I would have to add a CPLD to modify one bit of the address from the FPGA to the serial flash. EricArticle: 94871
"Eric Smith" <eric@brouhaha.com> schrieb im Newsbeitrag news:qhk6cxi95v.fsf_-_@ruckus.brouhaha.com... > Steve Knapp wrote: >> It also >> demonstrates that a Spartan-3E FPGA can configure from standard >> commodity parallel NOR Flash. Furthermore, it demonstrates the >> Spartan-3E FPGA's MutliBoot feature, which allows you to dynamically >> switch between two different configuration images stored in Flash. > > Does the multiboot feature work with serial flash memory, or only > with parallel? > > I want to have a protected configuration image in case a user-initiated > update fails, so the user can switch a jumper to get the write-protected > image. For a serial flash, I thought I would have to add a CPLD to > modify one bit of the address from the FPGA to the serial flash. > > Eric the multi boot is only for parallel flash AnttiArticle: 94872
JBits, Is a Xilinx invention, developed here. Austin Eric Smith wrote: > Phil Tomson wrote: > >>It looks like JBits is a University-developed tool. why wouldn't the source >>code be available? > > > If it really was developed at a university, the university probably signed > an NDA with Xilinx to get the bitstream details.Article: 94873
Austin Lesea wrote: > Eric, > > Correct. We want you to sell lots of silicon (that we provide). That > is why many (most, almost all) of the Xilinx IP has a 'license once, use > as much as you like in a product' agreement. To clarify this "“Licensed Products” means any integrated circuits manufactured by Xilinx that are programmed with a bitstream generated by use of the Licensed Materials." > > There are some fine points: [ This is the Project license, the site license agreement differs ] > > (d) “Licensed Project” means a project using the Licensed Materials to > create (i) a single bitstream (using one or more instances of the > Licensed Materials) for use in one or more printed circuit boards; or > (ii) one or more bitstreams (using one or more instances of the > Licensed Materials) for use in a single printed circuit board. > Derivative or follow-on projects, with the exception of bug fixes to > remedy errors in Licensed Products, are not part of the Licensed Project > as defined herein. > > So, we do like to see some revenue from you using the core again in > another pcb or project...seems fair? Yes, but that is not quite what the legalese actually says: Any significant revisions of either PCB or Software seem to be excluded. Indeed, even bug fixes are only allowed on the Xilinx flows, not to the users designs!! In fact, given that "Licensed Products" does _not_ include Xilinx SW, this seems to say the ONLY exception is Silicon related bug fixes! Under this wording, Xilinx can legally charge you again for SW bug fixes. Seems that even Version improvements are also excluded ? Now, one hopes Xilinx does what Austin says, and not what the agreement states, but some legal depts might worry about that. Of course, Xilinx could rewrite that poor wording..... -jgArticle: 94874
We have the Raggedstone1 board running with the pci32_lite core from opencores.org. (Only a few minor changes were necessary). I've written a simple linux driver along with a small user-space test program that can write hex numbers to the 7seg display. I've started a webpage for it here: http://projects.varxec.net/doku.php/raggedstone1 Regards, Manuel
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