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
Are you transferring data between related time domains either with or without a DCM? Your FPGA and software version could have a slight impact on results. "Thomas Reinemann" <tom.reinemann@gmx.net> wrote in message news:1163529222.557776.216940@k70g2000cwa.googlegroups.com... Hi, we are running in trouble with our curent design for a Xilinx Spartan 3 xc3s1500. It does signal processing and it seems that sample got lost with increasing temperature. Immediately after power on all works well, some minutes later, if final temperatures is reach, some samples are missed. I hadn't a thermometer ready, but I can always touch the FPGA for a long time, it may be 50°C. It runs with a clock of 76.8 MHz, PAR states a maximum frequency of 78.777MHz, and logic utilization is about 60%. One board works as expected and two other show the explained effect, the boards have the same layout but are made by different manufacturers. At least the not working are lead free. Just now, we had a discusion to the influence of temperature to propagation delay. I don't believe that it influences clock lines and other logic resources in a (big) different way. Is It true or not? I read the thread "Propagation delay sensitivity to temperature, voltage, and manufacturing", but the answers are very related to DCMs. TomArticle: 112001
uvbaz wrote:
> My question are:
> 1. I want to compile "fprint.vhd + fprint_body.vhd" in FPRINT, but it
> didn't. Why?
Until you learn modelsim,
compile everything into the default library "work".
> 2. "$XILINX/verilog/src/simprims/*.v" not recognized, why?
Maybe it is a verilog file and the
script is running vcom.
-- Mike Treseler
Article: 112002Xilinx has lost my account somehow so that I am unable to log on their web support page... so I thought I'd try it here... Which of the two should I use if I want to generate simple separate streaming tx only and rx only cores for V4FX? The RocketIO wizard allows for choosing silicon step level, while the Aurora core GUI seems to give more control over some other parameters... I've heard that the calibration block should be different for different stepping levels. If that's the case how can it be achieved with the Aurora core? Thanks, /MikhailArticle: 112003
Manny wrote: > It might be a naive question, however, I just want to make sure. Is > Xilinx new USB JTAG backward-compatible with old parallel port JTAG > development boards? I'm a bit suspicious as some of the newer Xilinx > boards say explicitly that the board is compatible with the USB JTAG. Perhaps you are referring to the Spartan 3E starter kit? In this case, in addition to the 6 pin JTAG header, it has a USB connector (and USB chip) on board so you can program it without having to buy *any* programming cable at all. Alan NishiokaArticle: 112004
fl wrote:
> I find there are a lot of warning (see below) in the
> first 25 ns. Is it normal?
They are common at time zero, but they can be eliminated.
Google is your friend.
> I rewrote the program in Xilinx previously
> using my own add subroutine. Although the sum was uncertain (in red) in
> the first 100 ns, there is no such warning. Are there something I can
> do in the ModelSimAltera to suppress these warning?
Add one or more of these the to
your .do script.
set NoVitalCheck 1;
set IgnoreVitalErrors 1;
set StdArithNoWarnings 1;
set NumericStdNoWarnings 1;
-- Mike Treseler
Article: 112005Thomas Try a rebuild with a tighter frequency. The tools will tend to just give you what you ask for, not anything much better. There are also some versions of ISE (i.e. the speed tables) that seem to be a bit marginal with designs if you are close to the limit like you are. On a similar vein check you have the latest version and service pack of ISE. Other things to watch when the unexpected happens are the power supplies and whether your clock source is stable. Ensure they don't dip or suffer significant noise (decoupling and power plane strategy) particularly if you are using a DCM. If using a DCM do have a good look at the Vccaux. John Adair Enterpoint Ltd. - Home of Darnaw1. Spartan-3E in PGA Format. Thomas Reinemann wrote: > Hi, > > we are running in trouble with our curent design for a Xilinx Spartan 3 > xc3s1500. > > It does signal processing and it seems that sample got lost with > increasing temperature. Immediately after power on all works well, some > minutes later, if final temperatures is reach, some samples are missed. > I hadn't a thermometer ready, but I can always touch the FPGA for a > long time, it may be 50=B0C. > It runs with a clock of 76.8 MHz, PAR states a maximum frequency of > 78.777MHz, and logic utilization is about 60%. > > One board works as expected and two other show the explained effect, > the boards have the same layout but are made by different > manufacturers. At least the not working are lead free. > > Just now, we had a discusion to the influence of temperature to > propagation delay. I don't believe that it influences clock lines and > other logic resources in a (big) different way. Is It true or not? > > I read the thread "Propagation delay sensitivity to temperature, > voltage, and manufacturing", but the answers are very related to DCMs. >=20 > TomArticle: 112006
Thomas, Comments below, Austin -snip- > I hadn't a thermometer ready, but I can always touch the FPGA for a > long time, it may be 50°C. How much slack does your timing report say it has? > It runs with a clock of 76.8 MHz, PAR states a maximum frequency of > 78.777MHz, and logic utilization is about 60%. I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz). That is pretty darned small. If you have 400 ps of jitter on your clock, you now have 327 - 1/2 (400) = 127 ps of slack ... If you have 800 ps of jitter, then you are failing (slack less than 0). If you have any paths that were not constrained properly, then 327 ps of slack is a fiction, you really may have paths that are failing to meet timing. > One board works as expected and two other show the explained effect, > the boards have the same layout but are made by different > manufacturers. At least the not working are lead free. Parts will vary: some will be faster than specified. none will be slower than specified. > Just now, we had a discusion to the influence of temperature to > propagation delay. I don't believe that it influences clock lines and > other logic resources in a (big) different way. Is It true or not? Temperature affects all delays. The resource affected may be different, and may be affected more, or less, but they will all slow down at hotter temperatures. > I read the thread "Propagation delay sensitivity to temperature, > voltage, and manufacturing", but the answers are very related to DCMs. DCM's vary, too. So does everything else. Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a rule of thumb, not anything we characterize or guarantee. You are just too close to the edge: go back and review your constraints (to see if they cover all the critical paths), and perhaps apply a smaller clock period as a timing specification.Article: 112007
Inline: Austin Lesea wrote: > Thomas, > > Comments below, > > Austin > > -snip- > >> I hadn't a thermometer ready, but I can always touch the FPGA for a >> long time, it may be 50°C. > > How much slack does your timing report say it has? > >> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of >> 78.777MHz, and logic utilization is about 60%. > > I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz). That > is pretty darned small. If you have 400 ps of jitter on your clock, you > now have 327 - 1/2 (400) = 127 ps of slack ... > > If you have 800 ps of jitter, then you are failing (slack less than 0). > > If you have any paths that were not constrained properly, then 327 ps of > slack is a fiction, you really may have paths that are failing to meet > timing. Now come, Austin. If the tool tells me I have positive margin (however small) I expect that to be true. I've done designs where I calculated the worst case and had a _guaranteed_ margin of 8 ps. Note the word guaranteed. I thought the post-PAR analysis tools gave me guaranteed timings. > >> One board works as expected and two other show the explained effect, >> the boards have the same layout but are made by different >> manufacturers. At least the not working are lead free. > > Parts will vary: some will be faster than specified. none will be > slower than specified. Lead free processes stress a part more than the non-lead free; there is also the issue that the joints may not have the same highspeed performance; your application is highspeed enough to be susceptible to soldering issues. However, I agree with Austin that your margin is sorta small. > >> Just now, we had a discusion to the influence of temperature to >> propagation delay. I don't believe that it influences clock lines and >> other logic resources in a (big) different way. Is It true or not? > > Temperature affects all delays. The resource affected may be different, > and may be affected more, or less, but they will all slow down at hotter > temperatures. > >> I read the thread "Propagation delay sensitivity to temperature, >> voltage, and manufacturing", but the answers are very related to DCMs. > > DCM's vary, too. So does everything else. > Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a > rule of thumb, not anything we characterize or guarantee. > > You are just too close to the edge: go back and review your constraints > (to see if they cover all the critical paths), and perhaps apply a > smaller clock period as a timing specification. I would also check to see if you are adding the signal rise/fall (which can get quite high for non-rocket IO pins) as temperatures increase. Cheers PeteSArticle: 112008
Hello all, I realized something interesting today, adding registers in your design can actually reduce the slice usage (in Virtex-II Pro). For example, I started a design with minimal pilelining to keep it simple at first. Before pipelining, I had the following usage: Slices: 2433 Flip Flops: 2287 LUT: 2981 (seems a bit high, might be a typo in my notebook) After pipelining, I get: Slices: 1973 Flip Flops: 2615 LUT: 2069 I knew from the begining that pipelining would be needed but I didn't realize that it could save me some slices (on top of the obvious max frequency increase). I might as well throw in a question while I'm at it. Now I need to pipeline further (need to go from 78 MHz to 100 MHz) but it gets more complicated, I would need to pipeline the function "to_signed (from float32)" from the VHDL-200X float_pkg. Any suggestions on how to do that? I read somewhere that one can add an extra level of registers, and let the tool figure out how to do the register retiming. I would use xst with the "register_balancing yes" flag, but I'm not sure how good xst is at register balancing. Thanks. Patrick DuboisArticle: 112009
At bottom: PeteS wrote: > Inline: > > Austin Lesea wrote: >> Thomas, >> >> Comments below, >> >> Austin >> >> -snip- >> >>> I hadn't a thermometer ready, but I can always touch the FPGA for a >>> long time, it may be 50°C. >> >> How much slack does your timing report say it has? >> >>> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of >>> 78.777MHz, and logic utilization is about 60%. >> >> I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz). That >> is pretty darned small. If you have 400 ps of jitter on your clock, you >> now have 327 - 1/2 (400) = 127 ps of slack ... >> >> If you have 800 ps of jitter, then you are failing (slack less than 0). >> >> If you have any paths that were not constrained properly, then 327 ps of >> slack is a fiction, you really may have paths that are failing to meet >> timing. > > Now come, Austin. If the tool tells me I have positive margin (however > small) I expect that to be true. I've done designs where I calculated > the worst case and had a _guaranteed_ margin of 8 ps. Note the word > guaranteed. I thought the post-PAR analysis tools gave me guaranteed > timings. > > >> >>> One board works as expected and two other show the explained effect, >>> the boards have the same layout but are made by different >>> manufacturers. At least the not working are lead free. >> >> Parts will vary: some will be faster than specified. none will be >> slower than specified. > > Lead free processes stress a part more than the non-lead free; there is > also the issue that the joints may not have the same highspeed > performance; your application is highspeed enough to be susceptible to > soldering issues. However, I agree with Austin that your margin is sorta > small. > > >> >>> Just now, we had a discusion to the influence of temperature to >>> propagation delay. I don't believe that it influences clock lines and >>> other logic resources in a (big) different way. Is It true or not? >> >> Temperature affects all delays. The resource affected may be different, >> and may be affected more, or less, but they will all slow down at hotter >> temperatures. >> >>> I read the thread "Propagation delay sensitivity to temperature, >>> voltage, and manufacturing", but the answers are very related to DCMs. >> >> DCM's vary, too. So does everything else. >> Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a >> rule of thumb, not anything we characterize or guarantee. >> >> You are just too close to the edge: go back and review your constraints >> (to see if they cover all the critical paths), and perhaps apply a >> smaller clock period as a timing specification. > > I would also check to see if you are adding the signal rise/fall (which > can get quite high for non-rocket IO pins) as temperatures increase. > > Cheers > > PeteS You are obviously clocking things from somewhere. A margin of 300 ps or so can get lost in the rise/fall times of a hot clock source. Have you characterised your clock inputs properly for post-PAR analysis? Cheers PeteSArticle: 112010
PeteS, See below, Austin -snip- > Now come, Austin. If the tool tells me I have positive margin (however > small) I expect that to be true. I've done designs where I calculated > the worst case and had a _guaranteed_ margin of 8 ps. Note the word > guaranteed. I thought the post-PAR analysis tools gave me guaranteed > timings. Sure. For whatever you constrained. Did everything get constrained properly? This is not a trivial task: verifying timing closure may sometimes take up huge amounts of time (to verify every critical path has sufficient slack, and was properly constrained). And 8ps of margin means that if you have 16 ps P-P of jitter, you have no slack left, and errors may occur if the jitter increases by even one ps... But if you have a clock with 400 ps P-P of jitter (not uncommon), and you have lots of IOs switching, and you have power supply variations, and so on, you might be at the edge, or over the edge. (Probably are...as was obvious in this case) > I agree with Austin that your margin is sorta > small. Yes, it is. I recommend having at least the peak to peak worst case measured jitter as margin (slack). That means you have a factor of two for safety. Considering peak to peak jitter is unbounded (14 sigma enough? 16 sigma? 20 sigma?), you really do not want to cut things too close (or you will eventually fail in some process/voltage/temperature/jitter 'corner'. > I would also check to see if you are adding the signal rise/fall (which > can get quite high for non-rocket IO pins) as temperatures increase. True, if the rise time is long, then you probably also have a lot of jitter (as a long slow rise time leads to imprecise transitions).Article: 112011
Inline Austin Lesea wrote: > PeteS, > > See below, > > Austin > > -snip- > > > Now come, Austin. If the tool tells me I have positive margin (however > >> small) I expect that to be true. I've done designs where I calculated >> the worst case and had a _guaranteed_ margin of 8 ps. Note the word >> guaranteed. I thought the post-PAR analysis tools gave me guaranteed >> timings. >> > Sure. For whatever you constrained. Did everything get constrained > properly? This is not a trivial task: No it isn't. I have spent days on end making sure I have considered everything involved. > verifying timing closure may > sometimes take up huge amounts of time (to verify every critical path > has sufficient slack, and was properly constrained). And 8ps of margin > means that if you have 16 ps P-P of jitter, you have no slack left, and > errors may occur if the jitter increases by even one ps... > > But if you have a clock with 400 ps P-P of jitter (not uncommon), and > you have lots of IOs switching, and you have power supply variations, > and so on, you might be at the edge, or over the edge. (Probably > are...as was obvious in this case) > > I am anal about my constraints. I've done really high speed stuff (10Gb/s) but even the marginal things (DDR above 200/400 comes to mind) will bite you if you haven't properly constrained the design. The last time I did that I even added the delays (and filter effect) of the bond wires from the pad to the die. Perhaps the OP is not so anal about it but needs to be. My design worked first time for that, for what it's worth. >> I agree with Austin that your margin is sorta >> small. >> > Yes, it is. I recommend having at least the peak to peak worst case > measured jitter as margin (slack). That means you have a factor of two > for safety. Considering peak to peak jitter is unbounded (14 sigma > enough? 16 sigma? 20 sigma?), you really do not want to cut things too > close (or you will eventually fail in some > process/voltage/temperature/jitter 'corner'. > > > Deterministic jitter will kill a design, but it's predictable (see my comments about being anal). PCB tracks can add enough jitter to swamp 300ps of margin, especially if there are vias involved. There are techniques to alleviate this, of course (maybe I should publish how I did it ;) One can not, however, eliminate it. >> I would also check to see if you are adding the signal rise/fall (which >> can get quite high for non-rocket IO pins) as temperatures increase. >> > True, if the rise time is long, then you probably also have a lot of > jitter (as a long slow rise time leads to imprecise transitions). > > > > That's my point. A FF will clock at some point in the active region. The indeterminacy of this region *must* be added to the error budget if you want guaranteed timing. Cheers PeteSArticle: 112012
> I belive that MPMC2 DDR2 works on "Xilinx provided boards" but the > question is how to make it to work on an "non Xilinx board?" > > I have several custom V4 boards with DDR2 and I have ML501, I assumed > that as MPMC2 generates UCF file that matches ML501 so first step would > be to get MPMC2 to work on ML501 and then derive a new design for the > custom board. I dont have ML410 or any other "xilinx supported board" > for testing. > > can you tell me why MPMC2 1.7 does not support V5? is it because > 1) it is not tested (but may work) ? > 2) IP core just want work for V-5 architecture > 3) IP core is ok for V-5 but want work on ML501 because of clock buffer > errata in ES silicon as described in EN049.PDF ? > > Are there any plans to make MPMC2 to support Virtex-5? If yes when can > we expect this? > > Getting MPMC2 to work on our custom V4 DDR2 boards is really urgent, so > any help is welcome. > > For now I will drop any MPMC2 testing on ML501 and try to modify some > MPMC2 archived project for our purpose, so far I did regenerate new > project (and that failed to workI) > Hi Antti - Unfortunately I do not have good answers for any of the above questions. I do know that the next release of MPMC2 will support V5. I do not know the schedules. /SivaArticle: 112013
"Jeff Cunningham" <jcc@sover.net> wrote in message news:455927fd$0$5782$4d3efbfe@news.sover.net... > Antti wrote: > > > > > PPC405 hard macro PLB DBUS *IS* 64 bits > > > > But according to the documentation, the native hard PLB interfaces on > the PPC core can be configured to operate in 32 bit mode, and they will > adapt themselves to just use 32 bits (i.e. you don't need any external > 64 to 32 bit mux). For instance, see the PLBC405DCUSSIZE1 parameter in > the Power PC 405 Processor Block Reference Guide. > > -Jeff At the EDK level it looks to be hardcoded to 64? Do you know how I would specify 32 and/or confirm that it is 32? Thanks, ClarkArticle: 112014
Thanks for throwing this back in after your "Now come, Austin" comment. The tools will report what the chip will *absolutely* support under worst case conditions as long as none of the input conditions for that specification are exceeded. Maximum acceptable jitter is specified in the data sheet but must also be considered *internal* to the device since a poor set of switching I/Os and/or improperly bypassed and distributed rails can affect the amount of jitter seen by the time it gets to the global clock routing. - John_H "PeteS" <peter.smith8380@ntlworld.com> wrote in message news:fXr6h.14160$yz3.6788@newsfe4-gui.ntli.net... > At bottom: > > PeteS wrote: >> Inline: >> >> Austin Lesea wrote: >>> Thomas, >>> >>> Comments below, >>> >>> Austin >>> >>> -snip- >>> >>>> I hadn't a thermometer ready, but I can always touch the FPGA for a >>>> long time, it may be 50°C. >>> >>> How much slack does your timing report say it has? >>> >>>> It runs with a clock of 76.8 MHz, PAR states a maximum frequency of >>>> 78.777MHz, and logic utilization is about 60%. >>> >>> I can infer that the slack is 327 ps (1/78.777 MHz - 1/76.8 MHz). That >>> is pretty darned small. If you have 400 ps of jitter on your clock, you >>> now have 327 - 1/2 (400) = 127 ps of slack ... >>> >>> If you have 800 ps of jitter, then you are failing (slack less than 0). >>> >>> If you have any paths that were not constrained properly, then 327 ps of >>> slack is a fiction, you really may have paths that are failing to meet >>> timing. >> >> Now come, Austin. If the tool tells me I have positive margin (however >> small) I expect that to be true. I've done designs where I calculated the >> worst case and had a _guaranteed_ margin of 8 ps. Note the word >> guaranteed. I thought the post-PAR analysis tools gave me guaranteed >> timings. >> >> >>> >>>> One board works as expected and two other show the explained effect, >>>> the boards have the same layout but are made by different >>>> manufacturers. At least the not working are lead free. >>> >>> Parts will vary: some will be faster than specified. none will be >>> slower than specified. >> >> Lead free processes stress a part more than the non-lead free; there is >> also the issue that the joints may not have the same highspeed >> performance; your application is highspeed enough to be susceptible to >> soldering issues. However, I agree with Austin that your margin is sorta >> small. >> >> >>> >>>> Just now, we had a discusion to the influence of temperature to >>>> propagation delay. I don't believe that it influences clock lines and >>>> other logic resources in a (big) different way. Is It true or not? >>> >>> Temperature affects all delays. The resource affected may be different, >>> and may be affected more, or less, but they will all slow down at hotter >>> temperatures. >>> >>>> I read the thread "Propagation delay sensitivity to temperature, >>>> voltage, and manufacturing", but the answers are very related to DCMs. >>> >>> DCM's vary, too. So does everything else. >>> Peter has a rule of thumb, or 0.3% per degree C slowdown, but it is a >>> rule of thumb, not anything we characterize or guarantee. >>> >>> You are just too close to the edge: go back and review your constraints >>> (to see if they cover all the critical paths), and perhaps apply a >>> smaller clock period as a timing specification. >> >> I would also check to see if you are adding the signal rise/fall (which >> can get quite high for non-rocket IO pins) as temperatures increase. >> >> Cheers >> >> PeteS > > You are obviously clocking things from somewhere. A margin of 300 ps or so > can get lost in the rise/fall times of a hot clock source. Have you > characterised your clock inputs properly for post-PAR analysis? > > Cheers > > PeteSArticle: 112015
I noticed that the PPC405 in the V4s has a MAC instruction. Does anyone know if there are optimized filter or fft routines to take advantage of this? I do my signal procesing in the FPGA but it would be nice to be able to do some simple procesing with the core. Thanks, ClarkArticle: 112016
PeteS wrote: > Now come, Austin. If the tool tells me I have positive margin (however > small) I expect that to be true. I've done designs where I calculated > the worst case and had a _guaranteed_ margin of 8 ps. Note the word > guaranteed. I thought the post-PAR analysis tools gave me guaranteed > timings. As far as I am aware, unless you punch it in, the tools won't take account of your input clock jitter, which can get quite large - I think that was the point? The tools have to make some assumptions somewhere - they don't have the information :) JeremyArticle: 112017
Hi, I try to build a simple program to run on PowerPC, which is HelloWork. When I compile, the error is: make: gcc: Command not found make: *** [PortLinux1/HelloWorld] Error 127 I checked the environment variables, which are XILINX_EDK, and Path. Everything is ok. I also did try to set a variable GNU_TOOLS to the gnu, but it still not work. Please tell me how to set variable to run the compile. Thanks, Thang NguyenArticle: 112018
Hi, I try to build a simple program to run on PowerPC, which is HelloWorld. When I compile, the error is: make: gcc: Command not found make: *** [PortLinux1/HelloWorld] Error 127 I checked the environment variables, which are XILINX_EDK, and Path. Everything is ok. I also did try to set a variable GNU_TOOLS to the gnu, but it still not work. Please tell me how to set variable to run the compile. Thanks, Thang NguyenArticle: 112019
uvbaz wrote: > > 2. "$XILINX/verilog/src/simprims/*.v" not recognized, why? >From what you wrote, it appears that you are using an input script file, and running the tool with the -f option to feed it in. I notice that you have //comments in your script file. I suspect that the /* in your pathname is being interpreted as a start of a block comment in the script file. This would mean that the path stops at simprims, followed by the start of a block comment /*.v. So you are trying to compile simprims, which is a directory. Note that the path printed by your error message ends at simprims. There is probably some way to escape the * character to prevent this from happening, but I don't know what it is.Article: 112020
uvbaz wrote: > I've write a script for this, but with no control statement. How can i > control the running flow, namely: > > if (NCVLOG ERROR) then ERROR REPORT and STOP THE RUNNING.... ncvlog and ncelab return an exit status, like many executables under UNIX. I don't know about the other tools you mentioned. With csh, you can test this with something like ncvlog -f ncvlog.args if ($status != 0) then echo "ncvlog failed" exit endif Other UNIX shells may use different mechanisms, but they should all provide access to the exit status.Article: 112021
Maybe you need a SATA connection to get a ultra high speed link. The IP Core for that is called Aurora. You can get a reference design from http://www.xilinx.com/univ/xupv2p.html On Nov 14, 9:22 pm, "nana" <nmic...@utk.edu> wrote: > Helllo, > Does anyone know about transfering data between two xupv2p boards, that > is from one board to another? > I appreciate your help > > nmichouArticle: 112022
PeteS wrote: > Now come, Austin. If the tool tells me I have positive margin (however > small) I expect that to be true. I've done designs where I calculated > the worst case and had a _guaranteed_ margin of 8 ps. Note the word > guaranteed. I thought the post-PAR analysis tools gave me guaranteed > timings. > > That is true provided you have a jitter-free clock. The tools do not know, nor can they predict how much jitter is on your clock. You need to consider a jitter margin in your clock constraints, as any jitter erodes the minimum clock period. Keep in mind that you not only have the jitter introduced by the DCMs if you use them, but also jitter inherent in your clock source plus jitter added by noise on the board and more importantly by modulation of the VCC-IOs of the clock pins by other pins switching on the bank or by fluctuations in the power rails. If you subtract your cycle-to-cycle max jitter from the clock constraint, then you wind up with guaranteed operation. In a lab environment, you can usually get away with ignoring the jitter, as you usually won't be anywhere near the slow corner of voltage, process and temperature. In the field though, not allowing for sufficient jitter tolerance is likely to come back and bite you hard in the shorts.Article: 112023
Hi, I am new in this area and would be happy to have some feedbacks. Does anyone have a clear cut answer as to what really low level programming model in image processing is? I have found different definitions and getting confused. My other question is, why does FPGA is said to have major disadvantage in modelling at low level? Thank you.Article: 112024
I did this by defining my own MGT protocol and connecting the board with a short SATA cable. It took a little bit of learning and then some coding but once I was done it worked with no problems. The corgen makes it pretty easy to setup. The hardest part is setting up the physical constraints. ---Matthew Hicks "vbcity" <chenxiang.xu@gmail.com> wrote in message news:1163554058.869484.20650@b28g2000cwb.googlegroups.com... > Maybe you need a SATA connection to get a ultra high speed link. The IP > Core for that is called Aurora. You can get a reference design from > http://www.xilinx.com/univ/xupv2p.html > > On Nov 14, 9:22 pm, "nana" <nmic...@utk.edu> wrote: >> Helllo, >> Does anyone know about transfering data between two xupv2p boards, that >> is from one board to another? >> I appreciate your help >> >> nmichou >
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